Loading...
Loading...
Browse 4 real-world technical and behavioral interview questions about Sharding. Review scenarios, edge cases, and architectural best practices.
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.
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.
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.
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.