So just wanted to add a few random thoughts about some of this stuff. With sharding, where this stuff eventually gets you is when your assumptions about shard

So just wanted to add a few random thoughts about some of this stuff. With sharding, where this stuff eventually gets you is when your assumptions about shard keys no longer hold. Eg, you might have user initiated traffic to start with, so you can easily and automatically shard everything by user id or whatever. Then one day, those assumptions change because you might have to accommodate event driven traffic, ie not request/response, and the user’s id can’t be assumed to always be present. For example let’s say something in the real world causes an event to be pushed onto your queue. That event could correspond to a real user, but since it originated somewhere in the real world, there’s probably a separate id for how that user is represented. So you can’t rely on that user ID being present to shard things by. Not sure, if that makes sense, but sharding can be hard. It’s not like free, and I still think it’s important for engineers to understand the mental model they’re using, even with a tool like vitess. Also, I saw claim either on planetscale or vitess that MySQL has no native support for horizontal scaling with automatic sharding, but I think they do? I think you just have to pay for that though. Also, cross-shard transactions were mentioned as another difficulty with sharding. They can be done with either sagas (depends on the context but it’s a design pattern), or 2PC which is available in MySQL > 5.8 I believe in the form of XA Transactions.