A live-streaming platform must compute real-time viewer counts, chat rate and moderation signals during events where concurrent viewers spike tenfold within minutes. What streaming architecture handles this, and what happens if the stream processor falls behind?

The architecture

Ingest into a partitioned log, keyed by channel. Per-channel ordering is what the computations need; global ordering is neither available nor useful. Channel keying also means a hot channel is a hot partition, which must be planned for rather than discovered.

Two processing paths with different guarantees:

• Approximate, low-latency aggregates for viewer counts and chat rate. These use probabilistic structures — HyperLogLog for unique viewers, count-min sketches for rates — computed over short tumbling windows. They are approximate by design, which is correct: nobody can perceive the difference between 812,000 and 814,000 viewers, and exactness would cost far more than it is worth.
• Exact, higher-latency processing for anything with consequences: moderation actions, subscriptions, payouts. These need at-least-once delivery with idempotent application and are allowed to be seconds behind.

Serving from a real-time store rather than from the stream processor. The processor writes aggregates to a low-latency store; the API reads from there. This decouples read availability from processing health, so a processing hiccup degrades freshness rather than availability.

Handling the tenfold spike

• Partition 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 — planned in advance.
• Chat fan-out is separate 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 message delivery, which is the wrong priority order.
• Shed low-value work first. During a spike, sampling chat for rate calculation is fine; sampling moderation is not. The shedding policy must be per-computation, not global.

What happens when the processor falls behind

The specific consequences, and why "it catches up" is not the whole answer:

1. Windowed aggregates become misleading. A five-second window computed over data arriving thirty seconds late reports the past as the present. Every displayed metric needs an as-of timestamp, and the UI should show staleness rather than presenting old numbers as current.
2. Watermarks advance or they do not. If the processor waits for late data, it stalls further behind. If it advances, late events are dropped. Both are choices; the failure is having no policy and discovering the implementation's default during the event.
3. State grows. Stateful operators holding windows accumulate state while output is delayed, eventually causing memory pressure or checkpoint failures — a lag problem escalating into a crash.
4. Recovery causes a second spike. Catching up means processing at many times the normal rate, which can overwhelm the downstream store and cause a cascading failure at exactly the moment of recovery. Recovery needs rate limiting.
5. Approximate and exact paths diverge, so the count shown to viewers disagrees with the count used for payouts. This must be expected and reconciled rather than treated as a bug.

The design principle

For live events, freshness is a feature and lag is a first-class state. The system must know it is behind, say so in its outputs, degrade in a chosen order, and recover at a controlled rate. A streaming system that only behaves correctly when it is keeping up is not designed for the event it exists to serve.