Why Extending Timeouts in Spring Cloud Can Crash Your System (And How to Fix It)

1. Introduction

Many companies use Spring Cloud to build microservice architectures. While it works for small user bases, high‑traffic systems (thousands of concurrent requests per second) expose several issues.

2. Scenario and Initial Problem

A startup built its core services with Spring Cloud. After a period of development the system handled a few hundred thousand registered users and a few thousand daily active users. As data grew to millions of rows and some services executed complex multi‑table SQL without proper indexes, response times slowed to several seconds, causing page hangs.

Developers, unaware of the root cause, simply increased Feign/Ribbon and Hystrix timeout settings, hoping longer timeouts would hide the latency.

3. Why Extending Timeouts Is Not a Solution

Increasing timeouts only masks the underlying performance problems. When a service’s thread pool has limited threads, each blocked call holds a thread for seconds; under high concurrency the pool exhausts, leading to complete hangs and forced restarts.

4. Root‑Cause Analysis and Optimisation Steps

Step 1: Refactor heavy SQL in the critical service B, move complex business logic to Java, keep database queries simple, and add appropriate indexes. This reduced response time from seconds to tens of milliseconds.

Step 2: Set reasonable timeout values (generally ≤1 s) for Feign/Ribbon and Hystrix.

Step 3: Configure retry policies to handle occasional network spikes, ensuring failed calls are retried on other instances.

Step 4: Ensure idempotency of retried operations, e.g., by using unique database indexes or Redis‑based unique keys.

5. Scaling the System

When user volume grew to millions, the team added more service instances, introduced read‑write splitting with master‑slave databases, and monitored thread‑pool saturation.

6. Final Outcome

After the optimisations, service B responded within tens of milliseconds, timeouts stayed under one second, and the system handled peak loads without hangs.

Images illustrate the before‑and‑after performance metrics.