A museums and culture department polls thousands of SD-WAN Edges through vManage APIs and starts receiving rate-limit responses. Which client strategy is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Rate limits are the museum velvet rope—push the whole crowd at once and security stops you. Stagger the Edge polls, slow down when told, and cache what you can. More parallel hammers just get more 429s.
Full Explanation
Museums polling thousands of SD-WAN Edges through vManage APIs and receiving rate-limit responses should stagger and throttle requests, honor rate-limit feedback, and batch or cache where possible. Client-side courtesy and backoff keep inventory jobs successful without abusing the controller. Unbounded parallelism is the wrong response to 429s.
Spinning up unbounded parallel workers until every Edge is queried in one second worsens rate limits. Ignoring 429 responses and keeping the same aggressive schedule continues failures. Bypassing vManage to scrape each Edge CLI simultaneously over SSH creates a different overload and consistency problem.
Exam caveat: respect Retry-After or vendor-specific limit headers when present; add jitter to avoid synchronized storms. Operational check: implement throttle/backoff, test against lab rate limits, cache static inventory fields, and alert if completion time exceeds the museums SLA. Prefer bulk endpoints when vManage offers them. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services. Re-validate after the next maintenance window that telemetry, API results, and device state still match the documented design intent.