Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What is sharding, and when would you do it?

They're testing: knowing it's a last resort with real costs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Sharding splits a dataset's rows across several databases, each handling a subset of reads and writes. I'd shard when one machine can't hold the data, can't sustain the write rate, or can't keep the working set in memory, after trying query fixes, caching, scaling up and read replicas, because sharding complicates queries, transactions and constraints and is hard to undo.
3
4**Counter-questions:**
5- *"Sharding vs replication?"* → Replication copies all data to scale reads and survive failures; sharding splits data to scale writes and storage. Most large systems do both.
6
7**Trap:** sharding as the first scaling step.

Q2. How do you choose a shard key?

They're testing: the single most important decision.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** High cardinality, even distribution of reads and writes, and present in the most frequent queries so they hit one shard. Data that's read or changed together should share it, so transactions stay on one shard. For an e-commerce orders table, user ID usually fits: lots of values, and "my orders" and checkout all include it.
3
4**Counter-questions:**
5- *"What queries become expensive with user ID?"* → Anything across users: orders by product, daily totals. Serve those from a secondary index or an analytics copy.
6
7**Trap:** picking a key without mentioning query patterns.

Q3. Range vs hash sharding?

They're testing: trade-offs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Range keeps adjacent keys together, so range scans are efficient and hot ranges can be split, but monotonically increasing keys like timestamps send all writes to the last shard. Hash spreads load evenly with no hot "latest" shard, but range queries must hit every shard, and naive mod N reshuffles everything on growth, so you use slots, logical shards or consistent hashing.
3
4**Counter-questions:**
5- *"Can you get both?"* → Compound keys: hash on a high-cardinality prefix (user ID) and keep a range within it (order date), so one user's orders are on one shard and sorted by date.
6
7**Trap:** saying hash is always better.

Q4. What causes hot shards, and how do you fix them?

They're testing: operational experience.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keys that grow with time under range sharding, a few huge keys like a celebrity or a giant tenant, and low-cardinality keys. Fixes: a better hashed key, compound keys with a bucket suffix for time-series data, splitting hot ranges, isolating huge tenants via a directory, and caching hot reads.
3
4**Counter-questions:**
5- *"One tenant is 40% of all traffic. What now?"* → Give it its own shard (or several, sharded internally by another key), using directory routing.
6
7**Trap:** "add more shards" (it doesn't help if one key is hot).

Q5. How do you reshard without downtime?

They're testing: practical migration knowledge.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Avoid mod N; use many fixed logical shards (or hash slots) mapped to physical servers, so growth moves whole buckets and keys never re-hash. To move a bucket: copy a snapshot, stream ongoing changes until caught up, briefly pause writes to that bucket, switch the routing map, verify, then delete the old copy. Tools like Vitess or Citus automate this.
3
4**Counter-questions:**
5- *"Why not just pick many logical shards like a million?"* → Each needs bookkeeping and routing state, and tiny buckets add overhead; a few thousand is a common balance.
6
7**Trap:** "take the site down and rehash".

Q6. How do you handle queries that don't include the shard key?

They're testing: cross-shard strategies.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Scatter-gather to all shards and merge, acceptable for rare or admin queries but slow and fragile because it waits for the slowest shard. For frequent ones, a global secondary index sharded by the other key, denormalised copies, or streaming changes into a separate store built for that access pattern, like a search index or an analytics warehouse.
3
4**Counter-questions:**
5- *"How do you keep a global index consistent?"* → Update it in the same flow with retries, or from a change stream, accepting brief lag; reads that must be exact go to the main shard.
6
7**Trap:** running heavy reports as scatter-gather on production shards.

Q7. How do you enforce a unique email when users are sharded by ID?

They're testing: a classic gotcha.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Two sign-ups with the same email could land on different shards and both succeed. Keep a separate table keyed by email, sharded by email, that maps email to user ID. Sign-up first inserts the email there, which fails if it already exists, then creates the user; if user creation fails, release the claim.
3
4**Counter-questions:**
5- *"What if the claim succeeds but the user insert fails and the release also fails?"* → A cleanup job removes claims that point at no user after a while, or the sign-up is retried with the same claim.
6
7**Trap:** "add a unique index" (it only works within one shard).

Q8. How do you do joins and transactions across shards?

They're testing: knowing what sharding takes away.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Avoid them by design: co-locate related data under the same shard key, replicate small reference tables to every shard, denormalise, or join in the application. For transactions that truly span shards, use two-phase commit (if the database supports it) or a saga with compensating steps (Chapter 17).
3
4**Counter-questions:**
5- *"Why not just use 2PC everywhere?"* → It's slower, holds locks across machines, and a stuck coordinator can block shards. Keep it rare.
6
7**Trap:** assuming cross-shard transactions are free.

Q9. How do sharding and replication combine?

They're testing: a full picture.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Each shard is a replica set: a leader plus followers in different zones. Shards spread data and writes; replicas within each shard give failover, durability and read capacity. Each shard fails over independently, so one machine failure affects only that shard's users briefly.
3
4**Counter-questions:**
5- *"How many servers for 8 shards with 3 copies each?"* → 24.
6
7**Trap:** treating sharding and replication as alternatives.

Q10. How does a request know which shard to go to?

They're testing: routing options.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A routing layer applies the shard function: a client library that knows the shard map, a proxy in front of the shards (like Vitess's), or the database itself redirecting. The map from logical shards or ranges to servers lives in a highly available config store and is cached by routers; when it changes during a move, routers pick up the new version.
3
4**Counter-questions:**
5- *"What if a router has a stale map?"* → The shard rejects or redirects the request, the router refreshes its map and retries.
6
7**Trap:** hard-coding shard addresses in application code.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 15.1 Why shard | Level 2.1, Q1 |
18| 15.2 Shard key | Level 1A, Level 5.1, Q2 |
19| 15.3 Strategies | Level 3.1, Q3 |
20| 15.4 Hot shards | Level 1A.3, Level 2.2, Level 4, Q4 |
21| 15.5 Resharding | Level 2.3, Level 3.2, Level 5.4, Q5 |
22| 15.6 Cross-shard queries | Level 1B, Level 2.4, Level 3.3, Level 5.2, Q6, Q8 |
23| 15.7 IDs and uniqueness | Level 5.3, Q7 |
24| 15.8 With replication | Level 2.1, Level 5.5, Q9, Q10 |
25
26---

15. Sharding