Event-Driven vs Polling

At Mensari, the legacy wallet monitoring system polled blockchain RPCs every five minutes. Users waited up to five minutes to know their transaction had confirmed. We replaced it with an event-driven webhook system. Sub-second notifications.

Why polling persists

Polling is simple. You write a cron job, it checks for new data, it processes what it finds. No connection state, no message ordering, no delivery guarantees to think about. For low-frequency, low-stakes data, polling is fine.

The problem is when “fine” is not good enough.

When to switch to event-driven

Switch when any of these are true:

• Latency matters — Your users are waiting for the update
• Frequency is unpredictable — You are either polling too often (wasting resources) or too rarely (missing data)
• Fan-out is wide — Multiple consumers need the same event

At Mensari, all three were true. Blockchain transactions are unpredictable, users expected real-time notifications, and multiple downstream services needed the data.

The hard parts nobody mentions

Event-driven architectures trade one set of problems for another:

• Ordering — Events may arrive out of order. Can your system handle that?
• Idempotency — Events may be delivered more than once. Every handler must be safe to re-run.
• Backpressure — What happens when events arrive faster than you can process them?
• Observability — A request-response flow is easy to trace. An event that triggers three downstream handlers across two services is not.

These are not reasons to avoid event-driven architecture. They are reasons to design for them explicitly.

The hybrid approach

In practice, the best systems use both. Events for the hot path (real-time, user-facing). Polling as a reconciliation mechanism to catch anything the event system missed. Belt and suspenders.