**Parent Topic**: [[System Design/README]] On a traditional website, request rate is bounded by how fast users can click — to double load you need double the users. That **axiom breaks for clients that act without user input**: a phone app syncing on a timer, or a page that auto-refreshes. Here a design choice silently sets the load — a client syncing every **60 seconds instead of 600 causes 10x the load**. Three failure patterns and their fixes: - **Retry storms** — clients retrying a failing, overloaded service add load, causing more failures. Fix: exponential backoff, and retry only appropriate errors (a network error warrants a retry; a 4xx client-side error does not). - **Synchronized thundering herd** — an app developer picking "2 a.m." for updates produces a nightly barrage and silence otherwise. Fix: each client picks its time randomly. - **Synchronized retries** — even backoff (1s, 2s, 4s…) re-synchronizes after a spike. Fix: **jitter** every delay by a random amount. A powerful launch tool is **server-side client control**: clients periodically fetch a config that toggles features or tunes sync/retry rates. Shipping new functionality dormant in the client — activated later via config — de-risks launches and makes aborting a launch as easy as switching the feature off. *Source: [[Site Reliability Engineering]] — Ch 27 — Reliable Product Launches at Scale*