The first version usually works.
A small system can poll on a comfortable interval and appear perfectly healthy. There are few records, few consumers, and no meaningful cost to asking the same question again. That makes polling a sensible first answer—until freshness starts to matter.
scroll ↓ watch the pressure spread
One simple loop, pulled apart by scale.
Freshness has a cost.
To make information arrive sooner, the interval gets shorter. More consumers join. Each integration keeps its own schedule. The result is a growing number of requests that mostly return “nothing changed,” while the important update can still arrive later than the product needs.
Choose the signal that fits the work.
When a change itself is important, it is often better to make that change a signal. An event or change stream lets interested systems respond when something happened, rather than continuously checking whether it might have happened.
That does not remove complexity. It shifts the work toward delivery guarantees, retries, ordering, and observability. But those are the real reliability questions anyway—and they are easier to reason about when the system has a clear record of the change moving through it.