Design a Real-Time Event Feed

Problem statement

Design a platform that ingests high-frequency events from many heterogeneous producers—application services, system logs, IoT devices, presence and activity generators—and broadcasts them to subscribed consumers in near real-time. Consumers are diverse: mobile and web clients holding open WebSocket or SSE connections, internal services consuming durable streams, and external partners receiving signed webhooks. Every subscription may carry a filter predicate and a transformation projection, and every delivery must survive producer bursts, consumer slowness, broker failover, and regional outages without silently losing critical events.

This is not a message queue renamed. A queue hands each message to one consumer group; a feed platform multiplies each event across thousands to millions of matching subscriptions with per-subscriber latency, ordering, replay, and authorization semantics. The defining tension is fan-out amplification: one hot producer can demand millions of deliveries per second, while one slow consumer can hold memory hostage on a gateway. The design must therefore separate four planes and keep their failure modes independent.

The four planes

1. Ingestion plane: authenticated producer gateways (REST/gRPC for services, MQTT for devices), schema validation against a registry, idempotency enforcement, per-producer quotas, and a durable append into the partitioned event backbone.
2. Distribution plane: the subscription index, the fan-out engine that decides push versus pull per producer heat, mailbox materialization, filter and transform evaluation, and per-subscriber cursors.
3. Delivery plane: WebSocket and SSE gateways with sticky connection affinity, webhook dispatchers with retries and dead-letter queues, and mobile push fallback for disconnected clients.
4. Control plane: schema registry, quota and admission control, observability, replay and audit tooling, and policy distribution.

A strong interview answer states the invariant early: ingestion durability and delivery freshness are different contracts. The backbone guarantees a durable, partition-ordered log with replay; the delivery plane guarantees low-latency best-effort push with at-least-once resume from cursors. Confusing the two produces either a slow system that synchronously writes every mailbox, or a lossy system that treats a dropped socket as a dropped fact.

Why the problem is distinctive

Three properties rarely coexist and each forces architecture. First, write amplification is asymmetric: a single event can match 12 subscriptions on average and 40 million for a global announcement. Second, latency is per-subscriber: p95 end-to-end under 300 ms for push-class events while replay stays available for hours. Third, heterogeneity: a 200-byte IoT heartbeat and a 4 KB enriched activity event share the backbone but need different retention, quota, and delivery classes. Twitter publicly hit 143,199 tweets per second at a 2013 peak while fanning each tweet out to follower timelines; LinkedIn built Kafka precisely because durable streams with consumer offsets beat RPC fan-out; Slack fans every channel message to thousands of connected members over WebSockets. These are the reference points for this design.

Public baseline versus design assumptions

Public figures anchor the category: Twitter reported roughly 500 million tweets per day and the 143,199 tweets-per-second peak; LinkedIn reports trillions of messages per day through Kafka; Netflix's Keystone pipelines trillions of events per day; Discord stores trillions of messages; WhatsApp reported 100 billion messages per day in 2021. These are cited company-reported figures, not our requirements. For capacity planning this answer explicitly assumes a mature platform with 6 million concurrent connected consumers at peak, 200,000 events per second ingest at a 5x peak, 300 million active subscriptions, and an average of 12 matching subscriptions per event. Every uncited number in this answer is a stated assumption, budget, or target.

The interview posture

Open by separating ingestion durability from delivery freshness, name the fan-out amplification as the dominant cost, and declare push/pull/hybrid as the central decision rather than a technology choice. Then the rest of the design—partitioning, mailboxes, cursors, gateways, backpressure—falls out of that one decision under explicit scale assumptions.