How a slow optional service with no HTTP timeout cascaded into a full storefront outage

A recommendations service that began responding in 90 seconds instead of 80 milliseconds triggered a cascading failure that brought down four services, including product catalogue, checkout, and the mobile API, within minutes. Because the HTTP client was constructed with default settings, it had no connect or read timeout, causing each slow request to hold a worker thread for the full 90 seconds. With 200 threads and roughly 40 requests per second on that path, the thread pool saturated in about five seconds, freezing the catalogue entirely. The same default client configuration in dependent services meant the failure propagated hop by hop. The team remediated the incident by enforcing explicit timeouts across all outbound clients, adding a build-time lint rule to catch default-constructed clients, and isolating non-critical dependencies behind bounded thread pools and circuit breakers with safe fallbacks.