3 ms·

Two phase commit is the traditional answer. Only extreme "enterprise" environments support it like JTA transaction managers in Java land. But 2PC is slow. The

Two phase commit is the traditional answer. Only extreme "enterprise" environments support it like JTA transaction managers in Java land. But 2PC is slow. The modern answer is to move scalability to your DB layer and have X instances of your monolith. Some NewSQL databases like CockroachDB and TiDB are reasonable choices as long as you avoid complex SQL

tharkun__ 6y ago
The modern answer? Really? I'm sorry but this is exactly what tons of "old" businesses have done for ages. But they are being told over and over that that isn't "web scale". In my old life we just scaled via the DB and were able to deploy as many copies of our monolithic services as we needed to scale. We had a few monolithic services (no, not microservices, really nothing micro about them at all) that even shared some core code through a library. In my new life that is no longer wanted and we need microservices and multiple databases. Except that it's all just logically split and in reality ends up in the same DB instance. But you know, we could scale it to a new DB instance if we ever needed to. Not that we will if you ask me because we run maaaany customers on the same database instance too. So it's all fake and we could've just used the same old boring working fine approach as any old business. Go figure.
- throwaway189262 6y ago
  Yeah you're right to an extent. But in the past you could hit a point where one DB could not handle the traffic. There's tons of businesses out there doing one DB instance per customer because of this. With Cockroach and TiDB you can host unlimited traffic on the same db as long as you're careful about queries. I guess you could with Mongo or whatever too if you're okay with data corruption
  - tharkun__ 6y ago
    In my experience being careful with the queries is harder and/or more expensive. Developer time is either very expensive or you just don't have the right developers. It also depends a lot what kind of money you can throw around. Are you a big fat insurance company? Music business? Bank? You are just gonna throw money at Oracle and your hardware vendor and its gonna scale (thinking 10-ish years back into my past here as an example). I think we came from like 4GB of RAM on the DB and a couple of CPUs with single path i/o. Could have spent ages optimizing all the different workloads. And this was already using read only replicas heavily for around the globe acceleration. This internal app was used 24/7 from different places in the world tho heaviest usage was Europe/US timezone. Instead they got 128GB of RAM, 16 cores IIRC and 4-path i/o (still spinning disk w/ SCSI at the time). Sure it cost a lot I'm sure. But I doubt it cost more than a year's salary of _one_ of us developers. And optimization would've required the application developers, the backend batch job developers and the (shared resource) DB admins to work on a multitude of workloads and use cases to analyze and optimize. FF to my current job with lots and lots of but mainly smaller customers. One DB instance per per customer would be a lot of overhead. We do one schema per customer on PostgreSQL right now with sharding.

tharkun__ 6y ago

The modern answer? Really? I'm sorry but this is exactly what tons of "old" businesses have done for ages. But they are being told over and over that that isn't "web scale". In my old life we just scaled via the DB and were able to deploy as many copies of our monolithic services as we needed to scale. We had a few monolithic services (no, not microservices, really nothing micro about them at all) that even shared some core code through a library. In my new life that is no longer wanted and we need microservices and multiple databases. Except that it's all just logically split and in reality ends up in the same DB instance. But you know, we could scale it to a new DB instance if we ever needed to. Not that we will if you ask me because we run maaaany customers on the same database instance too. So it's all fake and we could've just used the same old boring working fine approach as any old business. Go figure.

throwaway189262 6y ago
Yeah you're right to an extent. But in the past you could hit a point where one DB could not handle the traffic. There's tons of businesses out there doing one DB instance per customer because of this. With Cockroach and TiDB you can host unlimited traffic on the same db as long as you're careful about queries. I guess you could with Mongo or whatever too if you're okay with data corruption
- tharkun__ 6y ago
  In my experience being careful with the queries is harder and/or more expensive. Developer time is either very expensive or you just don't have the right developers. It also depends a lot what kind of money you can throw around. Are you a big fat insurance company? Music business? Bank? You are just gonna throw money at Oracle and your hardware vendor and its gonna scale (thinking 10-ish years back into my past here as an example). I think we came from like 4GB of RAM on the DB and a couple of CPUs with single path i/o. Could have spent ages optimizing all the different workloads. And this was already using read only replicas heavily for around the globe acceleration. This internal app was used 24/7 from different places in the world tho heaviest usage was Europe/US timezone. Instead they got 128GB of RAM, 16 cores IIRC and 4-path i/o (still spinning disk w/ SCSI at the time). Sure it cost a lot I'm sure. But I doubt it cost more than a year's salary of _one_ of us developers. And optimization would've required the application developers, the backend batch job developers and the (shared resource) DB admins to work on a multitude of workloads and use cases to analyze and optimize. FF to my current job with lots and lots of but mainly smaller customers. One DB instance per per customer would be a lot of overhead. We do one schema per customer on PostgreSQL right now with sharding.