A worker that polls every Meraki site every second exhausts the published controller quota and starves sibling civic apps. What design move should be chosen before implementation?
Select an answer to reveal the explanation.
Short Explanation
A shared water main has a meter—blasting every site every second empties the tank for everyone. Design for the vendor rate limit up front: shared poller, slower interval, or events. Ignoring the quota is not a plan.
Full Explanation
Platform rate limits are first-class design constraints. A worker that polls every Meraki site every second will exhaust published quota and starve sibling civic apps. Before implementation, choose aggregation (one shared poller), longer intervals aligned to freshness needs, or event-driven refresh (webhooks where offered) so the municipal estate shares the meter fairly.
Ignoring the published quota and adding more pollers fails by accelerating exhaustion. Moving polling into every browser tab fails by multiplying clients, exposing credentials risk, and making quota unpredictable. Deleting sibling apps so one worker owns the entire quota fails as governance and does not scale as a design strategy.
Exam caveat: wanting data as fresh as possible is not a blank check against vendor limits; document freshness SLOs that fit the quota.
Operational check: track 429 rates and remaining quota metrics per Meraki organization; validate that one aggregated poll schedule keeps sibling apps error-free under normal load.
Quota design also covers backoff when 429 appears: honor Retry-After, jitter retries, and shed noncritical poll frequency before critical sibling apps starve. A Meraki-heavy water or library estate that ignores published limits will look healthy in demos and fail under concurrent civic workloads. Treat rate limits like bandwidth caps in capacity planning.