1. Concept library
  2. Java & Spring Boot
  3. Module 12: Resilience and messaging

Concept

Retries and timeouts

Every remote call needs a timeout, and only some deserve a retry: idempotent ones, with backoff and a cap. Retries without timeouts or limits turn a slow dependency into an outage of your own.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

  1. Explain why every remote call needs a timeout
  2. Add a retry with backoff and a cap to an idempotent call
  3. Spot the retried POST that creates a second order

In practice

A few lines that show Retries and timeouts doing its job.

Java
var client = RestClient.builder()
    .requestFactory(factory(Duration.ofSeconds(2), Duration.ofSeconds(5)))  // connect, read
    .build();

@Retry(name = "catalog")        // resilience4j.retry.instances.catalog:
Price priceOf(String sku) {     //   max-attempts: 3
    ...                         //   wait-duration: 200ms
}                               //   enable-exponential-backoff: true

The common mistake

Watch for

Retrying a POST that is not idempotent. A request that timed out may have succeeded, and the retry creates a second order or charge. Use idempotency keys or retry only safe calls.

What to know first

Your roadmap puts these before Retries and timeouts, unless you already know them.

How it stays learned

Once a session shows you understand Retries and timeouts, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

  1. Day 3First recall, while it is fresh
  2. Day 7Second, a week on
  3. Day 18Last, when it has settled
Next in the moduleEvent-driven messaging →