Design Like Count for High Profile Users

The Hot Counter Problem

Tracking likes requires tracing the complete path from API ingress to displayed client counts. Hot key counter contention and write behind aggregation represent the core architectural pivots. When a high profile user publishes a viral update, 1M likes can arrive within 60 seconds. If every tap executes UPDATE posts SET like_count = like_count + 1, all write transactions target a single row. Row-level locks serialize these updates, exhausting the database connection and worker thread pools while causing cascading timeouts across unrelated services.

Celebrity publishes post: "Ronaldo scores goal" generates 1M likes/sec for 60 seconds

Naive relational approach:
  UPDATE posts SET like_count = like_count + 1 WHERE post_id = ?;

Cascading failure sequence under viral write load:
  1. 1M writes/sec target a single database row.
  2. Row-level lock contention forces database threads to serialize updates.
  3. Database thread and connection pools become completely exhausted.
  4. All other queries on the database slow down, triggering cascading timeouts.

Tiered Architecture: Normal vs Hot Posts

The system addresses hot key contention by segregating posts into distinct ingestion tiers based on write velocity. Normal posts use an exact user scoped Redis state transition and a low latency count path, while the durable event is persisted asynchronously through Kafka and Cassandra. Hot posts switch to sharded Redis count projections, with Kafka consumers batching Cassandra persistence every 5 seconds. Real-time velocity tracking promotes active posts to the hot tier, and a cooldown window prevents rapid tier oscillation.

Tier 1: Normal Posts (< 10K likes)
  Like request atomically updates user scoped Redis like state, durably enqueues the event,
  and serves the count from the normal post counter projection. Cassandra persistence is asynchronous.

Tier 2: Hot Posts (10K+ likes, detected via velocity)
  Like request atomically updates user scoped Redis state, durably enqueues the same event,
  and serves the aggregate count from 8 Redis counter shards. Cassandra consumers batch persistence every 5 seconds.

Hot post velocity detection:
  Track like velocity per post in Redis:
    INCR like_velocity:{post_id}:{minute}
  Promotion rule:
    If velocity exceeds 1,000 likes per minute, mark post_id as warming.
    Capture the current aggregate and Kafka offsets, seed the 8 counter shards, replay events after those offsets,
    then switch reads and new projections to hot mode at the catch-up barrier.
  Demotion rule:
    When velocity stays below 100 likes per minute for a cooldown window, keep sharded writes active,
    materialize one counter from the shard sum, and switch back only after an offset barrier.
  Hysteresis prevents rapid promotion and demotion when traffic fluctuates.

Liked-By Deduplication

Rapid client double-taps and network retry attempts must not inflate aggregate counts. The authoritative decision is an atomic user scoped state transition keyed by user_id, which supports exact like and unlike semantics. For mega-posts, a Bloom Filter can reduce negative membership work, but positive results still require an exact state check because Bloom Filters have false positives. Cassandra stores durable current state in bounded post and user buckets so exact recovery and reconciliation remain possible at celebrity scale.

Exact user-state path:
  Redis stores the acting user's current like state on a user scoped shard.
  Atomic state transition returns:
    +1  -> first like changes false -> true
     0  -> requested state already matches current state
    -1  -> unlike changes true -> false

Bloom Filter prefilter for mega-posts:
  Memory footprint: 100M entries x 10 bits = 125 MB
  Configured false positive rate: ~1%
  Bloom Filter is a prefilter, not the authority:
    EXISTS = false -> definitely not present in the filter, so the exact state check can often be skipped only after backfill is complete and every new like updates the filter before this fast path is used
    EXISTS = true  -> possibly present, so consult exact user state before treating the request as a duplicate
  False positives increase exact-check traffic but cannot silently drop a legitimate first like.

Tiered policy:
  Smaller workloads can use exact user state without a Bloom Filter.
  Mega-posts can add a sharded Bloom Filter for cold membership paths while Cassandra remains the durable source of exact state.
  Because exact user state is user scoped, Bloom Filter membership is never the correctness mechanism.

Sharded Counters

Even with tiered ingestion, a single Redis counter key such as like_count:{post_id} creates a hot key bottleneck at 1M writes per second. Counter sharding partitions the counter across 8 sub-keys. Each state-changing event deterministically maps to a shard using the user ID, which keeps retries and repeated actions for the same user and post consistent. Reads aggregate all 8 sub-keys in parallel and cache the sum briefly to trade a small amount of freshness for much higher write parallelism.

Counter sharding layout across 8 sub-keys:
  like_count:<post_id>:0 = 15234
  like_count:<post_id>:1 = 15189
  ...
  like_count:<post_id>:7 = 15122
  Redis Cluster note: do not use a hash tag such as {post_id} on these counter keys, or all 8 keys would map to the same cluster slot.

Write operation:
  shard = hash(user_id) % 8
  INCRBY like_count:<post_id>:<shard> effective_delta
  A deterministic shard keeps repeated operations for the same user/post on one counter shard.
  With balanced traffic and suitable Redis Cluster placement, sharding can provide roughly 8x aggregate write capacity at the counter layer, though actual gains depend on node placement and workload.

Read operation:
  SUM(like_count:<post_id>:0 through :7) = 121,234
  The application aggregates all 8 sub-keys in parallel and caches the sum locally for 1 to 2 seconds.

Read Your Writes for the Liker

While global aggregate counts can safely lag by several seconds, the user who tapped the like button must immediately see their filled heart icon on page reload. The system provides read your writes consistency by routing both the exact user-state transition and the subsequent read to the same Redis shard determined by a user ID hash tag. The acting user's state is therefore visible immediately after a successful request even while the aggregate count remains eventually consistent.

Write path:
  1. Route the request to the user's home Redis shard using a user_id hash tag.
  2. Compute a request_fingerprint from post_id + action and atomically validate operation_id reuse.
  3. If a prior operation for the same user/post is still pending durable enqueue, return blocked_pending. Do not assign a later sequence while an earlier sequence is pending.
  4. If the requested state already matches current state, record the operation as a committed no-op. Do not emit a count-changing event.
  5. For a state change, assign operation_seq and record:
       like_state:{user_id}:<post_id> -> { liked, operation_seq, operation_id }
       like_op:{user_id}:<operation_id> -> pending|operation_seq|desired_state|effective_delta|request_fingerprint
       pending_like:{user_id}:<post_id> -> operation_id|operation_seq|request_fingerprint
  6. Publish the event with the same operation_id and operation_seq to Kafka or a durable outbox. The producer uses idempotence and an explicit acknowledgment policy before the API reports success.
  7. After durable enqueue succeeds, mark the operation committed and clear pending_like. If the client retries while it is pending, reuse the same operation_id and sequence and re-enqueue the same event. A different request with the same operation_id is an idempotency conflict. A recovery worker must never silently let a reserved operation_seq expire: it either re-enqueues the original event or emits a durable no-op tombstone carrying that sequence before allowing later sequences to advance. The 24-hour operation record is the guaranteed retry horizon.

Read path (check if liked):
  1. Route by the same user_id hash tag to the user's home Redis shard.
  2. Execute the equivalent GET/HMGET for like_state:{user_id}:<post_id>.

Consistency rationale:
  Because the write and immediate read use the same user scoped Redis shard, the acting user's state is visible immediately after the successful request.
  The aggregate count is a separate derived value and may lag.

Fallback path:
  If the user-state cache misses or the shard is unavailable, first check the durable like_operation_by_day ledger for a retried operation_id in the current and previous UTC day buckets. If present and unexpired, reuse its exact sequence and payload. Otherwise route a point lookup to Cassandra:
    like_state_by_post_bucket WHERE post_id = ? AND user_bucket = hash(user_id) % 1024 AND user_id = ?
  If Redis failed after a successful durable enqueue, replay retained Kafka events for the affected user and post before clearing recovered pending state.
  If a pending operation cannot be recovered from its durable ledger or Kafka record, resolve it explicitly with a durable no-op tombstone or compensating rollback before clearing the pending gate. Never abandon a sequence gap silently.
  After Redis shard recovery, initialize the local sequence counter from the recovered highest operation_seq before accepting new state changes.
  The ~5ms value is an illustrative latency assumption, not a guarantee.

-- Illustrative atomic state transition on the user's Redis shard
-- KEYS[1] = like_state:{user_id}:<post_id>
-- KEYS[2] = like_seq:{user_id}:<post_id>
-- KEYS[3] = like_op:{user_id}:<operation_id>
-- KEYS[4] = pending_like:{user_id}:<post_id>, all sharing the user hash tag
-- ARGV[1] = action (like|unlike)
-- ARGV[2] = operation_id
-- ARGV[3] = request_fingerprint
-- Operation records define a 24-hour retry horizon. A recovery worker must resolve pending operations before expiry so their reserved sequence is not lost.
-- Values are encoded as: status|operation_seq|desired_state|effective_delta|request_fingerprint
local prior = redis.call("GET", KEYS[3])
if prior then
  local parts = {}
  for value in string.gmatch(prior, "[^|]+") do
    parts[#parts + 1] = value
  end
  if parts[5] ~= ARGV[3] then
    return {"idempotency_conflict"}
  end
  return {parts[1], tonumber(parts[2]), tonumber(parts[3]), tonumber(parts[4])}
end

local pending = redis.call("GET", KEYS[4])
if pending then
  local parts = {}
  for value in string.gmatch(pending, "[^|]+") do
    parts[#parts + 1] = value
  end
  return {"blocked_pending", tonumber(parts[2]), parts[1]}
end

local current = redis.call("HGET", KEYS[1], "liked") or "false"
local desired = ARGV[1] == "like"
local operationId = ARGV[2]
local fingerprint = ARGV[3]
local currentBool = current == "true"
local TTL = 86400

if currentBool == desired then
  local existingSeq = tonumber(redis.call("HGET", KEYS[1], "operation_seq") or "0")
  redis.call("SETEX", KEYS[3], TTL,
    "committed|" .. existingSeq .. "|" .. (currentBool and "1" or "0") .. "|0|" .. fingerprint)
  return {"committed", existingSeq, currentBool and 1 or 0, 0}
end

local seq = redis.call("INCR", KEYS[2])
local delta = desired and 1 or -1
redis.call("HSET", KEYS[1],
  "liked", desired and "true" or "false",
  "operation_id", operationId,
  "operation_seq", seq)
redis.call("SETEX", KEYS[3], TTL,
  "pending|" .. seq .. "|" .. (desired and "1" or "0") .. "|" .. delta .. "|" .. fingerprint)
redis.call("SETEX", KEYS[4], TTL, operationId .. "|" .. seq .. "|" .. fingerprint)
return {"pending", seq, desired and 1 or 0, delta}

Cache Warming

Celebrity posts appear in millions of follower feeds before the like spike arrives. Without proactive warming, initial read requests create a cache stampede against persistent storage. The system pre-populates Redis counter keys when a post enters high-velocity tracking or fans out across follower feeds.

Cache Warming Strategy for Viral Celebrity Content:

1. Proactive warming on feed fan out:
   When a celebrity publishes a post and it enters follower feeds, publish post_id to a warm-cache Kafka topic.
   Workers populate the Redis aggregate count before the first read spike.

2. Reactive warming on hot-post promotion:
   When like_velocity:{post_id} crosses 1,000 likes per minute, move post_id to a warming state.
   Capture a verified count snapshot at a projector checkpoint boundary together with the Kafka partition offset map through which that count is complete. Treat the snapshot and offsets as one logical replay barrier.
   Seed the 8 count shards using base = floor(count / 8) and remainder = count % 8, then add one to the first remainder shards.
   Replay events strictly after the captured offsets. Mark the post hot only after the replay reaches the promotion barrier.

3. Demotion after a cooldown window:
   Keep the post sharded until velocity stays below 100 likes per minute for the configured cooldown.
   Drain the projector through a known offset barrier, materialize the single counter from the 8 shard sum, record the matching offset map, and switch the read and write mode only after the new projection has caught up through that same barrier.
   This prevents lost or double-applied deltas during migration.

4. Eviction and TTL policy:
   Retain hot post keys without TTL while active.
   Evict normal posts after 24 hours of inactivity to reclaim memory.

Event Bus (Kafka)

The user facing API can respond after the user's state transition and durable event enqueue succeed. Secondary operations including Cassandra persistence, aggregate count projection, recent liker indexing, creator notification delivery, and analytics ingestion execute asynchronously through independent Kafka consumer groups. This keeps downstream processing off the request path while preserving a durable replay source.

topic: like-events
partitions: 128
partition_key: post_id + user_bucket # user_bucket = hash(user_id) % 1024. Preserves per-user/post ordering while distributing one viral post across many partition keys
retention_days: 7
replication_factor: 3
min_insync_replicas: 2

producer:
  idempotence: true # enable.idempotence=true prevents duplicate publications from producer retries
  acks: all # successful API response requires the event to be acknowledged by the required in-sync replicas
  event_schema:
    event_id: "uuid"
    operation_id: "string"
    user_id: "uuid"
    post_id: "uuid"
    action: "like | unlike"
    operation_seq: "monotonic per user/post, contiguous for state-changing events"
    effective_delta: "+1 | -1"
    timestamp: "server_assigned_epoch_ms"

consumer_groups:
  db_writer: "Persist authoritative current like state, time-bucketed operation ledger, and recent-like events to Cassandra in batches"
  count_projector: "Apply effective deltas in operation_seq order, hold sequence gaps, and deduplicate retries by operation_id. Redis is a repairable derived projection"
  count_reconciler: "Periodically compare derived counts against authoritative like state and repair drift"
  notification: "Batched push notifications dispatched to post creators"
  analytics: "Sink event stream to ClickHouse for analytics and reporting"

execution_paths:
  sync_path: "Validate request, atomically transition user like state on its home Redis shard, validate operation_id reuse, assign operation_seq for state changes, durably enqueue the event, and return the latest available cached count"
  async_path: "Persist state and event history to Cassandra, update aggregate counter shards, generate notifications, and reconcile drift without blocking the user response"
  fault_handling: "Retry failed consumers with idempotent operation_id handling, route poison events to like-events-dlq after 3 retries, hold sequence gaps for ordered replay, and alert when consumer lag exceeds 30 seconds"

durability_note:
  "The API must not acknowledge a state-changing operation merely because Redis changed. Kafka durability or an equivalent durable outbox must be confirmed before a successful response. Redis provides the low latency read model."