The half-interval tax

Start with the arithmetic, because it settles the argument faster than any architecture diagram. A pipeline that checks a source every five minutes will, for an event that can occur at any moment in that window, learn about it two and a half minutes late on average. Not because anything failed - because that is what the design does when it works perfectly. Call it the half-interval tax: the delay you pay for asking rather than listening, before a single millisecond of network, parsing, or evaluation is added on top.

The tax is easy to miss because it is invisible in the metrics most teams keep. Instrumentation usually starts when a record enters the pipeline, so the dashboards show the time from fetch to delivery, which can be genuinely excellent. The interval before the fetch is not measured by anyone, because no component was awake for it. This is the practical reason event time and processing time have to be distinguished: a system that stamps records on arrival is not reporting how late they are, it is reporting how quickly it handled its own discovery.

The instinctive fix is to poll more often, and it fails in a specific way. Going from five minutes to thirty seconds cuts the tax to fifteen seconds and multiplies request volume tenfold against sources that publish rate limits for exactly this reason. Each request also pays a connection setup and at least one round trip that a held-open connection pays once. And when limits start rejecting requests, the effective interval stretches - which happens under load, and load correlates with the world being busy. The design degrades precisely when the events are worth having.

There is a second-order effect worth naming. Because the tax is an average over a uniform distribution, its variance is as wide as the interval: on a five-minute cadence, some records arrive nearly instantly and some arrive five minutes late, with no way to know which kind you are holding. That is a tail latency problem dressed as an average, and averages are how it stays hidden. A median of ninety seconds sounds like a real-time product right up until the one record that mattered was in the slow half.

The alternative is not a faster loop, it is a different relationship with the source. An edge node that holds its connections open receives an event rather than discovering it, which removes the interval instead of shortening it. The cost moves from per-request to per-connection: one handshake, amortized across everything that arrives on it, which is also why hybrid post-quantum key exchange costs us bytes once rather than on every record. This is the whole practical argument for an event-driven architecture over a scheduled one, and it is worth about as much as every software optimization downstream of it combined.

It would be dishonest to imply the tax disappears everywhere. Some sources only publish on their own cadence, and no architecture beats a source that produces a file four times a day. What changes is who knows: when the bound comes from the source, it can be published as a property of that coverage, and the freshness figure a client sees is the truth rather than an average smoothed across everything else we carry. A vendor that quotes one latency number for an entire catalog has averaged its slowest coverage into its fastest and told you nothing about either.

So the question to put to any real-time vendor is not how fast their API responds. It is: how does an event reach you, and what is the interval before your clock starts? Two follow-ups separate the designs quickly. Does every record carry the time you observed it, or the time you processed it? And can I recompute your latency from the records themselves, without taking your aggregate on faith? A provider running an event-driven network can answer both without hesitating, because the answers are already stamped on the data.

One uncomfortable corollary, since it applies to our own clients: the tax can be reintroduced on the consuming side. A team that subscribes to a real-time stream and then polls its own queue every thirty seconds has paid to remove an interval and then added a smaller one, which is not obviously wrong - a thirty-second tax on a five-minute one is a large improvement - but it should be a decision rather than an accident. The REST endpoint exists for bounded history and backfills; anything whose value decays in seconds belongs on a connection that stays open.

The interval you cannot see is the one you pay for. Everything else in a latency budget is engineering; this part is arithmetic, and it is settled before the first packet moves.