Five parallel workers in the city's UCS inventory poller each retry as if they alone owned the entire API rate ceiling and still trip 429. What robust pattern should they use?
Select an answer to reveal the explanation.
Short Explanation
Five clerks each assuming they own the whole ticket roll will empty it together. One shared pacekeeper—or a single paced queue—keeps the team under the ceiling.
Full Explanation
When five parallel UCS inventory workers each assume they alone own the full API rate ceiling, their combined traffic overshoots and trips 429. Robust pacing uses one process-wide limiter or a single paced queue so all outbound calls share the same budget. Parallelism remains, but admission to the wire is coordinated.
Giving every thread an independent unlimited budget equal to the full platform ceiling multiplies quota by worker count and guarantees collective overage. Disabling parallelism forever because “REST cannot be paced” is false—shared limiters and queues exist specifically to pace concurrent REST clients. Raising each worker’s timeout to one hour does not reduce request rate and does not prevent 429; it only slows failure detection.
Exam caveat: a process-wide limiter still needs alignment with any cluster-wide quota if multiple hosts poll UCS—local sharing is necessary but may not be sufficient across machines. Operational check: put a shared token bucket or semaphore in front of UCS GETs, load-test with five workers, and confirm 429 rates fall while inventory freshness stays within the city’s poll SLA. Centralize the limiter near the HTTP client wrapper so new UCS poller threads cannot bypass pacing by calling the session directly. Expose limiter wait metrics; rising wait with falling 429s shows the shared budget is doing its job for the city’s inventory fleet.