System Design: Scale Writes with Sharding — Explain It, Don’t Guess

If your system can’t handle write spikes, it will fail in production—and in interviews. Sharding is the standard technique to scale write-heavy systems: partition data across multiple database instances (shards) so writes spread out instead of bottlenecking a single node.

This post gives a compact, interview-ready explanation: what sharding is, how to pick a key and strategy, how routing and rebalancing work, and the tradeoffs you must mention.

The core idea

• Partition data horizontally across multiple shards so each shard handles a subset of writes.
• With N shards, you can scale write throughput roughly by N (ignoring replication and other overheads).

How to explain sharding in an interview — step by step

1. State the problem: "We need to handle high write throughput or write spikes that overwhelm a single DB node."
2. Propose sharding: "Partition the data so writes are distributed across multiple DB instances (shards)."
3. Pick a sharding key (example: userId) and justify it: uniform distribution, locality for common queries, ability to route.
4. Choose a sharding strategy (hash, range, or directory) and explain why you picked it.
5. Describe how writes are routed to the correct shard and how the system looks to clients (transparent proxy or client-side routing).
6. Explain rebalancing: plan to split/merge shards, migrate ranges, or use consistent hashing with virtual nodes.
7. Call out tradeoffs: added complexity, cross-shard queries, and consistency/transactions.
8. Describe monitoring, automation, and fallback (alerts, autoscaling, circuit breakers).

If asked for specifics, sketch key components: a routing layer (proxy or client library), a shard map service, shard instances with replication, and a rebalancer/migration tool.

Sharding key strategies (short overview)

• Hash sharding

  • Use hash(key) mod N to map items to shards.
  • Pros: good distribution, simple.
  • Cons: range queries are hard; rehashing needed on reshard.

• Range sharding

  • Partition by ranges of a sortable key (e.g., userId ranges or time windows).
  • Pros: efficient range queries and scans.
  • Cons: hotspotting if keys are skewed (time-based writes create write hot shards).

• Directory (lookup) sharding

  • Maintain a mapping table (shard map) from key to shard.
  • Pros: flexible, supports complex placement.
  • Cons: extra lookup latency and central state to manage.

Choose the key and strategy based on query patterns, data skew, and operational constraints.

Routing writes

• Client-side routing: client computes shard (e.g., hash) and writes directly to the shard.
• Proxy/router: a stateless routing tier accepts requests and forwards them to the correct shard.
• Shard map service: used when directory sharding is in place or when shard topology can change.

Design for fast shard lookups, cache shard maps, and handle map changes (versioning, TTLs).

Rebalancing and resharding

• Resharding approaches:

  • Offline migration: copy data to new shards and switch traffic (good for low-traffic windows).
  • Online rebalancing: split/merge ranges or move virtual nodes while routing both versions.
  • Consistent hashing with virtual nodes: reduces amount of data moved when N changes.

• Important considerations: maintain correctness during migration, keep reads/writes consistent, and monitor lag.

Tradeoffs and how to mitigate them

• Complexity: orchestration, migration, shard map management. Mitigate with automation and clear operational runbooks.
• Cross-shard queries / joins: expensive or impossible. Mitigate with data denormalization, fan-out reads, or application-level joins.
• Transactions & consistency: distributed transactions across shards are costly. Prefer single-shard transactions, or use compensating workflows and idempotency.
• Hotspots: choose keys that spread load (or use request routing to avoid single hot shards). Consider write-back caches or throttling.

Quick interview checklist (what to say)

• State why a single node fails for writes.
• Propose sharding and justify your sharding key.
• Explain hash vs range vs directory and pick one with justification.
• Describe routing, shard map, and rebalancing plan.
• Call out tradeoffs and mitigation strategies.
• Mention monitoring, automation, and a fallback plan.

Closing note

Sharding is powerful but operationally heavy. In interviews show that you can reason about distribution, routing, resharding, and the real tradeoffs—don’t just say "shard by userId"; explain how and why, and how you’ll handle failures and growth.

#SystemDesign #SoftwareEngineering #TechInterviews