Design notification fan-out

Fan-out on write (push). On a post, write an entry into every follower's feed. Reads are then a single indexed lookup — fast and cheap, which matters because reads vastly outnumber writes. But a post from an account with 30M followers becomes 30M writes, which is a latency spike, a write-amplification problem, and a thundering herd against storage.

Fan-out on read (pull). Store the post once; a feed read gathers posts from everyone the user follows. Writes are trivial; reads become an expensive scatter-gather on the hottest path in the product.

The answer is hybrid, and the split is the insight. Push for ordinary accounts, where fan-out is cheap and read performance is what matters. Pull for the small set of celebrity accounts, merged in at read time. A user's feed is then "my precomputed feed" plus "recent posts from the handful of huge accounts I follow", merged on read. The celebrity set is tiny, so that merge is bounded.

Making the threshold a tuned parameter rather than a constant, and being able to say what you would measure to set it, is the depth marker.

Delivery. The fan-out itself belongs on a queue, not in the request path — the post should be durable and acknowledged long before delivery finishes. Per-channel workers (push, email, in-app) consume from it, since channels have wildly different latency and failure characteristics.

Idempotency. Queues deliver at least once. Without a dedupe key per (notification, user, channel), retries send duplicate push notifications — the single most visible way this system fails in public.

Things worth raising: per-user notification preferences and quiet hours applied at delivery rather than at fan-out; collapsing ("5 people liked your post") to avoid flooding; and the fact that a user following a celebrity mid-post-fan-out may or may not receive it, which needs a stated rule rather than an accident.