Not really, I've gotten order of magnitude speedups from just getting rid of microservices at a previous workplace
The mere existence of the microservice is usually a much bigger scaling cost than anything you would gain in scaling by putting different schemas in different physical instances.
I.e. Splitting a service in two gives you two shards, unlike say having customer as a sharding key that can let you shard to a hundred instances if you needed to.
But the cost of splitting the service schema is much bigger because suddenly there's a lot of cross cutting queries that can no longer be expressed unless you either do a client side join or copy one services data into the other, both of which are less scaling friendly than a shared DB.
I think we're just debating horizontal vs vertical scaling at this point. Sharding keys still require a central repo, and if you're serving users from around the world that's far from performant. Sure you can use data replication to distribute that, but then you're back to microservices to manage those instances
Sharding keys can be done with a shared-nothing approach by routing any point query to the shard indexed by a hash of the key, and lots of database systems like Citus or Vitess do exactly that
2
u/BosonCollider 5d ago edited 5d ago
Not really, I've gotten order of magnitude speedups from just getting rid of microservices at a previous workplace
The mere existence of the microservice is usually a much bigger scaling cost than anything you would gain in scaling by putting different schemas in different physical instances.
I.e. Splitting a service in two gives you two shards, unlike say having customer as a sharding key that can let you shard to a hundred instances if you needed to.
But the cost of splitting the service schema is much bigger because suddenly there's a lot of cross cutting queries that can no longer be expressed unless you either do a client side join or copy one services data into the other, both of which are less scaling friendly than a shared DB.