A gallery's visitor-flow sensors stream footfall counts continuously, and the reporting requirement is a rolling five-minute total per gallery, refreshed as new events arrive rather than recomputed from all history each time. Which loading pattern characteristic should the design center on?
Select an answer to reveal the explanation.
Short Explanation
A rolling five-minute total doesn't need the whole history replayed every time, just the events sliding into and out of the window. A windowed streaming design keeps that total updated incrementally as each new count arrives.
Full Explanation
Streaming loading patterns for continuously arriving data often rely on windowing functions that define a bounded time span, here five minutes, over which an aggregate is maintained and updated incrementally as new events enter the window and old ones age out. This produces a constantly current rolling total without reprocessing the full event history on every update, which matches the requirement exactly. A full nightly recomputation of all footfall history is a batch pattern that both arrives far too late for a rolling near-real-time metric and wastes enormous compute reprocessing data that hasn't changed. A one-time historical backfill with no ongoing processing addresses loading past data once, but the scenario needs continuous, ongoing updates as new events keep arriving, which a one-time backfill by definition does not provide. A manual, on-demand query run only when someone happens to check has no guarantee of freshness or consistency and isn't a loading pattern at all, it's an ad hoc read against whatever state happens to exist at that moment. When implementing the windowed aggregate, decide explicitly between a tumbling window, which resets on fixed non-overlapping intervals, and a sliding or hopping window, which better matches a continuously rolling five-minute total, since picking the wrong window type produces a metric that doesn't behave the way stakeholders expect.