The fastest way to lose a system design interview is to hear “the database can’t keep up” and answer “so we shard it.” Most of the time the interviewer was fishing for a read replica or a cache, and reaching straight for the most disruptive option tells them you don’t know what each one costs. Partitioning, sharding, and replication fix different problems. The question is really a test of whether you can name the problem in front of you before you name the fix.
Here’s the relationship that trips people up. All sharding is partitioning, but not all partitioning is sharding, and replication sits on a separate axis from both. You can partition a table without ever adding a second server. You can replicate a database that was never partitioned. A mature system usually does all three at once: data split into shards, each shard partitioned internally, each shard replicated for durability. Interviewers ask this because candidates collapse the three into one word, “scaling,” and then can’t reason about what each one gives up.
Partitioning splits one table into smaller pieces
Partitioning divides a single logical table into smaller physical chunks that the database engine manages for you. It comes in two shapes. Vertical partitioning splits by column: move the rarely read bio and avatar_blob fields out of the hot users row so the common query reads less data per page. Horizontal partitioning splits by row: January’s orders in one partition, February’s in the next, keyed on a range or a hash of some column.
The part that matters for an interview is that classic partitioning stays inside one database instance. Postgres has declarative partitioning where you write PARTITION BY RANGE (created_at) and the planner prunes to the right partition on its own. You get faster scans and cheap bulk deletes, since dropping last year’s partition beats a DELETE that bloats the table, and you pay none of the distributed-systems tax. If the interviewer’s problem is “one table got huge and queries scan too much,” partitioning may be the whole answer, and saying so earns credit for not over-building.
Sharding is partitioning across separate machines
Sharding is horizontal partitioning where the pieces live on independent nodes, each running its own database, with something deciding which node owns a given row. That something is the routing layer, and it’s where the pain hides. A lookup for user 12345 now has to know that user 12345 lives on shard 3. A join between two users on different shards can’t run in the database anymore. A transaction spanning three shards needs a distributed commit protocol or a redesign that avoids one. You can put the routing in the application, or in a proxy that speaks the database’s wire protocol so the app believes it’s talking to a single server.
You reach for sharding when one machine can’t hold the data or can’t absorb the write throughput, and replicas won’t help because the bottleneck is writes rather than reads. That condition is the whole point. Replication scales reads and does nothing for a write-saturated leader. When your write volume outgrows the largest instance your cloud sells, sharding is the move, and not a step before that.
Replication copies the same data to more nodes
Replication duplicates the same data across multiple nodes. It splits nothing. The common shape is one leader taking writes and several followers serving reads, with changes streaming from leader to follower. It buys read capacity, because followers soak up read traffic, and availability, because a follower can be promoted when the leader dies. Most systems keep a single leader, because multi-leader setups turn every concurrent write into a conflict you have to resolve by hand. Quorum stores in the Dynamo lineage skip the single leader entirely and instead write to several replicas and read from several, sized so a majority always overlaps.
The tradeoff you should volunteer is replication lag. Async replication lets a follower fall milliseconds or seconds behind the leader. A user updates their profile, the write lands on the leader, the next read hits a follower that hasn’t caught up, and the user sees stale data. Interviewers reach for this scenario constantly. Know the fixes: pin a user’s reads to the leader for a few seconds after they write, which gives read-your-writes consistency, or run synchronous replication on the paths that can’t tolerate staleness and accept the added write latency.
| Technique | What it does to the data | Problem it solves | Main cost you take on | Reach for it when |
|---|---|---|---|---|
| Partitioning | Splits one table into smaller chunks inside a single database | A large table with slow scans and expensive bulk deletes | Partition key has to fit the query; cross-partition queries still touch many partitions | One table is huge but the data still fits on one machine |
| Sharding | Spreads rows across independent databases on separate nodes | Data size or write volume exceeds a single machine | No cross-shard joins or easy transactions; resharding is hard; you build and run a routing layer | Writes or dataset outgrow the largest single instance available |
| Replication | Copies the full dataset to additional nodes | Too many reads for one node, or you need failover | Replication lag causes stale reads on async followers | Read-heavy load, or you need a standby to promote on failure |
When the interviewer says reads are slow, don’t open with sharding
A large share of these questions open with some version of “our reads have gotten slow, what do you do.” The trap is that sharding sounds impressive, so people go there first. The credible order is cheaper and less invasive. Put a cache in front of the hot reads. Add read replicas and route reporting and read-only traffic to them. Check whether the actual fix is a missing index or a rewritten query. Only when the write path itself is saturated, or the dataset no longer fits on one box, does sharding earn its place. Saying that order out loud signals you’ve run a database in production instead of only reading about one.
The shard key is the decision you can’t take back
Once you commit to sharding, the shard key is what you live with for years, and interviewers push on it because a bad key quietly wrecks the design. Three schemes come up. Range-based sharding, say users A to M on one shard and N to Z on another, makes range scans easy but invites hot spots when the data isn’t evenly spread. Hash-based sharding distributes rows evenly by hashing the key, at the cost of range queries, which now fan out to every shard. Directory-based sharding keeps a lookup table mapping keys to shards, which is flexible but adds a hop and another thing to keep consistent.
The failure everyone has a story about is the hot shard. Choose user ID as your key on a system where one celebrity account draws a thousand times the traffic, and that account’s shard melts while the rest sit idle. Strong candidates sidestep this by picking a tenant-shaped key, so everything one customer touches lives together and load spreads across customers. Notion shards on workspace ID; Slack shards on team ID. A workspace’s data stays co-located, so most queries hit a single shard, and no one tenant can dominate a node unless that tenant alone is enormous.
Then the follow-up that catches people: how do you add shards later without downtime? Naive modulo hashing, shard = id % N, reshuffles nearly every row the instant N changes. Consistent hashing exists to make that cheaper, moving only a fraction of keys when a node joins. In practice teams lean on systems that already solved this. Vitess shards MySQL and grew up running YouTube, Citus does it for Postgres, and DynamoDB and MongoDB manage partitions for you behind a declared partition or shard key. Naming one shows you treat resharding as a solved-but-painful operational problem, not something you’d hand-roll on a whiteboard.
The follow-ups that separate a mid-level answer from a senior one
The deeper the interview goes, the more it starts to sound like these:
- “A transaction has to touch two shards. What breaks, and what would you do instead?”
- “Your async replica is thirty seconds behind and a user just changed their email. What do they see on the next page load?”
- “One tenant is now forty percent of your traffic and your shard key is tenant ID. Now what?”
- “You need to double the shard count during your busiest week. Walk me through it.”
Good answers stay concrete. The two-shard transaction either gets a two-phase commit or, better, a redesign so the write lands on one shard. The lagging replica means a stale read, fixed by routing that user to the leader briefly. The forty-percent tenant gets split onto its own shards or moved to a composite key. The resharding walk-through leans on consistent hashing and an online backfill that copies data to the new shards before traffic flips over.
If you carry one habit into the room, make it matching the fix to the symptom before you name any technique. “Reads are slow,” “we can’t write fast enough,” and “this table is too big to query” are three different sentences with three different answers, and the people who get leveled up are the ones who work out which one they’re actually solving before they draw a single box.
Keep sharpening your system design:
