PATTERN Cited by 1 source
Timer-driven heartbeat emission¶
Definition¶
A stream-processing pattern where processing-time timers fire on a fixed schedule to emit output records (heartbeats, keep-alive signals, duration updates) independent of whether any new input data has arrived. This decouples output cadence from input arrival rate.
Shape¶
Input: ──GameStart──────────────────────GameEnd──
Timers: ▼ (30s) ▼ (30s) ▼ (30s)
Output: Active─┤─Heartbeat─┤─Heartbeat─┤─End──
When to use¶
- Session tracking at scale (gaming, IoT, connected devices) where downstream systems need periodic proof-of-life signals.
- SLA monitoring where absence of heartbeat triggers timeout logic.
- Any workload with high output amplification — a small number of input events spawn many timer-driven outputs (16× amplification observed in gaming sessionization: ~500K inputs/min → ~8M outputs/min).
Trade-offs¶
- Pro: Output freshness is bounded by the timer interval (e.g., 30s), not by input arrival. Downstream always knows session status within one timer period.
- Pro: Works within a single stateful processor — no external scheduler needed.
- Con: Output volume scales with number of active entities × timer frequency, not with input rate. 4M sessions × 30s timer = 8M heartbeats/min.
- Con: Requires sub-second timer precision if heartbeat freshness matters — micro-batch mode rounds timer fires to batch boundaries.
Seen in¶
- sources/2026-06-03-databricks-apache-spark-real-time-mode-for-gaming —
handleExpiredTimer()in aStatefulProcessorfires every 30 seconds per active gaming session, emittingSessionActiveheartbeats with current duration. Responsible for the majority of output (8M records/min from timers vs 500K from input events).
Related¶
- concepts/stateful-stream-processing — timers are a core primitive of stateful processors
- patterns/reactive-plus-proactive-stream-processing — the broader dual-path pattern
- patterns/heartbeat-absence-as-alert-trigger — downstream consumer of heartbeat streams