This is the second article of my Distributed Systems series. If you haven't read the previous one, here: Read Replication.

Sharding

What if things get too tough for the leader database (referring back to read replication)?

Writing and distributing the data to all the follower databases, here we've to come up with a different solution.

Sharding is splitting up the workload into multiple read replicas. For an instance, if we have users with names that begin with the letters A to Z, we want to have 4 different replicas, responsible for a different set of users. One replica for example would be responsible for users whose names begin with A to D.

Complexity & Limitations

Sharding fits nicely for key-value stores, but what if you're not a key-value store?

If you don't luck out on being able to shard every single query, life can get a little hard, to the point Sharding just won't work for you (then you'd have to look for something else).

Visualizations