Describes when a single database becomes a bottleneck and compares replication and sharding to scale reads and writes
Database sharding is a fundamental concept in large-scale database design and a frequent system-design interview topic. Before jumping into sharding strategies, it helps to recognize the real-world signals that a single database is no longer sufficient.
Scenario: John and Alan launch Chirp, a simple social app where users sign up, post short public messages, and follow each other.
Day 1: A few hundred users — the app runs on a single application server and a single database.
Behavior: Taps on Send persist posts synchronously; profiles and posts are read from the same database.
Focus: Early-stage teams optimize for user acquisition, not scaling.
To know when to shard, first understand what the database is doing. Chirp uses two primary tables:
Users — one row per user (username, follower count, profile metadata).
chirps — one row per post, including author and timestamps.
The database workload reduces to two types of operations: reads (profile views, feed reads) and writes (posts, follows, likes). As the user base grows — 200 → 2,000 → 200,000 → millions — the simple single-node database becomes a bottleneck even as the team repeatedly upgrades to larger instances.One visible symptom of this bottleneck is slow reads. An operation that used to take ~30 ms can degrade to multiple seconds because read queries queue behind heavy write or transactional load.
A common mitigation is adding replicas (read replicas). Replicas are machines that hold copies of the primary database’s data and serve two main purposes:
High availability — a replica can take over if the primary fails.
Read scaling — route read-only queries to replicas to reduce load on the primary.
Because replicas contain the same data, they can answer reads just like the primary. Distributing read traffic across replicas lowers read latency and frees the primary to focus on writes.
Replicas improve read throughput and availability, but they do not by themselves increase write throughput. Replication can be synchronous or asynchronous; most production systems use asynchronous replication, which introduces replication lag and potential temporary inconsistencies between primary and replicas.
The trickier problem is write throughput. High-volume applications like Chirp can receive tens of thousands of writes per minute (posts, likes, follows), often concentrated in short bursts. As write volume grows, write latency increases and writes may begin to fail or time out.Why can’t we spread writes across replicas like we do for reads? Because writes must maintain a single source of truth and strong consistency for many workloads. Consider a like-counter example:
Leo’s post has 99 likes.
Chris and Martin like the post simultaneously.
Chris’s like reaches the primary first; the primary updates the count to 100.
Martin’s like is applied to a replica that is still at 99 (replication lag) and increments to 100 locally.
The replica and primary both report 100, but the true total should be 101.
If multiple machines accepted writes independently without coordination, conflicting updates and lost increments would occur. To avoid this, production systems typically route all writes to the primary (the authoritative source). Replicas copy data from the primary asynchronously, which helps reads but leaves writes constrained to a single node.
As load increases, the single primary will eventually reach its write throughput limit. At that point:
Vertical scaling (bigger instance) is no longer cost-effective or possible.
Latency increases for both reads and writes.
The application suffers from reduced availability and poor user experience.
The next architectural step is horizontal partitioning (sharding): split the dataset across multiple independent database instances so that both reads and writes can be distributed. Sharding introduces complexity (routing logic, rebalancing, cross-shard transactions), but it is the standard solution when a single primary cannot handle the write load.Comparison: Vertical scaling vs Replication vs Sharding
Strategy
Primary Benefit
Limits / Trade-offs
Vertical scaling (bigger machine)
Simplicity; no application changes
Hardware limits, diminishing returns, expensive
Replication (read replicas)
Read throughput and HA
Does not increase write capacity; replication lag and eventual consistency
Sharding (horizontal partitioning)
Increases both read and write capacity by partitioning data
Added operational and application complexity; cross-shard transactions are harder
Sharding solves capacity limits but introduces operational complexity: shard key selection, resharding, cross-shard joins/transactions, and data rebalancing. Evaluate sharding only after exhausting vertical scaling and replication strategies, and plan migration carefully.
