liveBook · Manning

Retry

As explained in Platform Engineering on Kubernetes

A retry mechanism automatically repeats a failed operation according to configured retry conditions and timing.

A retry mechanism repeats a failed service-to-service request under defined conditions. Exponential backoff varies the delay between attempts, giving the failing service time to recover without being flooded. section 7.1.2

Use retries as one part of a broader service-interaction design:

  • Pair retries with other cross-cutting concerns such as circuit breakers, rate limiting, and observability. section 7.1.2
  • Consider how retry behavior affects troubleshooting when services use different frameworks or dependency versions. section 7.1.2

Service A calls Service B

When Service B temporarily fails, Service A retries the request with increasing delays rather than issuing requests at a fixed interval. The delay gives Service B time to recover and reduces retry pressure. section 7.1.2

Figure 7.3 Service-to-service interactions retry mechanisms

Visualizes retry mechanisms in service-to-service interactions. section 7.1.2

How Platform Engineering on Kubernetes covers it

How deep it goes
Explains exponential backoff and its rationale, but does not specify retry conditions, limits, or configuration.
Examples
Uses Service A and Service B to illustrate delayed retries during a failed interaction.
What it assumes
Assumes familiarity with services communicating across service-to-service boundaries.
What you can do after
Evaluate how increasing retry delays can allow recovery while reducing request pressure on a failing service.
How it connects
Connects retries with circuit breakers, rate limiting, observability, resiliency, and service-to-service communication.

Also explained in

Compare how 21 books explain retry →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Platform Engineering on Kubernetes. The section links point to the parts of the book it draws on.