Notes
Sharding comes up when a single database won’t work (e.g., hit storage limits, write throughput limits, or read throughput limits) and you need to split your data across multiple independent servers.
For a user-centric social media app, sharding by user_id means all of a user’s
posts, likes, and comments live on one shard. User-scoped queries are fast, but
“trending posts across all users” become expensive because of hitting every
shard and aggregating results. Mutating transations need to account for the
distributed nature of the shards, making them complex and slow.
There are several sharding techniques to decide where the data goes, e.g.,
- Hash the shard key and use modulo to pick a shard. Assuming randomness, this avoids hot spots.
- Range-based sharding if access patterns naturally partition, e.g., multi-tenant SaaS where each company only queries their own data. Can create hot spots.
- Directory-based sharding consults a lookup table, but this adds a dependecy and latency to every request.
Consistent Hashing helps avoid data movements as DB shards (or cache nodes) come offline or go offline.
References
- Core Concepts for System Design Interviews. www.hellointerview.com . Accessed Jun 6, 2026.