Lesson 2 of 5
Resilience patterns: timeouts, retries, circuit breakers
11 min
Listen to this lesson
Every remote call an extension makes will fail at some point: S/4HANA is in a maintenance window, the network drops, a dependency slows to a crawl under month-end load. Resilience is not avoiding failure; it is deciding in advance what the extension does when a dependency fails, so that one slow system does not take down everything that touches it. The fleet order status app makes three remote calls per page: identity, the Sales Order API through a destination, and the delivery service. Each needs the same few patterns.
| Pattern | Protects against | Without it |
|---|---|---|
| Timeout | Calls that hang | Threads and connections pile up waiting; the app stalls |
| Retry with backoff | Brief, random failures | A single dropped packet becomes a user-facing error |
| Circuit breaker | A dependency that is down or overloaded | Every request waits for a timeout and keeps hammering the failing system |
| Bulkhead | One dependency consuming all capacity | A slow delivery service blocks order lookups too |
| Fallback | Unavailable data | Users see an error page instead of a degraded answer |
| Rate limiter | Overloading a dependency | The extension itself causes the outage it fears |
Timeouts first
A call without a timeout can wait forever. Set a timeout on every remote call, and set it from the user's point of view: if the fleet order page must answer within three seconds, a five-second timeout on one of its calls is a bug. The SAP Cloud SDK for JavaScript has a default timeout of 10 seconds for its timeout middleware, which you can change per request; SAP's guidance places the timeout first in the list of resilience middlewares.
Retries, carefully
Retries help when failures are random and short, and hurt when they are not. SAP's Cloud SDK guidance is blunt: use the retry middleware with caution, because it often mitigates a problem that should be solved properly, and it does not help to press the same button repeatedly when something fails consistently. Its rules are worth adopting as Contoso's: errors should be the exception, they should happen randomly so a second call has a good chance, and their source should be outside your domain. The JavaScript SDK's default retry makes three retries with exponentially growing waits (up to 2, 4 and 8 seconds). Only retry operations that are safe to repeat: reads, or writes protected by idempotency.
Circuit breakers
A circuit breaker watches the failures of calls to one dependency. When failures pass a threshold, it opens: calls fail immediately without being sent, which protects the struggling system and frees the caller. After a reset period it goes half-open and lets one test call through; success closes it, failure keeps it open. The SAP Cloud SDK for JavaScript uses these defaults: it records requests over a 10-second window; once at least 10 requests are recorded, it opens if 50% or more failed; it moves to half-open after 30 seconds. HTTP 4xx responses do not count as failures, because they do not indicate an unhealthy system. Each target system and tenant gets its own breaker instance.
- ClosedCalls flow normally; failures are counted over a rolling window
- Threshold reachedEnough requests and enough failures (SDK defaults: 10 requests, 50% failed, 10-second window)
- OpenCalls fail fast without reaching the dependency; the fallback answers
- Half-openAfter the reset timeout (default 30 seconds) one test call is allowed
- Closed or open againSuccess closes the breaker; failure keeps it open for another period
Order and fallbacks
Patterns interact, so order matters. SAP's guidance for the JavaScript SDK puts the timeout first, the circuit breaker after it, and the retry last, and recommends its resilience() helper because it builds them in the right order. Then decide the fallback for each call. For the fleet order status app, an order lookup can fall back to the last known status stored in SAP HANA Cloud, clearly labeled "as of 10:42"; a change request cannot fall back and must tell the user to try later. A fallback that silently shows stale data as current is worse than an error.
| Call | Timeout | Retry | Breaker | Fallback |
|---|---|---|---|---|
| Sales Order API (read) | 3 s | Up to 2, with backoff | Yes, per destination | Last known status with timestamp |
| Delivery service (read) | 2 s | None | Yes | Hide the delivery panel; show "temporarily unavailable" |
| Portal update (write) | 5 s | Yes, idempotent key | Yes | Queue for later; never drop |
Contoso's resilience settings for the fleet order status app (illustrative).
Platform resilience is not app resilience
SAP's architecture guidance notes that many SAP BTP services use multiple availability zones within a region, so a failure in one data center does not stop the service. That protects the platform, not your design: a region-wide outage still affects everything in the region, and SAP states that multi-region setups for BTP must be architected by the customer, with two subaccounts in separate regions, a load balancer and data and event synchronization. Contoso decided its extensions need multi-AZ resilience only; the fleet portal can tolerate a regional outage measured in hours. Writing that decision down, with the business owner's agreement, is part of the architecture.
What would you do?
At month-end, CMQ becomes very slow. The fleet order status app in test starts timing out on every page, and the S/4HANA team says the app's retries are making things worse. What is the best change?
- Every remote call needs a timeout set from the user's point of view.
- Retry only random, transient failures of safe operations, a few times, with backoff.
- Circuit breakers fail fast when a dependency is unhealthy; 4xx responses do not count as failures in the SAP Cloud SDK.
- Order: timeout, then circuit breaker, then retry; design a labeled fallback per call.
- Multi-AZ is platform resilience; multi-region is a customer architecture decision.
Check your understanding · not graded
Lesson check
1. What does an open circuit breaker do?
2. In the SAP Cloud SDK for JavaScript, do HTTP 4xx responses count as circuit breaker failures?
3. Which order does SAP recommend for resilience middleware in the JavaScript SDK?
4. What does SAP say about multi-region resilience for BTP apps?