A live platform computes real-time metrics during events where concurrency changes by an order of magnitude within minutes. What must the streaming architecture provide?

What it must provide

1. Two processing paths with different guarantees. Approximate low-latency aggregates for viewer counts and chat rate, using probabilistic structures over short windows — approximate by design, because nobody perceives the difference between 812,000 and 814,000 viewers and exactness costs far more than it is worth. And exact, higher-latency processing for anything with consequences: moderation, subscriptions, payouts.

2. Serving decoupled from processing. The processor writes aggregates to a low-latency store; the API reads from there. A processing hiccup then degrades freshness rather than availability.

3. Partitioning planned for the peak, not the mean. Partition count is difficult to change on a live system, so a hot channel needs sub-partitioning — salting the key for the highest-volume channels — designed in advance.

4. Lag as a first-class state. The system must know it is behind, expose an as-of timestamp on every metric, degrade in a chosen order, and recover at a controlled rate.

5. Chat fan-out separated from chat analytics. Delivering a message to a hundred thousand viewers is a connection-layer problem; counting messages is a stream-processing problem. Coupling them means analytics load affects delivery, which is the wrong priority order.

What happens when the processor falls behind

• Windowed aggregates become misleading — a five-second window over thirty-second-old data reports the past as the present.
• Watermarks force a choice: wait for late data and stall further, or advance and drop it. Both are valid; having no policy and discovering the default during the event is the failure.
• State grows in stateful operators while output is delayed, escalating lag into a checkpoint failure.
• Recovery causes a second spike, since catching up at many times normal rate can overwhelm the downstream store — so recovery needs rate limiting.
• Approximate and exact paths diverge, so displayed counts disagree with payout counts. Expected, and reconciled rather than treated as a bug.

A streaming system that only behaves correctly when it is keeping up is not designed for the event it exists to serve.