Multiple-choice synthesis across the social-feed cases: notification fan-out and the retry storm, the feed's fan-out tradeoff and the celebrity hybrid, chat's server-push and per-conversation ordering, and autocomplete's precompute-offline rule.
SDCSenior◷ 13 min
Level
FoundationsJuniorMiddleSenior
Four decisions across the unit’s four cases — each a choice you make in a design review, not a definition to recite. The thread tying them together is the same one that runs through every read-heavy social system: do the expensive work once, on the write or build side, and keep the user-facing path a cheap lookup.
Confirm you can name the missing dedup guard in a notification retry storm, route a celebrity through the feed hybrid, impose consistent chat ordering without global coordination, and reject a live-per-keystroke autocomplete.
Quiz
Completed
A notification provider recovers from an outage and the backlog re-flushes; users get the same push 5–9 times. Retries with backoff are already in place. What single piece is missing?
Heads-up Exactly-once across a provider you do not control is unachievable — it can deliver then fail to ack. At-least-once delivery plus an idempotency guard gives the user effectively-once; that guard is the missing piece.
Heads-up That silently drops messages on any transient blip — the opposite failure. Keep retries (bounded, with backoff+jitter) and add an idempotency check so retries do not duplicate.
Heads-up Faster draining just delivers the duplicates faster. Duplicates come from re-sending without a dedup guard; throughput does not address it.
Quiz
Completed
Your news feed uses fan-out-on-write, but a celebrity's 30M-follower post causes a write storm that stalls everyone's feed. What is the standard fix?
Heads-up Pure pull makes every feed load a scatter-gather across all followed accounts on every refresh, with no amortization over the ~100:1 reads — disastrous for a read-heavy feed. Keep push for the common case; pull only the few celebrities.
Heads-up More workers still means 30M writes per celebrity post — scaling the wrong axis. The problem is the strategy at the power-law tail, not throughput; pull those accounts instead.
Heads-up You cannot dictate the social graph; the power-law tail is inherent. The design must handle 30M-follower accounts, and the way is to pull them at read time.
Quiz
Completed
Two chat users on different gateways message rapidly; messages render out of order and one duplicates after a reconnect. How do you get consistent ordering and no duplicates?
Heads-up A global sequence is needless coordination and a bottleneck, and meaningless since order only matters within a conversation. Per-conversation sequence on its shard gives a total order where it is needed without global serialization.
Heads-up Client clocks are skewed and unsynchronized, so timestamp sort reorders messages under drift. Order must come from a server-assigned per-conversation sequence at persist time; dedup still needs a message id.
Heads-up Speed does not impose order — network reordering and retries happen regardless. You need a sequence number for order and a message id for dedup.
Quiz
Completed
An autocomplete queries the search logs on each keystroke to rank matching queries; it is 600 ms slow and overloads the cluster. What is the architectural fix?
Heads-up More replicas still run a heavy aggregation per keystroke — scaling the wrong thing. The latency is ranking on the read path over a large dataset; precompute it offline and serve an O(1) lookup.
Heads-up Autocomplete is about prefixes, not full queries; caching full-query results does nothing for partial-prefix keystrokes. You need a trie of prefixes with precomputed top-k per node, built offline.
Heads-up Debouncing trims load a little but even one request still triggers a live aggregation that blows the tens-of-ms budget. You must stop ranking on the read path entirely.
Recall before you leave
01
Why do notification retries need an idempotency key, and why does the feed need a hybrid?
02
How do chat ordering and autocomplete serving each avoid doing expensive work on the user path?
Recap
The four cases rhyme. A notification system retries at-least-once, so it needs an idempotency key to avoid the retry storm — retries without dedup duplicate. A news feed is read-heavy, so it pushes (fan-out-on-write) for normal authors but pulls celebrities in a hybrid, because the power-law tail breaks any single strategy. A chat system orders messages with a per-conversation sequence number assigned at persist time — a total order where it matters, with no global coordination — and dedups on a message id. Autocomplete never ranks live per keystroke; it serves a precomputed top-k from a trie built offline, an O(1) read behind an edge cache. The unifying principle across all four: do the expensive work once, on the write or build side, and keep the user-facing path a cheap, safe lookup.