Top 5 Sharding Interview Questions
Browse 5 real-world technical and behavioral interview questions about Sharding. Review scenarios, edge cases, and architectural best practices.
You are asked to design something distributed and your honest answer is one Postgres box. When is that the strongest answer in the room, and when does it end the interview?
One PostgreSQL primary with a replica and tested backups is the strongest answer when a capacity estimate built from the prompt fits it with headroom and the core invariants need transactions. It ends the interview when the prompt rules it out, or when you use it to decline the distributed design you were asked for.
Your data is pinned per region, but login must be globally unique and admins want one global search. How do you build that?
Keep one small global directory holding only the keys needed to route a request, never the payload. Uniqueness becomes a claim on a pseudonymous token, search becomes a fan-out that returns pointers each region resolves locally, and every field promoted to the global tier is a transfer decision.
How do you choose a datastore, and then how do you choose its shard key?
Choose the store from the dominant access pattern and the invariants it must enforce, not from a category label. Choose the shard key so the most frequent query is answerable from one shard, the key has enough distinct high-traffic values to spread load, and shards can be split later without rewriting every row.
One celebrity account is ninety per cent of your write traffic on a single partition. What do you do about a key you cannot rebalance?
A hot partition from one account cannot be fixed by ordinary rebalancing because it is one key. Split the key into write-sharded sub-keys or aggregate writes before storage; both choices move cost to reads, ordering, rollups or approximation.
The table is 800GB and the shard key turned out wrong. How do you reshard while writes continue?
Changing a shard key moves rows between shards, so it is a copy-and-delete across nodes rather than an UPDATE. Put a bucket-to-shard directory in front of the data, move one bucket at a time behind a freeze measured in milliseconds, verify each bucket before flipping its ownership, and keep every bucket independently reversible.