A streaming app tracks each bus’s last-seen timestamp so stale vehicles can be flagged. What concept does maintaining that per-bus value illustrate?
Select an answer to reveal the explanation.
Short Explanation
Remembering each bus’s last beep means the job has a pocket notebook—state—keyed by bus. Pure stateless one-and-done maps forget the past; printed-only timetables are not streaming state. Keep the timestamp, spot the stale vehicle.
Full Explanation
Tracking each bus’s last-seen timestamp so stale vehicles can be flagged illustrates stateful streaming: the job keeps per-key state as events continue, updating and reading that state for decisions. Stateless map-only batch with no memory across events cannot know a bus went silent. Printed timetables that replace all digital state abandon live AVL. Mandatory deletion of timestamps before any alert logic removes the signal required to detect staleness. Exam caveat: state grows with key cardinality—use TTLs, rocksdb-style state stores, and checkpoints so citywide bus fleets do not exhaust memory. Operational check: simulate a bus that stops emitting, confirm the stateful job flags it after the staleness threshold, restart the job from checkpoint, and verify per-bus state restores without losing the last-seen values. In production terms for stateful per-key streaming, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for stateful per-key streaming after material dependency upgrades so regressions are caught before the next public release.