Why I prefer events over polling
(and when I don't)

Polling has a place. If a system cannot emit events, a relay can query a table, call an endpoint, or inspect a queue. OpenTrace Relay supports that kind of bridge because real systems are messy. But when I control the instrumented code, I prefer events.

Events are more precise. The process can report the moment it changes phase, finishes a batch, notices an anomaly, or reaches a milestone. Polling discovers state later and often has to infer what changed between samples.

Intent lives inside the work

The running job knows why something matters. It can publish a note that says validation started or a payload that explains why records were skipped. An outside poller usually sees symptoms, not intent.

Less guessing

Polling often creates design pressure to expose status tables or computed summaries. Events keep the producer contract direct: when something meaningful happens, send it. The dashboard can then build views from facts instead of guesses.

Events can be missed

The reason I still fall back to polling is simple: events are easy to miss. A process can crash before sending one. A network call can fail. A deployment can restart at the wrong moment. A consumer can be down when an event is emitted. Event-driven systems need retries, durability, and reconciliation if the missing event matters.

Polling is useful as a safety net because it can ask, "What is true now?" even if the system missed the moment when that truth changed. For important workflows, the best design is often event-first with some form of polling or reconciliation behind it.

Still pragmatic

I still value polling as an adapter strategy and a reliability fallback. Existing databases, REST endpoints, and webhook sources may need relays. Critical workflows may need periodic checks to catch anything the event path missed. But for new instrumentation, event emission is cleaner because it preserves timing, context, and intent.