Evaluation

In one line: the availability argument here is unusually strong — sharding gives fault tolerance for free, as a side effect of removing contention rather than as a separate mechanism.

Availability

A single counter for any feature (such as likes, views, or replies) is prone to a single point of failure. Sharded counters eliminate a single point of failure by running many shards for a particular counter. The system remains available even if some shards go down or suffer a fault.

Partial availability is meaningful here in a way it usually isn't

For most systems, losing a shard means losing access to the data on it. Here it means something much milder: the count is slightly low.

Because the total is a sum, a missing shard subtracts its portion rather than breaking the read. With 100 shards, losing one means the displayed count is roughly 1% low — which for a like count is genuinely invisible.

Compare with a sharded database: losing a shard makes some records completely unavailable, and there is no degraded mode. Here, degradation is smooth and proportional.

That is unusually forgiving, and it comes directly from the data being an aggregate of interchangeable parts. Lesson 3 noted increments are fungible; this is the same property paying off during failure.

Worth noting the design's framing: sharding was adopted for contention, and single-point-of-failure removal is a by-product. Rarely does one mechanism solve two problems this cleanly.

Scalability

Sharded counters allow high horizontal scaling as needed. Shards running on additional nodes can be easily added to the system to scale up our operation capacity. Eventually, these additional shards also increase the system's performance.

Scaling is per-counter, not fleet-wide — and that granularity is the real feature

Most scaling in this course is fleet-level: add nodes, everything gets more capacity.

Here it is per-counter. One viral tweet's counter can go from 4 shards to 400 while every other counter in the system stays at 4. The scaling is targeted at the hot object.

That granularity is exactly what the heavy hitters problem requires. Lesson 1 established that aggregate load is fine and per-key load is the problem — so a fleet-level scaling knob would be the wrong instrument entirely. You would be adding capacity everywhere to fix congestion in one place.

Sharded counters are a per-key scaling mechanism, which is rare and is precisely why they exist.

Reliability

Another primary purpose of the sharded counters is to reduce the volume of write requests by mapping each write to a specific shard. Each write request is handled as it arrives, and there are no requests waiting in the queue. As a result, the hit ratio and the system's reliability increase. Furthermore, the system periodically saves the computed counts in stable storage, such as Cassandra.

'No requests waiting in the queue' is the contention fix restated as a reliability property

Lesson 1's diagram showed the celebrity tweet's counter with a queue behind it — writes serializing and backing up. Removing that queue is the whole point.

The reliability consequence is worth spelling out, because a queue in front of a contended resource does not only add latency:

• Queued requests consume memory while they wait.
• Under sustained load the queue grows without bound — message-queue design's warning that a queue buys time, not capacity.
• Clients time out and retry, which adds more load to an already-saturated counter — a retry storm.

Eliminating the queue removes all three failure modes at once. So "no requests waiting" is not a performance nicety; it is what prevents a hot counter from becoming a cascading failure.

And periodically saving to stable storage is the durability half: shards may be in memory for speed, but the aggregated total is persisted, so a shard failure costs recent increments rather than the whole count.

Conclusion

Sharded counters are widely used in large-scale systems to improve performance under high write contention. They increase write scalability and reduce hot-key contention, which improves system stability under load. Sharded counters mitigate hot-key bottlenecks in heavy-hitter scenarios and serve as a building block for Top-K style analytics in large-scale systems.

What sharded counters cannot do — worth volunteering

• No read-then-write. Anything that branches on the value — inventory, balances, thresholds that trigger actions — needs a transaction, not a sharded counter. This is the disqualifying test from Lesson 6.
• No exact value at any instant. The sum is a value the counter passed through, and the cached aggregate is stale by up to one aggregation interval.
• No enforceable floor. Individual shards can go negative and you cannot check a global minimum at write time (Lesson 3).
• Reads are only cheap because of caching. Remove the periodic aggregation and read amplification returns in full, worsened by cross-region fan-out.
• The initial shard estimate is a prediction from proxies, made before any engagement signal exists — and it fails in both directions.
• Local Top-K merges are approximate — a hashtag ranking 11th in every region is invisible globally (Lesson 7).

Where this fits among the building blocks

Sharded counters are the most narrowly scoped block in this module — a single data structure rather than a subsystem — and also the most broadly reusable. They appeared as the answer to a hot-key problem in the Distributed Cache, Distributed Messaging Queue, Rate Limiter, and Pub-Sub chapters before getting a chapter of their own.

The generalizable idea is worth carrying into the system design chapters ahead: when one key takes too much write traffic, the fix is always to make it several keys and pay to recombine them. The variations are only in how you choose among them (Lesson 5), when you recombine (Lesson 6), and how you size the split (Lesson 4).

That third row is the underrated property: because the total is a sum of independent slots, losing one shard produces an undercount, not an outage. Most designs would call that data loss; here it degrades gracefully, which is exactly why the structure suits a metric nobody needs to be exact.

Interview signal by level

Next: the whole design under interview conditions.