Your app is taking off. Traffic grows, users sign up, the database keeps getting bigger — until a single machine simply can't keep up. Sharding is what you reach for next, and it trades one hard problem for several new ones.
01Why Sharding Exists
At first, growth is easy to absorb. A single database instance — say an AWS RDS Postgres box — handles rising read and write volume without complaint. When it starts to strain, the obvious first move is vertical scaling: upgrade to a bigger machine with more CPU, memory, and storage. This works, and it works for a surprisingly long time.
But every single machine has a ceiling. Queries slow down, writes become a bottleneck, backups take forever, and storage approaches its limit. Even powerful managed databases top out — Amazon Aurora maxes out around 256 TiB. Once you saturate CPU, storage, and I/O, a bigger box is no longer the answer: no matter how big the database, one machine can't keep up. That is the moment you shard.
Evan frames it with a running example. A single sizeable Postgres instance handled roughly 70 TB of storage and ~10,000 writes/sec. Vertical scaling on AWS could push that to about 140 TB and ~50,000 writes/sec — "a ton of throughput; most companies will never hit this." Only after that ceiling is truly saturated (global traffic, CPU/storage/IO all maxed) does sharding become the right tool. The exact numbers matter less than the shape: vertical scaling first, sharding only when it runs out.
handles all load
bigger machine
CPU/IO/storage maxed
split across machines
When a single database can't keep up anymore, you have only one real option: split your data across multiple machines. That is sharding. It is a necessity at scale — and it introduces a fresh set of problems you must now design around.
02Partitioning vs. Sharding
People often use "partitioning" and "sharding" interchangeably. Technically they differ, and it's worth being precise even though most engineers use the words loosely.
Partitioning splits a large table into smaller pieces inside a single database instance. No new machines are added — the data is organized into logical pieces the database can manage separately.
Sharding splits data across multiple machines. Each shard is an independent database.
The practical distinction is simply: is your data on one machine or many? Don't get hung up on the wording in an interview — just be clear about which situation you're describing.
Why partition at all?
Consider an orders table with 500 million rows and 2 TB of data. A query for last month's orders has to scan the entire table. Indexes become huge and slow to maintain, and routine operations — vacuuming, analyzing, rebuilding indexes — can lock the whole table and tank performance.
Partitioning breaks that large table into smaller partitions. The data doesn't move off the machine; it's divided into logical pieces. Now a query for last month's orders only scans the relevant partition instead of the full table.
| Type | What splits | Result | Example |
|---|---|---|---|
| Horizontal | Rows across partitions | Same columns, fewer rows each | One partition per year of orders |
| Vertical | Columns across partitions | Same rows, fewer columns each | Hot columns in one partition, large/rare columns in another |
03What Sharding Actually Is
Sharding is horizontal partitioning across multiple machines. Each shard holds a subset of the data, and together the shards make up the full dataset. Unlike partitioning, which stays within one instance, sharding spreads the load across many independent databases.
Each shard is a standalone database with its own CPU, memory, storage, and connection pool. No single machine holds all the data or handles all the traffic — which is exactly why both storage capacity and read/write throughput scale as you add more shards.
id. Each shard is a full, independent database holding one slice of the range.Sharding solves scaling but immediately hands you new problems: you now have to choose a shard key, route queries to the right shard, avoid hot spots, and rebalance data as shards grow. The rest of these notes work through each of those.
04The Two Decisions
When you decide to shard, you make two decisions that work together:
What to shard by — the field used to split the data. It defines how data is grouped. This is the shard key.
How to distribute it — the rule for assigning those groups to shards. It defines how data is distributed across machines. This is the distribution strategy.
"In simple terms, the shard key is how we group our data, and the distribution strategy is how we place those groups onto shards." In an interview, anytime you discuss sharding, the very first thing to state is your shard key — which column, and why.
4.1 · Choosing a Shard Key
A common interview line is "I'm going to shard by [field]." The skill is knowing what field and why. A bad shard key leads to uneven distribution, hot spots where one shard gets pounded while others sit idle, and queries that must hit every shard. A good one distributes evenly, aligns with your queries, and scales as you grow.
Three properties of a good shard key
| Property | What it means | Why it matters |
|---|---|---|
| High cardinality | Many unique values | A boolean gives you only 2 shards, max. Millions of user IDs give room to spread. |
| Even distribution | Values spread evenly across shards | Shard by country when 90% of users are in the US and that one shard dwarfs the rest. |
| Query alignment | Common queries hit one shard | Shard users by user_id and "get user's profile / orders" stays single-shard. Queries that span all shards get expensive. |
Worked examples
- user_id for a user-centric app — millions of users (high cardinality), even distribution, and most queries are scoped to a single user anyway ("show me this user's data"). Perfect fit.
- order_id for an e-commerce orders table — millions of orders, queries usually scoped to one order ("get order details", "update status"), and orders distribute evenly over time.
- is_premium (boolean) — only two values means only two shards. One gets all premium users, the other all free users; if most are free, that shard is overloaded.
- created_at for a growing table — all new writes land on the most recent shard, making it a write hot spot while older shards go idle.
Even user_id, the model good key, has one weakness: some keys are inherently more active than others. Uniform arrival of users doesn't mean uniform traffic per user. Hold that thought — it becomes the "celebrity problem" in §5.1.
4.2 · Distribution Strategies
Once you know your shard key, you decide how to distribute that data. There are three main strategies with different trade-offs.
Range-based sharding
The most straightforward: group records by a continuous range of values. Pick a key like user_id or created_at, then assign value ranges to shards.
Shard 1 → User IDs 1–1M
Shard 2 → User IDs 1M–2M
Shard 3 → User IDs 2M–3MIts advantage is simplicity and efficient range scans — need all orders between user IDs 500K and 600K? You hit one shard. The problem is that most real access patterns don't spread evenly across ranges. Shard orders by created_at and almost all traffic hits the newest shard, because users care about recent data. New writes only go to the latest shard; old shards sit idle.
Multi-tenant systems. Each company gets a range of IDs — a SaaS app where Company A's users query only Company A's range and Company B's users query only Company B's. Different tenants naturally query different ranges, which distributes the load. This is the sweet spot for range sharding.
If user IDs are monotonically increasing, all new users land in the highest range — and new users are, almost by definition, your most active ones. So shard 3 takes all the heat while shards 1–2 sit cold. Range sharding "can work, but you have to be really intentional about splitting ranges before things get too big." It's a fine place to start intuitively, but "it's not what most things use in production."
Hash-based sharding · the default
Instead of assigning ranges, take the shard key, hash it, and use the result to pick a shard. The hash function scrambles the input, so records spread evenly.
shard = hash(user_id) % 4
User 42 → hash(42) % 4 = Shard 2
User 99 → hash(99) % 4 = Shard 3
User 123 → hash(123) % 4 = Shard 1The big win is even distribution — new users get scattered across all shards. The downside shows up when you add or remove shards: going from 4 shards to 5 changes % 4 to % 5, and almost every record now maps to a different shard. You have to move massive amounts of data.
Hash-based sharding is the most common strategy and what your interviewer assumes you're using unless you say otherwise. It works great as long as you have a plan for resharding — and that plan is consistent hashing.
Plain modulo means "add one shard → reshuffle almost everything," which is an operational nightmare. Consistent hashing fixes this by placing both the keys and the shards on a virtual ring: you hash a key onto the ring, then walk clockwise until you hit a database. Adding or removing a shard only moves the keys in one arc, not the whole dataset. Techniques like virtual nodes smooth this further. (There's a dedicated consistent-hashing page/video; here, just know: hash-based + consistent hashing = smooth scaling.)
Say "I'll shard by user_id" and a senior-plus interviewer already assumes hash-based + consistent hashing — you often don't even need to state it. For junior / mid-level roles they may ask "how is the sharding happening?", which is your cue to explain the hash-and-consistent-hashing mechanics.
Directory-based sharding
Instead of a formula, store shard assignments in a lookup table or service. Every record's location is explicit.
user_to_shard
---------------
User 15 → Shard 1
User 87 → Shard 4
User 204 → Shard 2The power is flexibility: move a heavy user to a dedicated shard, rebalance load by updating the mapping, implement arbitrary logic a hash can't. The cost is that every request needs a lookup first — extra latency on every read and write, and the directory becomes a single point of failure. If the directory goes down, the whole system stops even if every data shard is healthy.
Directory-based sharding is valid for genuinely dynamic needs, but in an interview it "is almost never the right answer." It introduces a single point of failure, adds a second hop of latency to every request, and invites a swarm of follow-up questions that can derail the whole conversation. Know it exists; default to hash-based + consistent hashing.
| Strategy | Best when | Main weakness |
|---|---|---|
| Range | Data falls into clean ranges; multi-tenant; range scans matter | Skewed load — newest range takes all traffic |
| Hash default | You want even distribution (most cases) | Resharding — solved by consistent hashing |
| Directory | You need maximum flexibility / hot-key isolation | Extra latency + single point of failure |
05The Challenges of Sharding
Sharding solves scaling but distributes your data across machines, which means you must now deal with uneven load, queries that span shards, and consistency across databases. These are unavoidable — but designable-around if you know what to expect. In an interview, these three are the follow-up questions your interviewer will throw at you.
5.1 · Hot Spots & Load Imbalance
Even with a good shard key, some shards can end up handling far more traffic than others. That's a hot spot, and it negates the whole benefit of sharding — one overloaded shard becomes your bottleneck.
Shard users by user_id and a superstar's shard handles 1000× the traffic of a normal user's. Every profile view, like, comment, and message hits the same shard. Hash-based distribution doesn't help — the issue isn't the distribution strategy, it's that some keys are inherently more active than others.
The written guide uses Taylor Swift; the video uses Lionel Messi. Same idea: one celebrity lands on shard 1, and shard 1's write throughput becomes orders of magnitude larger than every cold shard around it.
Time-based sharding creates a different hot spot: shard by creation date and all new writes pile onto the most recent shard while older shards sit idle serving only historical reads.
Three ways to handle hot spots
1. Isolate hot keys to a dedicated shard. Move the celebrity account onto its own shard (often with beefier hardware, and reachable via a directory lookup). This is one of the few cases where directory-based routing earns its keep.
2. Use a compound shard key. Instead of hashing just user_id, combine it with another dimension — hash(user_id + date) or hash(user_id + n) where n spreads over several shards. This scatters a single hot user's data across multiple shards.
3. Dynamic shard splitting. Some databases split a shard automatically when it gets too big or too hot. MongoDB's balancer splits and migrates range-based chunks (including with a hashed shard key) to keep balance. Vitess supports online resharding, but it's operator-driven, not automatic.
A reader asked the sharp question: doesn't hash(user_id + date) also scatter every regular user's data, breaking the query-alignment property? A query for "all of user X's posts this week" would now hit 7 shards for everyone, not just celebrities.
This is a real tension. The practical resolution discussed: keep a register of known hot users and apply the compound key (or a dedicated shard) only to them, while everyone else stays on plain hash(user_id) and keeps single-shard queries. Don't blanket-apply a compound key to your whole user base.
Q&ADoesn't a "dedicated celebrity shard" just become THE hot spot?
Yes — that shard is busy by design. But it does two useful things. First, it isolates the blast radius: ordinary users sharing a normal shard are no longer collateral damage when the celebrity spikes. Second, because that shard is dedicated, you can give it special hardware and vertically scale it to absorb throughput spikes. As one commenter noted, in the extreme you might give a single "big whale" its own shard. And "hot" is often transient — trending keys shift day to day, so the load moves rather than pinning one node forever.
5.2 · Cross-Shard Operations
When data lives on multiple machines, any query needing data from more than one shard becomes expensive. Instead of hitting one database, you fan out to multiple shards, wait for all of them, and aggregate the results yourself. This happens whenever a query doesn't align with your shard key.
Shard users by user_id. "Get user 12345's profile" → one shard. Fast. But "get the top 10 most popular posts globally" → posts are scattered across all 64 user shards. You send the query to all 64, wait for 64 responses, merge, then return the top 10. That's 64× the network calls and latency.
Minimizing cross-shard queries
Cache the results. If "top 10 posts" needs all shards, cache it (e.g. in Redis) for ~5 minutes. The first query is expensive; the next thousand hit the cache. Perfect for anything tolerant of slight staleness — leaderboards, trending content, aggregate stats. You trade a little consistency for a lot of latency.
Denormalize to keep related data together. If you frequently query posts alongside user data, store some post info directly on the user's shard. Yes, this duplicates data and makes writes more complex — but it lets you answer from one shard. Classic scaling trade-off: pay a bit more on writes, make reads faster and cheaper.
Accept the hit for rare queries. A query that must hit all shards is fine if it's infrequent. An admin dashboard showing "total users across all shards" can afford to be slow if it loads a few times a day.
If you catch yourself saying "we'll query all shards and aggregate" for a common use case, pause. It usually signals one of three things: (a) you chose the wrong shard key (most important), (b) you should cache / precompute, or (c) you should denormalize. Interviewers expect you to minimize cross-shard queries, not accept them as inevitable. They should be the exception, not the norm.
5.3 · Maintaining Consistency
On a single database, transactions are easy: wrap two operations in a transaction and either both succeed or both fail. Sharding breaks this. If a user's account is on shard 1 and a transaction record is on shard 2, you're coordinating writes across two independent databases that don't know about each other.
Bob has $10, Alice has $10, Bob sends $5 to Alice. On one database this is a single atomic transaction: deduct $5 from Bob, add $5 to Alice — both commit or neither does. But if Bob is on shard 1 and Alice is on shard 3, the two updates can't happen atomically. What if Bob's deduction succeeds and Alice's credit fails? Now you're in an inconsistent state.
The textbook solution: two-phase commit (2PC)
A central coordinator asks all shards "are you ready?", waits for every shard to confirm, then tells them all to commit. It guarantees consistency — but it's slow and fragile. If any shard or the coordinator dies mid-transaction, the whole thing can get stuck in a lock that's painful to escape. Most production systems avoid 2PC because the performance and reliability trade-offs aren't worth it.
Bob · shard 1
Alice · shard 3
refund Bob (compensate)
What to do instead
Design to avoid cross-shard transactions. The best solution. Keep all of a user's data — balance, history, profile — on their shard, so every transaction is single-shard: fast and reliable.
Use the saga pattern for genuine multi-shard operations. Break the operation into a sequence of independent steps, each with a compensating action. If step 3 fails, run the compensations for steps 2 and 1 to undo the work. This gives eventual consistency without 2PC's fragility.
1. Deduct money from User A (shard 1)
2. Add money to User B (shard 2)
3. If step 2 fails → refund User A // compensating actionAccept eventual consistency. Strict consistency often isn't required. A denormalized follower count can differ across shards for a few seconds and then converge — far simpler than a distributed transaction, and fine for most apps.
Most applications can be designed to avoid cross-shard transactions entirely. If you constantly need distributed transactions, you probably chose the wrong shard key or the wrong shard boundaries.
Q&AWhat about DynamoDB's ACID transactions? Can I lean on them in an interview?
This came up in the comments. DynamoDB does support ACID transactions in a distributed setup, using optimistic concurrency control (OCC) rather than the pessimistic locking of 2PC. But the maintainers cautioned against leaning on it uncritically: transactions have strict limits (originally ~25 actions, later raised to ~100; a ~4 MB total cap; same-account, same-Region only), and because it's OCC, high-contention workloads see lots of transaction failures and retries. It also isn't MVCC, so repeatable-read efficiency lags something like Postgres.
The suggested interview framing: "Yes, managed distributed ACID exists here — but only within narrow operating bounds." Good for showing depth; risky if stated without those caveats.
06Sharding in Modern Databases
You probably won't implement sharding from scratch. Most modern distributed databases handle it automatically — you specify a partition/shard key and they route queries and rebalance for you. But the mechanics differ, so don't claim they all "use consistent hashing."
Common NoSQL stores let you specify a partition key, but distribute differently:
| Database | How it distributes |
|---|---|
| Cassandra | A partitioner (e.g. Murmur3Partitioner) with virtual nodes — a form of consistent hashing mapping partition keys to token ranges on nodes. |
| DynamoDB | Hashes the partition key to route items to internal partitions, splitting/merging partitions as they grow. Not classic ring-based consistent hashing exposed to users. |
| MongoDB | Shards into range-based chunks on the shard key (over the hash space if you pick a hashed key). A background balancer auto-splits and migrates chunks. Not classic consistent hashing. |
SQL has matured too. Vitess and Citus are open-source sharding layers that sit in front of MySQL or PostgreSQL and handle query routing, cross-shard operations, and resharding for you. Cloud offerings like AWS Aurora and Google Cloud Spanner provide distributed SQL with built-in sharding.
"We'll use DynamoDB with user_id as the partition key," or "We'll shard using Vitess on user_id and plan for operator-driven online resharding." You don't need to implement sharding internals unless asked.
07Sharding in the Interview
Sharding comes up almost any time you discuss scaling — typically in your deep dives, toward the end, while satisfying a scaling non-functional requirement. The skill is knowing when to bring it up, what to say, and what mistakes to avoid.
When to mention sharding
By far the most common sharding mistake is premature sharding — introducing it before proving it's necessary. Candidates reflexively say "I need to shard, and I'll shard by X." Slow down, do the math, and establish why a single database won't work first.
Bring up sharding when capacity planning hits a real limit:
| Bottleneck | Sample reasoning |
|---|---|
| Storage | "500M users × 5KB = 2.5TB. A single Postgres handles that — but 10× growth needs sharding." |
| Write throughput | "50K writes/sec at peak. A single database will struggle, so we shard." |
| Read throughput | "Even with read replicas, 100M DAU making multiple queries each means distributing reads across shards." |
1. Identify the bottleneck → 2. Explain why a single database won't scale → 3. Propose sharding. Ground it in numbers (use a "numbers to know" reference for realistic single-DB limits).
It can be genuinely impressive to conclude "based on this math, I don't need to shard." Modern hardware goes far — 140TB storage, ~50K writes/sec on a single box. 500M users × 5KB is only 2.5TB. Showing restraint reads as senior judgment, not a gap.
What to say — the four-step walkthrough
Using a social media app as the example:
1. Propose a shard key from access patterns. "Most queries are user-centric — loading a feed means a user's posts, followers, likes, all scoped to one user. So I'd shard by user_id."
2. Choose a distribution strategy. "Hash-based sharding with consistent hashing — hash the user_id to distribute users evenly." (Often skippable for senior roles; worth stating for junior/mid.)
3. Call out the trade-offs. "Global queries get expensive — 'trending posts across all users' means querying all shards and aggregating. We'd cache trending content and precompute it with a background job rather than compute per request."
4. Address growth. "We'll start with enough shards to leave room to grow, and consistent hashing makes adding shards later cheap — only a fraction of the data moves."
On starting shard count, the two sources differ: the written guide says "start with 64 shards", while the video says "start with 10 shards." Neither is a magic number — the point is to pick enough headroom that you're not resharding immediately, and lean on consistent hashing when you do grow.
The reason this works is flow: you're not listing facts, you're walking through your reasoning and showing you understand the trade-offs.
In Short
Sharding is what you do when a single database can't handle your scale anymore — you split data across machines to grow storage and throughput. Two decisions carry the weight: pick a shard key that aligns with your query patterns, and choose a distribution strategy that spreads load evenly. Get these wrong and you inherit hot spots and expensive cross-shard queries.
In interviews: bring up sharding only once you've identified a real bottleneck, walk through your shard-key choice and its trade-offs, and show you've thought about cross-shard queries and resharding. Most of all — don't shard too early. A well-tuned single database gets you surprisingly far.
✎Active Recall
Answer each before expanding. These test reconstruction and decision-making, not trivia.
01Distinguish partitioning from sharding. Why does the distinction matter?
Partitioning splits a large table into smaller pieces within a single database instance (no new machines) so the DB manages and scans less at a time. Sharding splits data across multiple machines, each an independent database. It matters because they solve different problems: partitioning improves single-machine efficiency; sharding is what you reach for once a single machine — even a vertically scaled one — is exhausted. Practically, ask: is the data on one machine or many?
02Name the three properties of a good shard key, and give a key that fails each.
High cardinality — fails: a boolean like is_premium (only 2 shards possible). Even distribution — fails: country when 90% of users are in one country. Query alignment — fails: any key where common queries must fan out to all shards. user_id for a user-centric app satisfies all three.
03Why is hash-based sharding the default, and what problem does consistent hashing solve for it?
Hashing scrambles the key so records spread evenly across shards — solid even distribution with no manual range management. Its weakness is resharding: with plain hash(key) % N, adding a shard changes % N to % (N+1) and nearly every record remaps, forcing a massive data move. Consistent hashing places keys and shards on a virtual ring and walks clockwise to find a shard, so adding/removing a shard only moves keys in one arc. Virtual nodes smooth the distribution further.
04What is the celebrity problem, and why doesn't better hashing fix it?
One extremely active key (a celebrity) lands on a shard, and that shard receives orders of magnitude more traffic than its peers. Hashing distributes keys evenly, but it can't change the fact that traffic per key is wildly uneven — some keys are inherently hotter. Fixes: isolate the hot key on a dedicated (often beefier) shard via directory lookup, use a compound shard key like hash(user_id + date) to scatter that key's data, or use dynamic shard splitting.
05A compound shard key spreads a hot user's data — what does it break, and how do you avoid the downside?
It breaks query alignment: if you apply hash(user_id + date) to everyone, "all of user X's posts this week" now fans out across multiple shards for every user, not just celebrities. Avoid it by applying the compound key (or a dedicated shard) only to a known register of hot users, while keeping plain hash(user_id) — and single-shard queries — for the ordinary majority.
06You keep needing to "query all shards and aggregate" for a common request. What does that signal, and what are your options?
It usually signals the wrong shard key (most important) — the query doesn't align with how data is grouped. Options: (a) reconsider the shard key, (b) cache or precompute the result (great for leaderboards/trending where slight staleness is fine), or (c) denormalize so related data lives on one shard (pay more on writes for cheaper reads). Cross-shard queries should be the exception, not the norm.
07Why does sharding break single-database transactions, and how do 2PC and sagas each respond?
When the two rows in a transaction live on different shards, you can't wrap them in one atomic DB operation — a partial failure leaves inconsistent state. 2PC: a coordinator asks all shards to prepare, waits for unanimous yes, then commits — correct but slow and fragile (a mid-flight failure can deadlock). Saga: chain smaller steps, each with a compensating action; if a later step fails, run the compensations to undo earlier ones — eventual consistency without 2PC's fragility. Best of all: design so transactions stay single-shard.
08Walk through the four-step interview script for introducing sharding — and the mistake to avoid before step one.
Before anything: don't shard prematurely — first prove a single database can't handle the storage/write/read load with actual math. Then: (1) propose a shard key from access patterns (e.g. user_id because queries are user-centric); (2) choose a distribution strategy (hash-based + consistent hashing); (3) call out trade-offs (global queries get expensive → cache/precompute); (4) address growth (start with enough shards; consistent hashing keeps future resharding cheap).
↺Quick Revision
Rapid refresh — skim before an interview.
Must Remember
- Sharding = horizontal partitioning across machines.
- Two decisions: shard key (grouping) + distribution strategy (placement).
- Don't shard prematurely — prove the single DB is exhausted first.
- Default = hash-based + consistent hashing.
Good Shard Key
- High cardinality — many unique values.
- Even distribution — no skew.
- Query alignment — common queries hit one shard.
- Bad:
is_premium(boolean),created_at(write hot spot).
Strategies
- Range — simple, range scans; skews to newest. Good for multi-tenant.
- Hash — even; resharding pain → consistent hashing.
- Directory — flexible; adds latency + SPOF. Rarely the interview answer.
Three Challenges
- Hot spots (celebrity) → dedicated shard, compound key, dynamic split.
- Cross-shard → cache, denormalize, or accept if rare.
- Consistency → avoid cross-shard txns; else saga; accept eventual.
Interview Script
- 1. Shard key from access patterns.
- 2. Hash-based + consistent hashing.
- 3. Call out trade-offs (global queries).
- 4. Handle growth (start w/ headroom).
Key Distinctions
- Partitioning (one machine) vs. sharding (many).
- 2PC (atomic, blocking) vs. saga (eventual, compensations).
- Even key distribution ≠ even traffic per key.
- Managed DBs: Cassandra ≈ consistent hashing Dynamo/Mongo ≠
Pick a shard key that keeps your common queries on a single shard, distribute with hash-based + consistent hashing, and only shard once a single database genuinely can't cope. Everything else — hot spots, cross-shard queries, distributed transactions — is a symptom you minimize, usually by revisiting that key.
Study notes compiled from Hello Interview's written guide "Sharding in System Design Interviews" and its companion video with Evan (former Meta staff engineer). Instructor commentary and reader questions are labelled where woven in. For deeper dives, the source links to dedicated pages on consistent hashing, the saga pattern, and numbers-to-know.