Rate limits, retries, and controlled recovery.
Shape upstream traffic with explicit quotas, bounded queues, error-aware retries, freshness policies, and transaction reconciliation.
Start with the actual provider limits
Record limits by operation, account, environment, and time window. Distinguish request quotas from connection limits or message limits. Do not hard-code a number from a different plan or assume that a documented maximum is a recommended operating target. Confirm the current rules before launch.
Shape traffic around the workflow
Use a bounded queue and an explicit concurrency limit for each upstream destination. Spread routine work over time rather than launching every refresh at the same moment. Where the provider permits it, cache or batch reads with a defined freshness policy. Never reduce traffic by presenting older data as newly updated.
Classify errors before retrying
A rate-limit response, a temporary service fault, a missing permission, and an invalid request require different handling. Follow documented retry timing where available and use bounded delays with jitter for appropriate transient failures. Repeatedly sending an invalid payload or unauthorized operation does not make it more likely to become valid.
Treat command retries more carefully than reads
After an ambiguous transaction timeout, reconcile the provider state before creating another instruction. Use a supported idempotency mechanism according to its scope and retention rules. A generic retry wrapper should not turn a safe listing refresh policy into repeated purchase attempts. RFC 9110 provides the underlying HTTP semantics for idempotent methods.
Budget for recovery traffic
Reconnects, pagination, replay, and reconciliation add load even when the end-user count does not change. Give recovery work a bounded share of capacity so it cannot starve current requests. Retain a manual-review route for ambiguous commands rather than allowing an unlimited loop to make the decision.
Measure the product consequence
Track queue age, failed operations, last valid observation, provider throttling, and time spent recovering. A low error count does not establish that a dashboard is fresh or an outcome is resolved. Connect request metrics to domain-level states. Use the cost-planning article to translate measured workloads into a budget.