รูปแบบด้านความทนทาน: Circuit Breaker การลองใหม่ และการหมดเวลา

In a microservices network, calls cross machines and links that will fail. Resilience patterns keep one slow or broken service from dragging down the whole system.

A call with no timeout can hang forever, exhausting threads and connections. Every remote call must have a deadline.

Retrying immediately after a failure can amplify an outage — a struggling service gets hit even harder. Retries must be bounded and spaced.

Increase the wait between attempts exponentially so a recovering service gets breathing room.

If many clients back off on the same schedule they retry in sync, creating a thundering herd. Add random jitter to spread the load.

Retrying a non-idempotent write (like 'charge card') can double-execute it. Only retry safe operations, or use idempotency keys to make writes safe.

A circuit breaker tracks failures to a dependency. After too many, it opens and fails fast instead of waiting on a dead service.

This stops resources from piling up on a doomed call.

A circuit breaker has three states:

• Closed — calls flow normally
• Open — calls fail immediately
• Half-Open — a few test calls probe recovery

A minimal breaker counts failures and trips after a threshold, refusing calls until a cooldown elapses.

When a breaker is open, return a sensible fallback: cached data, a default value, or a reduced feature set. A degraded response beats a total failure.

The bulkhead pattern isolates resources (thread pools, connection pools) per dependency, so one saturated dependency cannot starve the others.

You can now build resilient service calls:

• Always set timeouts
• Bounded retries with exponential backoff + jitter
• Retry only idempotent operations
• Circuit breakers (closed/open/half-open) to fail fast
• Fallbacks and bulkheads for graceful degradation

This complements your load balancing, service mesh, and API gateway lessons.