Case study: a live dashboard
Request
The Briar Dispatch operations team needs an operational delivery dashboard.
Data
A 15-second freshness target; 3-second ingestion, 4-second processing, and 2-second serving; tablet arrivals up to 120 seconds late. All figures are fictional workload inputs.
Done
Deliver the freshness budget, retained processing graph, correction policy, metadata API, and a checked display recommendation.
Briar Dispatch monitors delivery assignments during a fictional regional launch. Operators want a view less than 15 seconds behind the business, but tablets can upload completion events two minutes late. The dashboard must distinguish when it last refreshed, how far processing has progressed, and whether a time window is still provisional. A moving refresh timestamp alone proves none of those things.
You'll budget the path, build retained ingestion, and choose how corrections reach readers. A cache speeds reads but can hide the latest published version unless its lifetime fits the freshness promise. The API also needs enough metadata to explain an empty chart. Zero completed jobs, an unreachable source, and a delayed processor all produce different operational decisions. The final recommendation ties the display policy to those uncertainties instead of presenting incomplete windows as final.
Freshness budget: 15 s
Ingest: 3 s + process: 4 s + serve: 2 s
Cache allowance: 6 s
Window finality: separate 120 s late-arrival policy
The serving budget and late-event finality answer different questions. A chart can be fresh and still provisional.