A real-time platform must serve computed state to a low-latency request path. What should the serving layer look like?

The shape

The stream processor writes; the serving layer reads; the request path never touches the processor.

That decoupling is the central property. It means a processing failure degrades freshness rather than availability — the API continues serving the last computed state, which for most real-time features is a far better failure mode than an error.

What the serving store must provide

• Low-latency point lookups by key, which is the only access pattern the request path uses.
• High write throughput, since the processor updates continuously.
• Bounded staleness that is measurable, so the request path can know how current the value is.
• Availability independent of the processing pipeline.

The properties the request path needs

1. An as-of timestamp with every value, so the caller can decide whether stale data is usable. For dispatch, a driver location from four minutes ago should be treated differently from one from four seconds ago — and without the timestamp the caller cannot tell.

2. A defined behaviour when the value is missing or stale — a default, a fallback computation, or an explicit degradation. Decided per feature rather than defaulted.

3. No computation over history. Everything derived from large volumes of events is precomputed; the request path does lookup and ranking only. A budget of tens of milliseconds forbids anything else.

The failure modes to design against

• The serving store as a hard dependency with no fallback, so a store problem is a total outage rather than a degradation.
• Unbounded staleness, where the processor has been stalled for an hour and the API serves confidently stale data with no signal.
• Hot keys, since real-time features are heavily skewed — a popular location, a busy region — requiring replication or local caching of the hottest entries.
• Write amplification from updating every key on every event rather than only what changed.

The lag SLI

Processing lag is the serving layer's most important signal, and it must be published to consumers rather than only monitored internally.

A pipeline that is running, connected and twenty minutes behind passes every liveness check while serving increasingly wrong data — which is why the metric must be lag, not health.