Serving Latency Budget
The end-to-end time from an event occurring to its effect being queryable, allocated across ingest, processing and serving.
"Real time" is not a specification. A budget is: two hundred milliseconds from event to queryable, split as fifty for ingest and transport, eighty for processing, and seventy for the serving store to index and answer.
Allocating it makes the architecture decidable. A seventy-millisecond serving budget rules out a store that indexes on a one-minute cycle, and it rules in a real-time analytical store designed for continuous ingest. It also exposes where the budget is actually spent, which is frequently in a place nobody suspected — often the sink's commit interval, set to five minutes by default and never revisited.
The half most often forgotten is the query itself. A budget consumed entirely by the write path leaves nothing for the read, and a dashboard issuing an expensive aggregate over the serving store will exceed the total regardless of how fast the pipeline was.
The measurement that keeps it honest is end to end from the event's own timestamp to when a query first returns it — not the sum of each component's self-reported latency, which omits every queue between them.