A large theme park app (think Disneyland or Universal Studios) must show an accurate wait time for every attraction and forecast it 15 to 60 minutes ahead, so a guest can decide whether to walk across the park now or after lunch. The system ingests real-time signals: ride throughput counters, queue-length estimates from cameras or Bluetooth beacons, ride downtime events, weather, and live park attendance.
It must learn the patterns that drive wait fluctuations (time of day, day of week, season, holidays, parades and special events) and survive the non-stationarity caused by breakdowns, capacity changes, and brand-new rides. Predictions must update within seconds of a status change, and the app must show a range rather than a single number, because one estimate that is 20 minutes wrong destroys trust in every other number on the screen.
How would you design this system? Cover the real-time feature ingestion pipeline, the forecasting model architecture (sequence model vs temporal graph vs hybrid), how you handle downtime events and non-stationarity, how you produce calibrated uncertainty intervals, and how you evaluate both prediction accuracy and freshness.
The Problem: the posted number is a lagging measurement, while the guest needs a forecast that already accounts for the breakdown, the lost train, the rain, and the crowd walking over right now.
Answer
The design is a physics-anchored hybrid forecaster served from a streaming feature pipeline. A queueing-theory baseline gives the mechanical wait from live queue length and boarding throughput, and a learned model predicts the residual plus the multi-horizon trajectory. The learner is a spatiotemporal hybrid: a temporal encoder over each ride’s recent history, message passing over a park graph whose edges encode walking time and historical guest flow, and global context (attendance, weather, event calendar) injected as conditioning. Two decisions are pivotal. First, the model emits quantiles (P10, P50, P90) that are re-calibrated hourly with conformal prediction, so the app shows an interval whose stated coverage is measured, not assumed. Second, downtime is not left to the model to infer: a state machine on status events fires within seconds, switches the ride into a closure or recovery regime, and widens the band while the surge plays out.
(1) Physics Prior Plus Residual: start from 
using measured queue length and boarding rate, then learn the correction; the prior keeps the system sane when a ride has no history.
(2) Spatiotemporal Hybrid Model: per-ride temporal encoder over 4 hours of one-minute features plus graph message passing across nearby rides, because a closure spills guests onto its neighbors within minutes.
(3) Direct Multi-Horizon Quantile Heads: one forward pass emits P10/P50/P90 for the 0, 15, 30, 45, and 60-minute horizons, avoiding the error compounding of autoregressive rollout.
(4) Downtime State Machine: status events drive an explicit open / closed / recovering state that overrides the model, feeds a regime feature, and inflates the interval during the reopen surge.
(5) Streaming Features With Point-In-Time Discipline: the same transformations run in the stream (30-second online cache) and in the offline store, joined as-of prediction time so training never sees a future counter.
(6) Freshness As A First-Class SLO: every prediction carries a feature-age stamp; stale sensors degrade the system down a ladder rather than silently serving a confident stale number.
Figure 1: One batched graph inference every 30 seconds for the whole park, a seconds-latency override path for status changes, and a slow loop where realized waits measured from band scans retrain the model and recalibrate the intervals.
Clarify Before Designing:
(1) Ground Truth: how do we measure the wait a guest actually experienced (entry and boarding scan pairs from bands or the app, or only human-carried test cards), and what fraction of guests are instrumented?
(2) Scale: how many attractions per park, how many parks share the model, and how many guests open the app per day?
(3) Freshness SLO: what is the allowed lag from a status change to an updated number in the app, and how often may a displayed value be refreshed?
(4) Horizons And Display: which horizons does the product show, and is the app allowed to show a range or a range plus a point?
(5) Sensor Coverage: do all rides have queue-length sensing, or only throughput counters for some, and how are virtual queue and paid-lane guests counted?
(6) Error Asymmetry: is over-promising (say 20, actual 45) worse than under-promising, and by how much, since that ratio sets the loss weights and the displayed quantiles?
Leave a Reply