CONCEPT Cited by 1 source
Polling interval as freshness budget¶
Definition¶
When a system coalesces upstream work behind a polling proxy, the proxy's poll interval becomes the upper bound on how quickly any configuration change can reach the downstream consumers. The interval is not a performance knob — it is the user-visible freshness budget for the whole pipeline.
Canonical instance¶
Route Server polls the
Kubernetes API every 3 seconds (Source:
sources/2025-02-16-zalando-scaling-beyond-limits-harnessing-route-server-for-a-stable-cluster).
That choice fixes the worst-case propagation time for a new
or changed Ingress / RouteGroup: a team applying a
manifest at t=0 has [3s poll + ETag-update round-trip to
Skippers] before the new route is reachable in the data
plane. The 3 seconds is not hidden — it is the contract.
Why it's a contract, not an implementation detail¶
Operators upstream of a coalescing proxy cannot get faster propagation than the interval by any means short of short-circuiting the proxy. Freshness-sensitive consumers must be redesigned — either to drive the proxy themselves (not possible with a shared coalescer), or to accept the floor.
Worked example: a deploy that flips an A/B experiment by changing a route filter has a minimum 3-second activation delay end-to-end at Zalando. Anything downstream (load balancers, client caches, CDN) compounds on top.
Interval-as-knob trade-offs¶
| Shorter interval (e.g. 500 ms) | Longer interval (e.g. 30 s) |
|---|---|
| Tighter freshness for operators | Looser freshness |
| More load on upstream (K8s API) | Less load on upstream |
| More ETag / 304 churn on downstream | Less downstream churn |
| Change-detection latency ≤ interval | Change-detection latency ≤ interval |
At Zalando the chosen point is 3 seconds: fast enough that operators don't complain, slow enough that one Route Server deployment handles 300 Skippers at 100 rps.
Compose with ETag, not instead¶
ETag conditional
polling makes the interval cheaper (most polls are empty
304s), but does not change the freshness ceiling. A 304
poll still advances the clock by Δ.
When this isn't the right primitive¶
- Sub-second propagation required. Use a push stream (xDS, Kubernetes watch, SSE) — the poll-interval floor doesn't apply.
- Change volume so high that the cost of an ETag miss overwhelms the 304 floor. The coalescing gain shrinks; push becomes attractive.
- Consumers can tolerate much looser freshness. Simpler designs (manual config push, cron refresh) may suffice.