A tiny number under a photo hides one of the more interesting engineering problems in large-scale software.

Picture a number sitting quietly under a photo: 42,318 likes. It looks like the simplest thing on the entire screen — smaller than the photo, smaller than the caption, smaller than the comment box. And yet, behind that one small number sits one of the more interesting engineering problems in large-scale software: how do you count something that millions of people are changing at the exact same instant, and show a number that still feels accurate, still feels instant, and never brings the rest of the app to a crawl?

To understand why this became a genuine engineering discipline of its own, it helps to look back at how “like” counts evolved. In the early web, a “count” usually meant a simple number stored in one row of one table — a hit counter on a personal homepage, a view count on a forum post. If ten people visited a page in a minute, the database happily ran ten small updates and nobody noticed the cost. That model worked because traffic was small and slow, and because nobody was watching the number update live in front of them, second by second, waiting for it to move.

Then came social platforms at global scale. Facebook introduced the “Like” button in 2009, and almost overnight, a feature that seemed cosmetic became one of the highest-traffic write paths in the company’s entire infrastructure. Twitter’s retweet and favorite counts, YouTube’s view counter, Instagram’s like counter, TikTok’s counts for likes, shares, and comments — all of them turned a “small number on the screen” into a distributed systems problem touching caching, databases, message queues, and real-time delivery pipelines, all operating at a scale most engineers never encounter anywhere else in their careers.

What makes this problem genuinely interesting — and a favorite in system design interviews — is that it sits exactly at the crossroads of several classic distributed systems tensions: extremely high write volume against a single logical value, the trade-off between exact correctness and speed, and the challenge of pushing updates to millions of open connections in real time rather than making every client repeatedly ask “has it changed yet?” Solving it well requires touching almost every layer of a modern backend stack, which is exactly why this tutorial walks through it layer by layer, the same way you’d walk through it on a whiteboard in an actual interview or an actual design review. By the end, the goal is not just to remember one specific architecture, but to internalize the reasoning that produces it, so a genuinely new, unfamiliar system design question still feels approachable using the same underlying habits of thought.

1.1 A Short History of Like & Share Counters

Before drawing a single box, sit with why this problem is actually hard — the difficulty appears only once you consider scale and traffic shape.

Before drawing a single box on a diagram, it’s worth sitting with why this problem is actually hard. On the surface it looks trivial — increment a number, show a number. The difficulty appears only once you consider the scale and the shape of the traffic.

2.1 The Hot-Key Problem

Imagine a global celebrity posts a photo. Within minutes, tens of thousands of people are tapping “like” on that exact same post, all targeting the exact same counter. In distributed systems terms, this single post_id becomes a hot key — one specific piece of data receiving a disproportionate share of all traffic. A normal system, sized for average load, can handle millions of different keys receiving modest traffic each. It struggles badly when one single key receives more traffic than an entire average day’s worth of other keys combined.

2.2 Read-Heavy AND Write-Heavy, At the Same Time

Most systems you design lean one way — read-heavy (a product catalog) or write-heavy (a logging pipeline). A like/share counter is unusual because it’s brutally heavy on both sides simultaneously. Every viewer of the post issues a read (show me the current count). Every tap of the like button issues a write. On a viral post, you might see hundreds of thousands of reads per second and tens of thousands of writes per second, on the very same piece of data, at the very same moment.

2.3 Exact Correctness vs. Real-Time Feel

Here’s the twist that makes this a genuinely interesting design problem rather than a plumbing exercise: users do not actually need the exact, perfectly accurate count at every millisecond. Nobody double-checks whether a post has 42,318 or 42,321 likes. What they do need is a number that feels alive — one that visibly climbs while they’re watching, and one that is eventually, provably correct for anything downstream that actually depends on the true value (billing for sponsored engagement, analytics dashboards, content ranking algorithms, abuse detection). This gap between “must feel instant and always-moving” and “must eventually be exactly correct” is the single most important design insight in this whole problem, and nearly every architectural decision that follows flows from it.

2.4 Fan-Out to Millions of Simultaneous Viewers

It’s not enough to update a number correctly on the backend. Millions of people might be looking at the very same post at the very same time — during a live stream, a breaking news event, or a viral moment. Every one of those viewers expects their screen to update without refreshing the page. Pushing a single incrementing number to millions of open client connections, without hammering your servers, is its own significant distributed systems challenge, closely related to the “fan-out” problem seen in chat systems and live sports score apps.

2.5 Back-of-Envelope Math

It’s worth walking through rough numbers out loud, because interviewers consistently reward candidates who can reason quantitatively rather than only qualitatively. Suppose a single viral post receives 50,000 likes in one minute at its absolute peak. That works out to roughly 833 writes per second sustained, with short bursts likely running several times higher during the first few seconds after a post is shared by a major account. If a hundred thousand people are simultaneously viewing that post’s live count, and the system pushed a raw update on every single increment, that’s 833 events per second multiplied by 100,000 viewers — over 83 million individual delivery operations per second, for one single post. That number alone explains why naive “broadcast every increment to every viewer” designs are unworkable, and why both batching on the write side and throttling on the delivery side aren’t optional extras — they’re the only reason this system can exist at all.

Scale that single-post scenario across an entire platform running many such moments concurrently — a major sporting event, an awards show, breaking news — and aggregate write volume across the whole platform can reasonably reach tens of millions of engagement events per second. No single database, however well-tuned, absorbs that volume through direct per-event writes; the entire architecture that follows in this tutorial exists specifically to make that number tractable.

Pin down requirements out loud, before touching architecture — interviewers reward this deliberately.

Every good system design starts by pinning down requirements out loud, before touching architecture. Interviewers reward candidates who do this deliberately rather than jumping straight to boxes and arrows.

3.1 Functional Requirements

• Users can “like” or “unlike” a post, and “share” a post, from any client (web, mobile app, third-party embed).
• Every viewer of a post sees a like/share count, and that count updates live, without the user manually refreshing.
• The system supports posts ranging from near-zero engagement to hundreds of millions of likes over their lifetime.
• A user’s own like/unlike state is reflected correctly on their own client (their heart icon fills in, and stays filled in after a refresh).
• Historical, exact counts are available for analytics, billing, and audit purposes, even if the live-facing number is approximate at any given instant.

3.2 Non-Functional Requirements

Never let a single user action touch the primary database directly — the core idea threading through the whole design.

With requirements agreed, we can lay out the major building blocks. The core idea threading through the whole design: never let a single user action touch the primary database directly. Instead, every like or share becomes a lightweight event that flows through a fast in-memory layer, gets aggregated, and only occasionally, in batches, touches durable storage.

4.1 Component Breakdown

Zoom into how each piece actually behaves internally — the interesting engineering lives in these details.

Let’s zoom into how each piece actually behaves internally, because the interesting engineering lives in these details, not just in the boxes-and-arrows diagram.

5.1 Step 1: Client Sends the Like Action

When a user taps the heart icon, the client optimistically updates its own UI immediately — the heart fills in, the number increments locally by one — before waiting for any server confirmation. This is called optimistic UI update, and it’s why liking a post feels instantaneous even on a slow network. The actual network request happens in the background, and if it ultimately fails, the client quietly rolls the UI back and can show a subtle retry or error state.

5.2 Step 2: API Gateway Validates and Routes

The request carries an auth token (validated against a session or JWT service) and hits a rate limiter tuned per-user, to block abusive scripts that might try to like the same post thousands of times per second. Assuming it passes, it’s routed to an available instance of the Like/Share Service.

5.3 Step 3: Idempotency Check

Networks are unreliable — a client might retry a request that actually succeeded the first time, or a double-tap might slip through. The service checks a fast idempotency cache keyed by something like user_id + post_id + action_type. If that exact action was already recorded in the last few seconds, the request is safely deduplicated and simply returns success without re-processing.

5.4 Step 4: Event Published to the Stream

Instead of writing to a database, the service publishes a tiny event — essentially {post_id, user_id, action: "like", timestamp} — onto a partitioned event stream. Events for the same post_id are routed to the same partition, which preserves ordering for that post and lets a single consumer instance own the aggregation for it.

5.5 Step 5: Aggregation Service Consumes in Micro-Batches

Rather than processing one event at a time (which would recreate the exact hot-row problem we’re trying to avoid), the aggregation service reads small batches of events — say, every 50–200 milliseconds, or every N events, whichever comes first — and applies a single atomic increment-by-N operation to the counter cache. This turns potentially tens of thousands of individual increments per second into a much smaller number of batched operations.

5.6 Step 6: Sharded Cache Update

For an average post, one Redis key holding the count is plenty. For a viral post receiving extreme write volume, the counter itself is split into multiple shards (for example, post:123:shard:0 through post:123:shard:15), and the true count is the sum across shards. Writes are spread evenly across shards (often by hashing the user_id), and reads sum them together, dramatically reducing contention on any single key.

5.7 Step 7: Periodic Durable Flush

On a fixed interval (for example every 5–10 seconds) or after a threshold number of increments, the aggregation service writes the accumulated delta to the durable database, alongside a checkpoint marking which stream offset has been safely persisted. This keeps the database write rate low and predictable, regardless of how bursty the live traffic is.

5.8 Step 8: Fan-Out to Live Viewers

Whenever the aggregation service updates a counter meaningfully (not necessarily on every single micro-batch, often throttled to something like once per second per post), it emits a small delta event to a pub/sub channel scoped to that post. Any WebSocket gateway instance with clients subscribed to that post_id receives the delta and pushes it down to those open connections.

The full lifecycle of a single like, end to end — one of the most common things an interviewer will ask you to draw.

It helps to see the full lifecycle of a single like, end to end, as a sequence — this is also one of the most common things an interviewer will ask you to draw on a whiteboard.

6.1 Read Path Lifecycle

The read path is deliberately simpler and shorter, because reads vastly outnumber writes and every extra hop adds latency multiplied by an enormous number of requests.

1. Client requests a post’s initial data (including its like/share count) — usually served from a CDN or edge cache for the first paint.
2. Client opens a persistent connection (WebSocket or SSE) and subscribes to live updates for the posts currently visible on screen.
3. As count-delta events arrive, the client updates the displayed number directly, without any further network request per update.
4. If the persistent connection drops, the client falls back to periodic polling with exponential backoff, or reconnects and re-syncs the latest count from the read API.

Several classic and modern data structures make this system possible at scale — and knowing when each is the right tool.

Several classic and modern data structures make this system possible at scale. Understanding them — and, crucially, when each one is the right tool — is often the difference between a good and a great interview performance.

7.1 Sharded Counters

The single most important pattern in this whole system. Instead of one counter per post, maintain N counters per post (say, 16 or 32), and route each increment to one shard using a hash of the acting user’s ID (or a random shard, or round-robin). The true count is the sum of all shards. This spreads write contention across N independent pieces of memory instead of one, turning a single hot key into N warm keys.

public class ShardedLikeCounter {

    private static final int SHARD_COUNT = 16;
    private final RedisClient redisClient;

    public void incrementLike(String postId, String userId) {
        int shard = Math.floorMod(userId.hashCode(), SHARD_COUNT);
        String key = "post:" + postId + ":likes:shard:" + shard;
        // Atomic operation - no read-modify-write race condition
        redisClient.incrBy(key, 1);
    }

    public long getTotalLikes(String postId) {
        long total = 0;
        for (int shard = 0; shard < SHARD_COUNT; shard++) {
            String key = "post:" + postId + ":likes:shard:" + shard;
            String value = redisClient.get(key);
            total += (value != null) ? Long.parseLong(value) : 0L;
        }
        return total;
    }
}

7.2 CRDTs — Conflict-free Replicated Data Types

In a multi-region deployment, you may have counter replicas in the US, Europe, and Asia, each accepting local writes for lower latency, and periodically syncing with each other. A plain integer counter doesn’t merge safely across regions — if both regions think the count is 100 and each adds 5 independently, naively merging by picking one region’s value loses the other’s updates. A G-Counter (grow-only counter), a well-known CRDT, solves this elegantly: each region maintains its own independent counter, and the true global value is always the sum of all regions’ counters. Merging two replicas is as simple as taking the element-wise maximum of shared state, or in this simplified case, summing per-region values — the structure guarantees replicas converge to the same correct total regardless of the order updates arrive in.

7.3 HyperLogLog — For Unique Counts, Not Raw Counts

Worth mentioning as a related, frequently confused concept: if the requirement were “count of unique users who liked this post” rather than a running total, and you needed to do it with minimal memory across billions of entries, HyperLogLog is the classic probabilistic data structure — it estimates cardinality (distinct count) using a small, fixed amount of memory, with a small, well-understood error margin (typically under 2%). It’s not the right tool for a simple additive like-counter, but interviewers sometimes probe whether you can distinguish “counting total events” from “counting unique participants,” and HyperLogLog is the right answer for the latter.

7.4 Sliding Window Counters

Useful for a secondary but related requirement: showing “trending” or “likes in the last hour” rather than lifetime totals. A sliding window counter (or its simpler cousin, fixed time-bucketed counters, e.g., one counter per minute, summed over the last 60 buckets) lets you answer “how much activity recently” without storing and scanning every individual event.

7.5 Data Structure Summary

At the heart of every counter bug lies a concurrency mistake — getting this right is non-negotiable at scale.

8.1 The Read-Modify-Write Trap

The classic bug: reading a value, adding one in application code, then writing it back. Under concurrency, two threads (or two servers) can both read the same starting value, both add one, and both write back the same result — silently losing one increment. This is a textbook race condition, and it’s exactly why every operation described earlier uses atomic primitives instead.

// WRONG - race condition under concurrency
public void unsafeIncrement(String key) {
    long current = redisClient.get(key);   // read
    long updated = current + 1;             // modify
    redisClient.set(key, updated);          // write - can overwrite a concurrent update
}

// RIGHT - atomic operation, safe under any concurrency level
public void safeIncrement(String key) {
    redisClient.incrBy(key, 1);  // single atomic instruction at the Redis engine level
}

8.2 In-Process Concurrency: LongAdder Over AtomicLong

Within a single JVM instance of the aggregation service, when many threads are incrementing an in-memory counter before a batch flush, Java’s AtomicLong works correctly but can become a contention point under very high thread counts, because every thread competes for the same memory location via compare-and-swap. LongAdder (from java.util.concurrent.atomic) solves this by internally striping the counter across multiple cells, letting different threads update different cells and only summing them when the total is actually needed — trading a little memory and summation cost for dramatically better write throughput under contention.

import java.util.concurrent.atomic.LongAdder;
import java.util.concurrent.ConcurrentHashMap;

public class InMemoryBatcher {

    private final ConcurrentHashMap<String, LongAdder> pendingDeltas = new ConcurrentHashMap<>();

    public void recordLike(String postId) {
        pendingDeltas
            .computeIfAbsent(postId, id -> new LongAdder())
            .increment();
    }

    // Called on a fixed schedule, e.g. every 200ms
    public void flushToCache(RedisClient redis) {
        pendingDeltas.forEach((postId, adder) -> {
            long delta = adder.sumThenReset();
            if (delta != 0) {
                redis.incrBy("post:" + postId + ":likes", delta);
            }
        });
    }
}

8.3 Optimistic vs. Pessimistic Locking

Pessimistic locking (acquiring a lock before every write) guarantees correctness but throttles throughput to whatever a single lock can sustain — exactly wrong for this workload. Optimistic approaches (atomic compare-and-swap, or simply relying on the atomicity guarantees of operations like Redis’s INCR) avoid ever blocking a writer, which is why virtually every high-throughput counter system in production leans optimistic and atomic rather than lock-based.

8.4 Networking Considerations at Connection Scale

Concurrency isn’t only about threads inside a single process — it’s also about how the network layer behaves under millions of simultaneous, long-lived connections. A few networking details matter more here than in most systems you’ll design:

• TCP connection overhead: each WebSocket connection consumes a file descriptor and kernel-level socket buffer on the server holding it. Operating system tuning (raising file descriptor limits, tuning TCP keepalive intervals) becomes a genuine, practical concern once a single gateway node approaches tens of thousands of open connections.
• HTTP/2 multiplexing: for clients using Server-Sent Events or polling fallbacks, HTTP/2’s ability to multiplex many logical streams over a single TCP connection reduces per-connection overhead compared to older HTTP/1.1 approaches that typically required one connection per request stream.
• Keepalive and idle timeout tuning: WebSocket connections that sit idle (a user has the app open but isn’t actively scrolling) still need periodic keepalive pings to survive intermediate proxies and load balancers that silently drop connections after a period of inactivity — getting this interval wrong either wastes bandwidth on unnecessary pings or causes connections to drop unexpectedly.
• Connection draining during deploys: when a gateway node is being taken out of rotation for a deployment, existing connections should be drained gracefully (clients told to reconnect elsewhere) rather than abruptly severed, avoiding a visible glitch for users mid-session.

No serious conversation about a distributed counter is complete without explicitly placing the design on CAP.

No serious system design conversation about a distributed counter is complete without explicitly placing the design on the CAP theorem. CAP theorem states that under a network partition, a distributed system must choose between Consistency (every read sees the latest write) and Availability (every request gets a response, even if it’s not the absolute latest data).

9.1 Where This System Sits

The visible like/share count deliberately chooses AP (Availability + Partition tolerance) over strict consistency. If a cache shard is temporarily unreachable, it’s far better for users to see a slightly stale count than to see an error or a frozen page. The system is explicitly designed around eventual consistency: given enough time without new writes, every replica of the counter will converge to the same correct value, even though at any single instant different users might briefly see slightly different numbers.

However, the underlying event log (the durable, ordered stream of every like/unlike/share event) is treated with much stronger guarantees, because it’s the source of truth for billing, analytics, and dispute resolution. That layer favors CP (Consistency + Partition tolerance) — better to briefly reject or delay a write than to silently record it incorrectly or lose it.

9.2 Consistency Levels in Practice

9.3 Consensus and Leader Election Under the Hood

It’s easy to treat Redis and Cassandra as black boxes, but understanding what happens internally during a failure builds real credibility in an interview. Redis, when deployed with Sentinel or Redis Cluster for high availability, uses a consensus-like voting mechanism among Sentinel nodes to detect a failed primary and agree on which replica should be promoted — a lightweight relative of the same leader-election problem solved more rigorously by algorithms like Raft and Paxos in systems like etcd or ZooKeeper. Cassandra takes a different approach entirely: rather than electing a single leader, it uses a gossip protocol, where nodes continuously exchange state information with a few random peers, letting membership and health information propagate through the whole cluster without any central coordinator — a design choice that favors availability and horizontal scale over the stronger coordination guarantees a Raft-based system provides.

Why does this distinction matter for a counter system specifically? Because it explains why different components in this architecture recover differently from failure. A Redis Sentinel failover involves a brief window (often a few seconds) where writes to the affected shard may be rejected or delayed while a new primary is elected and agreed upon — exactly the kind of short, bounded unavailability the write-behind, queue-buffered design is built to absorb gracefully. Cassandra’s gossip-based membership, by contrast, tends to degrade more gradually under partial failure, continuing to serve reads and writes from unaffected nodes even while the cluster is still converging on the current membership state.

Caching isn’t bolted on afterward — it’s the primary mechanism that makes the whole system work.

Caching isn’t an optimization bolted on afterward here — it’s the primary mechanism that makes the whole system work. Almost every read and the vast majority of writes touch cache, not the database.

10.1 Write-Behind (Write-Back) Caching

The aggregation service updates the fast cache (Redis) immediately and synchronously, but writes to the durable database asynchronously, in batches, on a delay. This is called write-behind caching: the cache is updated first, and the slower, durable store catches up afterward. It maximizes write throughput at the cost of a short window where the cache is “ahead” of the durable store — acceptable here because the event stream guarantees no data is lost even if the flush is delayed.

10.2 Multi-Layer Caching

10.3 Cache Invalidation and TTL Strategy

Because staleness is tolerated by design, this system leans on time-based expiration rather than complex invalidation logic. A summed, cached total (across shards) might carry a 1–2 second TTL. Edge/CDN caches might carry a slightly longer TTL for very hot, extremely high-traffic posts, deliberately trading a bit more staleness for a bit less origin load — a classic, well-understood engineering trade-off rather than an oversight.

10.4 Cache Warm-Up and Cold Starts

When a Redis node restarts or a new shard is added, counters temporarily show as zero or missing unless mitigated. Production systems handle this with a fast recovery path: on cache miss, fall back to reading the last known durable value from the database, seed the cache with it, and let live increments continue from there — never showing a like count that appears to have reset to zero, which would look like a visible bug to users.

The durable store exists for a different purpose than the cache: not speed, but truth.

The durable store exists for a different purpose than the cache: not speed, but truth. It needs to survive restarts, support analytics queries, and provide an auditable history.

11.1 Choosing the Database Type

A wide-column store like Cassandra or a managed NoSQL store like DynamoDB is a strong fit here, for a few concrete reasons: both scale horizontally by partitioning on a key (naturally, post_id), both support very high write throughput for append-style workloads, and both let you tune consistency per-operation (e.g., DynamoDB’s eventually-consistent vs. strongly-consistent reads) rather than forcing one model everywhere.

11.2 Schema Design

-- Aggregated, current-truth counters (one row per post)
CREATE TABLE post_counters (
    post_id       TEXT PRIMARY KEY,
    like_count    BIGINT,
    share_count   BIGINT,
    last_updated  TIMESTAMP,
    version       BIGINT   -- optimistic concurrency marker
);

-- Append-only event ledger (source of truth for audits/billing)
CREATE TABLE like_events (
    post_id       TEXT,
    event_id      UUID,
    user_id       TEXT,
    action        TEXT,      -- 'like' | 'unlike' | 'share'
    event_time    TIMESTAMP,
    PRIMARY KEY (post_id, event_time, event_id)
) WITH CLUSTERING ORDER BY (event_time DESC);

Notice the two-table split: post_counters holds the cheap-to-read aggregated number, while like_events holds the full, granular, append-only history. This separation — a fast summary table plus a detailed event log — is a recurring pattern anywhere aggregation and auditability both matter.

11.3 Partitioning Strategy

Partitioning by post_id is the natural choice — it keeps all data for one post together, which is exactly what both the read path (show this post’s count) and write path (aggregate this post’s events) need. The one risk is the same hot-key problem discussed earlier: a single viral post’s partition can receive disproportionate traffic even at the database layer. Some systems mitigate this with a compound partition key like post_id + time_bucket, spreading a single post’s events across multiple partitions over time.

11.4 Hash Partitioning vs. Range Partitioning

Two broad strategies exist for distributing data across nodes, and the choice matters for this workload specifically. Hash partitioning applies a hash function to the partition key (here, post_id) and uses the result to determine which node owns that data — this distributes load evenly and predictably across the cluster regardless of the actual key values, which is exactly what you want when you can’t predict in advance which post_id is about to go viral. Range partitioning, by contrast, assigns contiguous ranges of keys to specific nodes (useful for range-scan queries, like “give me all events between these two timestamps”), but risks concentrating load on one node if traffic clusters within a narrow key range — a real danger if post_ids were assigned sequentially and recent posts (which naturally receive more engagement) all hashed to nearby ranges. For this reason, counter systems overwhelmingly favor hash partitioning for the primary counter table, sometimes combined with range partitioning on a secondary dimension (like time) for the event ledger, where efficient time-range queries genuinely matter for analytics.

11.5 Replication Factor and Quorum Reads/Writes

Both Cassandra and DynamoDB let you tune a replication factor (commonly 3, meaning each piece of data lives on three separate nodes) and a consistency level per operation — for example, requiring a write to be acknowledged by a quorum (majority) of replicas before returning success. For the durable ledger, a quorum write (e.g., 2 out of 3 replicas) strikes a practical balance: it survives a single node failure without data loss, while avoiding the latency cost of waiting for every single replica to acknowledge on every write.

11.6 Avoiding Write Amplification

Because the aggregation service batches updates before writing, the database sees perhaps one write every 5–10 seconds per active post, rather than one write per individual like. For a post receiving 10,000 likes per second, that’s the difference between roughly 10,000 database writes/sec and roughly 0.1–0.2 writes/sec for that post — a reduction of multiple orders of magnitude, and the single biggest factor making this design viable at scale.

Counting correctly on the backend solves only half the problem — the other half is pushing that number to every screen.

Counting correctly on the backend solves only half the problem. The other half is pushing that updated number to every screen currently displaying the post — potentially millions of devices — without asking each one to repeatedly ask “anything new?”

12.1 Polling vs. Long Polling vs. WebSockets vs. SSE

For this system, a common production choice is WebSockets for actively engaged users (someone scrolling a feed, watching a live video) combined with polling or SSE as a fallback for clients on restrictive networks or older devices that don’t support persistent WebSocket connections well.

12.2 The Fan-Out Challenge

A single viral post might have a million people simultaneously subscribed to its live updates. No single server holds a million open connections efficiently on its own, so the WebSocket layer is horizontally scaled across many gateway nodes, each holding a slice of the total connections. The hard part is: when the counter updates, how does the update reach the correct subset of gateway nodes holding the relevant subscriptions?

Every WebSocket gateway node subscribes to the pub/sub topics matching the posts its connected clients care about. When a delta event is published, every relevant gateway node receives it independently and forwards it only to its own locally connected, subscribed clients. This design means gateway nodes never need to know about each other directly — the pub/sub layer handles all the coordination.

12.3 Throttling Update Frequency

Pushing an update on literally every single increment would flood connections and waste bandwidth on updates too small to notice visually. Production systems throttle broadcast frequency — for example, at most once per second per post, or only when the count crosses a meaningful threshold — batching many small increments into one broadcast update. Users still perceive the number as “live” because a 1-second cadence feels instantaneous to a human, while dramatically cutting the actual message volume.

public class ThrottledBroadcaster {

    private final Map<String, Long> lastBroadcastTime = new ConcurrentHashMap<>();
    private static final long MIN_INTERVAL_MS = 1000;

    public void maybeBroadcast(String postId, long currentCount, PubSubClient pubSub) {
        long now = System.currentTimeMillis();
        long last = lastBroadcastTime.getOrDefault(postId, 0L);

        if (now - last >= MIN_INTERVAL_MS) {
            pubSub.publish("post:" + postId + ":count", currentCount);
            lastBroadcastTime.put(postId, now);
        }
        // If a broadcast is skipped, the next scheduled tick will catch up
        // with the latest count, so no update is permanently lost.
    }
}

Every component in this architecture is designed to scale horizontally — no single machine could keep up at this traffic scale, regardless of its size.

Every component in this architecture is designed to scale horizontally — adding more machines rather than relying on ever-bigger single machines — because at this traffic scale, no single machine could keep up regardless of its size.

13.1 Horizontal Scaling of the Like Service

The Like/Share Service is intentionally stateless: any instance can handle any request, because idempotency and business state live in shared external stores (Redis, the event stream), not in the process itself. This means it scales trivially — a load balancer distributes traffic across as many instances as needed, and an autoscaler adds or removes instances based on request rate or CPU utilization.

13.2 Load Balancing Strategies

13.3 Partitioning the Event Stream

Kafka (or a similar system) partitions the like/share event topic by post_id, ensuring all events for one post land on the same partition and are processed in order by a single consumer at a time — critical for the aggregation logic to work correctly without needing distributed locks. The number of partitions determines the maximum parallelism of the aggregation layer, so it’s chosen generously up front (partitions are far easier to add than to safely reduce later).

13.4 Autoscaling Under Bursty Load

Traffic on this kind of system is inherently spiky — a normal Tuesday afternoon looks nothing like the minute after a celebrity posts something or a sports match ends. Autoscaling policies here typically react to leading indicators (queue depth in the event stream, CPU on aggregation instances, connection count on gateway nodes) rather than lagging indicators alone, so new capacity comes online before a backlog builds up rather than after users already notice degraded performance.

13.5 Reference Numbers

A slightly stale count is fine. Errors or a frozen feed are not.

A “like” counter feature failing outright — showing errors, or freezing the entire feed — is far worse for user trust than showing a count that’s a few seconds stale. Every design decision in this section optimizes for graceful degradation over perfect correctness.

14.1 Replication

The Redis cluster holding sharded counters runs with replicas per shard (typically one primary plus one or more replicas), so a single node failure doesn’t lose recently-written counter state — a replica is promoted automatically, and clients reconnect transparently. The durable database (Cassandra/DynamoDB) similarly replicates data across multiple nodes and, ideally, multiple availability zones, so a zone outage doesn’t take down the source of truth.

14.2 Failure Recovery

If the aggregation service crashes mid-batch, it hasn’t lost any data — because it processes events from the durable, replayable event stream, it simply resumes from its last committed offset on restart, reprocessing any events it hadn’t yet acknowledged. This is why an idempotent design matters even at the aggregation layer: reprocessing the same event twice after a crash (a rare but possible “at-least-once” delivery scenario) should never double count.

14.3 Graceful Degradation

14.4 Multi-Region Disaster Recovery

For platforms operating globally, an entire region can fail — a data center outage, a cloud provider incident. A resilient design runs active deployments in multiple regions, with cross-region replication of the durable ledger and CRDT-based counter merging (as discussed earlier) so users can be failed over to a healthy region without losing engagement data or requiring complex reconciliation logic after the fact.

14.5 Backup and Audit

The append-only event ledger doubles as a natural backup mechanism — because it records every individual action with a timestamp, the aggregated counter can always be recomputed from scratch by replaying the ledger, providing a strong disaster-recovery guarantee and a clean audit trail for disputes (for example, if a brand disputes an engagement count used for advertising billing).

14.6 Running Disaster Recovery Drills

A recovery plan that’s never been tested is, in practice, only a hypothesis. Mature teams operating a system at this scale run scheduled disaster-recovery drills — deliberately failing over traffic from a primary region to a secondary one, or restoring the durable counter store from a ledger replay, on a regular cadence, during business hours, with engineers actively observing the process. These drills routinely surface gaps that look fine on paper but fail in practice: a runbook referencing an outdated command, a replay job that takes far longer than expected under real data volumes, or a failover that technically succeeds but produces a brief spike in error rates nobody had accounted for. Treating recovery as a rehearsed, practiced procedure rather than a one-time design decision is what actually determines whether a real incident, months later, resolves in minutes or drags on for hours.

A feature this simple-looking is, perhaps surprisingly, a common target for abuse — defenses baked in, not bolted on.

A feature this simple-looking is, perhaps surprisingly, a common target for abuse — fake engagement is a real business problem for social platforms, and the counting system needs defenses baked in, not bolted on.

15.1 Authentication and Authorization

Every like/share request must be tied to an authenticated user (via a session token or JWT validated at the API Gateway), preventing anonymous or spoofed likes. Authorization checks ensure a user can only like/unlike on their own behalf, never on behalf of another user_id passed in a request.

15.2 Rate Limiting and Bot Detection

A per-user, per-IP, and per-device rate limiter caps how many like/share actions can occur in a short window, blocking scripted bot accounts attempting to inflate a post’s engagement artificially. More sophisticated systems layer in behavioral signals — click timing patterns, device fingerprinting, account age and history — feeding a fraud-scoring model that can flag suspicious engagement for review or silent exclusion from public counts, without necessarily blocking the action outright.

15.3 Idempotency as a Security Boundary

The same idempotency mechanism that prevents accidental double-counting from network retries also blocks a certain class of abuse — rapid repeated taps or replayed requests attempting to inflate a count through duplication rather than genuine distinct actions.

15.4 Protecting Against DDoS

Because the like/share endpoint is public-facing and lightweight to call, it’s an attractive target for denial-of-service attempts aimed at overwhelming backend capacity. Standard defenses apply: a CDN/WAF layer in front of the API Gateway absorbing volumetric attacks, aggressive rate limiting at the edge, and circuit breakers within the service mesh that shed load gracefully rather than cascading failure into downstream systems.

15.5 Data Integrity for Billing-Relevant Engagement

Where like/share counts feed into anything with financial consequences (sponsored content payouts, creator monetization, ad performance metrics), the durable event ledger needs tamper-evidence — commonly achieved through write-once storage semantics, checksums, and restricted write access limited to the aggregation service’s service account, with all administrative overrides logged and auditable.

15.6 Encryption In Transit and At Rest

All client-to-server traffic, including the WebSocket connections carrying live count updates, should run over TLS, preventing eavesdropping or tampering on untrusted networks — a genuine concern given how often mobile clients connect over public Wi-Fi. Data at rest in the durable database and event stream should also be encrypted, both to satisfy common compliance requirements (SOC 2, GDPR-adjacent obligations around user activity data) and as defense-in-depth, so a storage-layer breach doesn’t directly expose raw engagement history. None of this adds meaningful latency at modern hardware-accelerated TLS speeds, so there’s rarely a good reason to skip it, even on purely internal service-to-service traffic within the same cluster.

Catch problems before users do, and understand normal vs. abnormal on ever-changing traffic patterns.

A system this central to user-facing experience needs deep observability — both to catch problems before users do, and to understand normal versus abnormal behavior on an ever-changing traffic pattern.

16.1 Key Metrics to Track

16.2 Logging Strategy

High-cardinality, high-volume events like individual likes should not be logged verbosely in a general-purpose logging system at full volume — the cost and noise would be enormous. Instead, structured, sampled logging captures a representative slice of events for debugging, while the full, authoritative record lives in the event stream and durable ledger, which are purpose-built for high-volume storage and later analysis.

16.3 Distributed Tracing

Because a single like touches several services (Gateway, Like Service, Event Stream, Aggregator, Cache, Pub/Sub, WebSocket Gateway), distributed tracing (using something like OpenTelemetry, with a trace ID propagated through every hop) is essential for diagnosing where latency or failures occur in a specific slow request, rather than guessing across a chain of loosely correlated logs.

16.4 Alerting

Alerts should be tuned around leading indicators — a growing event stream lag, a rising error rate on the durable flush, an unusual spike in rate-limit rejections — rather than only alerting after users are already visibly affected. Good alerting on this kind of system distinguishes between “a specific post’s shard is temporarily hot” (often self-resolving, log and watch) and “the aggregation service as a whole is falling behind” (page an engineer immediately).

16.5 SLOs and Error Budgets

Rather than chasing a vague notion of “as reliable as possible,” mature teams define explicit Service Level Objectives for this system — for example, “99.9% of like actions are reflected in the durable ledger within 30 seconds” or “the read API responds within 100ms at the 99th percentile for 99.95% of requests.” These targets translate directly into an error budget: a defined, tracked allowance for how much the system is permitted to miss its targets before it triggers a deliberate slowdown in new feature rollout to prioritize stability. Framing reliability this way turns an abstract goal into a concrete, trackable number that both engineering and product teams can reason about together, and it directly informs on-call alerting thresholds — alerts should fire when the error budget is being consumed unusually fast, not merely whenever any single request is slow.

A brilliant architecture poorly deployed still fails users.

How this system is deployed matters almost as much as how it’s designed — a brilliant architecture poorly deployed still fails users.

17.1 Multi-Region Deployment

For a global platform, running the entire stack (Like Service, aggregation, cache, database, WebSocket gateways) in multiple geographic regions reduces latency for users everywhere and provides resilience against regional outages. Users are routed to their nearest healthy region via geo-DNS or a global load balancer, with cross-region replication reconciling counters using the CRDT approach discussed earlier.

17.2 Containerization and Orchestration

Stateless components (Like Service, Aggregation Service, WebSocket Gateway) are natural fits for containerized deployment on Kubernetes or a similar orchestrator, enabling fast, automated horizontal scaling, rolling deployments with zero downtime, and self-healing when individual instances fail health checks.

17.3 Managed Cloud Services Mapping

17.4 Cost Optimization

The batching and aggregation strategy described throughout this tutorial isn’t only a performance optimization — it’s also directly a cost optimization, since database write operations and inter-service network calls are typically billed per-operation or per-throughput-unit in managed cloud services. Reducing millions of individual writes to a much smaller number of batched writes has a direct, often dramatic, impact on monthly infrastructure cost. Reserved or committed-use capacity for predictable baseline load, combined with autoscaling for bursts, further optimizes spend versus always provisioning for peak capacity.

Clean API design and clear service boundaries keep this maintainable as it grows.

Clean API design and clear service boundaries keep this system maintainable as it grows and as more engineers work on different parts of it.

18.1 API Design

POST /v1/posts/{postId}/like
Headers: Authorization: Bearer <token>
Response: 202 Accepted
{
  "status": "queued",
  "optimisticCount": 42319
}

DELETE /v1/posts/{postId}/like
Response: 202 Accepted

POST /v1/posts/{postId}/share
Response: 202 Accepted

GET /v1/posts/{postId}/counts
Response: 200 OK
{
  "postId": "123",
  "likeCount": 42318,
  "shareCount": 1204,
  "asOf": "2026-07-26T10:15:32Z"
}

WS /v1/realtime/subscribe
Subscribe message: { "postIds": ["123", "456"] }
Server push: { "postId": "123", "likeCount": 42340, "delta": 22 }

Notice the write endpoints return 202 Accepted rather than 200 OK — this deliberately signals to the client that the action has been durably queued for processing, but not necessarily fully reflected everywhere yet, an honest reflection of the system’s asynchronous, eventually-consistent design.

18.2 Microservice Boundaries

Each service owns a narrow, well-defined responsibility: the Like/Share Service only validates and publishes events; it knows nothing about caching internals or aggregation logic. The Aggregation Service only consumes events and maintains counters; it knows nothing about authentication or client connections. This separation lets teams scale, deploy, and even rewrite each service independently, as long as the contracts (event schema, API shape) stay stable.

18.3 gRPC for Internal Service-to-Service Calls

While the public-facing API is typically REST or GraphQL for broad client compatibility, internal service-to-service communication (e.g., between the Aggregation Service and internal analytics consumers) often uses gRPC for its lower serialization overhead and strongly-typed contracts via Protocol Buffers — a meaningful efficiency gain at the scale this system operates.

18.4 Event Schema Versioning

As the system evolves, the like/share event schema will need to change (new fields, new action types). Using a schema registry (common with Kafka deployments) and following backward-compatible evolution rules (only adding optional fields, never repurposing existing ones) prevents a schema change from breaking consumers that haven’t yet been updated — a subtle but important operational discipline at this scale.

Naming the patterns isn’t academic vocabulary — it signals every design choice was deliberate.

Naming the patterns at work here isn’t just academic vocabulary — being able to name a pattern precisely in an interview signals that a design choice was deliberate and well-understood, not accidental or copied without comprehension. Each pattern below solves a specific, identifiable problem encountered earlier in this tutorial, and recognizing which problem each one solves is more valuable than memorizing the pattern names themselves.

19.1 Patterns Used in This Design

19.2 Anti-Patterns to Avoid

Habits to build in — and the specific failure modes each one prevents.

20.1 Best Practices

• Always make counter increments atomic — never implement a manual read-then-write pattern for anything counting at scale.
• Design for idempotency from day one — retries, duplicate taps, and at-least-once delivery are inevitable, not edge cases.
• Separate the fast, approximate, user-facing number from the slow, exact, source-of-truth number — trying to make one number serve both purposes forces you into a bad compromise on both sides.
• Batch aggressively before touching durable storage — this single decision has the largest impact on both cost and scalability.
• Throttle real-time broadcasts to a human-perceivable cadence — sub-second precision is invisible to users and expensive to deliver.
• Plan for hot keys explicitly — assume some piece of content will receive wildly disproportionate traffic, and design sharding for that case, not just the average case.
• Instrument everything — event stream lag, cache hit ratio, and flush success rate are the earliest warning signs of trouble.
• Version your event schemas deliberately — a counting pipeline that runs for years will inevitably need new fields and new action types; backward-compatible schema evolution prevents a routine change from becoming an outage.

20.2 Common Mistakes

Where these exact patterns appear in production systems you already use every day.

Every design choice above trades something away — here they are, side by side.

This last point is worth emphasizing in an interview: a small application with modest traffic absolutely should not build this entire architecture on day one. The right answer to “how would you build this” always depends on scale — for a small app, a simple database counter with basic caching is the right, pragmatic choice, and this elaborate architecture is what you grow into as traffic genuinely demands it, not what every application needs from the start.

22.1 Key Trade-off: In-Memory Cache vs. Durable Store as the “Truth”

A system built for extreme bursts can’t be trusted until it’s actually been pushed past its limits deliberately.

A system built around handling extreme, unpredictable bursts can’t be trusted until it’s actually been pushed past its limits deliberately, under controlled conditions, before real users do it unexpectedly.

23.1 Load Testing for Hot-Key Scenarios

Standard load tests that spread traffic evenly across many keys won’t reveal hot-key problems at all — the whole point is to simulate the skewed, concentrated traffic pattern a real viral post produces. Effective load tests for this system deliberately generate a small number of extremely hot keys receiving the bulk of simulated traffic (a Zipfian or power-law distribution models real engagement patterns far better than a uniform one), while background traffic continues normally across thousands of other, cooler keys — verifying that a single hot post doesn’t degrade performance for everyone else on the platform.

23.2 Chaos Engineering

Deliberately injecting failure into a running system — killing a Redis node mid-traffic, introducing artificial network latency between the aggregation service and the event stream, forcing a WebSocket gateway node to restart under load — validates that the graceful-degradation behaviors described earlier actually work as designed, rather than only working in theory. Tools like Chaos Monkey (popularized by Netflix) or more targeted fault-injection frameworks let engineers run these experiments safely, on a schedule, rather than discovering failure modes for the first time during an actual outage.

23.3 Correctness Testing for Concurrency

Because so much of this system’s correctness depends on atomic operations behaving correctly under real concurrency, tests should include genuine concurrent-execution scenarios — many threads or processes hammering the same counter key simultaneously — verifying the final count exactly matches the expected total, not just testing the happy path with sequential, non-concurrent calls that would never actually expose a race condition even if one existed.

23.4 Practical Test Matrix

Because guaranteeing perfect real-time accuracy for a value being modified by thousands of concurrent writers, while also serving that value to millions of concurrent readers, requires exactly the kind of tight coordination that destroys both latency and availability at this scale. The small, momentary staleness in exchange for speed and resilience is a deliberate, well-reasoned trade-off, not a compromise born of laziness.

The idempotency layer and batching window absorb this gracefully — if a like and an unlike for the same user land in the same micro-batch, they net out to zero before ever reaching the counter, avoiding wasted writes and flicker in the displayed count.

The durable database holds the last successfully flushed aggregated value, and the append-only event ledger holds everything since. On recovery, the cache is reseeded from the database, and any events not yet reflected in that snapshot are replayed from the ledger, fully reconstructing an accurate count with no permanent data loss.

For most applications, yes — and that’s fine. This design is specifically for scale where a single post can realistically receive tens of thousands of writes per second and be viewed by millions simultaneously. Smaller platforms should start simple and adopt these patterns incrementally as specific bottlenecks actually appear, rather than building all of this preemptively.

The same core pattern generalizes directly — an event type, sharded atomic counters, batched aggregation, and throttled real-time broadcast work equally well for comments, views, shares, or any other high-volume engagement metric, typically as additional event types flowing through the same underlying pipeline rather than entirely separate systems.

Kafka’s partition-based ordering guarantees and very high sustained throughput make it especially well-suited to this workload’s need for per-post ordering at massive scale. RabbitMQ or similar brokers remain perfectly valid choices at more moderate scale, or where ordering-per-key isn’t as central a requirement — the underlying pattern matters more than the specific technology chosen.

There’s no fixed universal number — it’s tuned based on observed or predicted write throughput for that specific piece of content. Many production systems start every new post with a small default shard count (or even a single shard) and dynamically increase the shard count for a specific post once its write rate crosses a defined threshold, avoiding the wasted overhead of over-sharding the vast majority of ordinary posts that never receive extreme traffic.

Structurally, yes — shares flow through the same event-driven, sharded-counter pipeline. The main practical difference is that a share often triggers secondary side effects (the shared content appearing in another user’s feed, notifications firing) that likes typically don’t, which usually means the share event fans out to additional downstream consumers beyond just the counter aggregation service, using the same underlying event stream as the distribution backbone.

If only one idea survives the conversation, it should be this: recognize early that the visible number doesn’t need to be perfectly accurate at every instant, say that trade-off out loud, and then let every subsequent decision — batching, sharding, eventual consistency, throttled broadcasts — flow logically from it. Interviewers consistently rate candidates higher when they can articulate why a trade-off is being made, not just describe the resulting architecture from memory.

Designing a real-time like and share counter for millions of simultaneous users is deceptively deep — the feature looks trivial from the outside, but building it correctly at scale touches nearly every major distributed systems concept: atomicity and concurrency control, the CAP theorem and consistency trade-offs, caching layers and cache invalidation, event-driven architecture and stream processing, database partitioning, real-time fan-out delivery, and graceful degradation under failure. It’s also a genuinely useful lens for practicing system design thinking more broadly, because nearly every pattern used here — sharding a hot key, batching writes before durable storage, decoupling producers from consumers with a queue, throttling broadcast frequency, choosing consistency models per component rather than globally — reappears constantly across unrelated systems, from ride-sharing dispatch to stock-trading order books to multiplayer game state synchronization. Internalizing this one design deeply pays dividends well beyond the specific problem of counting likes.