The alpha, twice a week
That was 2 min.
Get the best new moments in your inbox every Wednesday and Saturday. It's free.
Check your inbox
We sent a link to your address. Click it to finish signing up. Not there in a minute? Look in spam.
or
The Pragmatic Engineer · 2 min · Oct 7, 2026
Robustness is only one of four parts of resilience
Sam Newman
Gergely OroszHost · Host, The Pragmatic Engineer
Spent four years at Uber heading mobile, web and backend teams; shipped part of its payments system.
About this segment
Sam walks through David Woods's four concepts, starting with robustness and rebound. Most engineers stop at robustness, which can add complexity and new failure modes.
From “Building resilient systems with Sam Newman”, Oct 7, 2026. Watch the full episode
Thanks. We'll look at and fix what's off.
“One of the really nasty things about robustness is the things we often do to make our systems more robust in turn increases the complexity of our system”
Takeaways
- Robustness absorbs known failures, like Kubernetes replacing a failed pod
- Measures that add robustness also add complexity and new failure types
- Rebound is how quickly you detect and recover once something goes wrong
In this episode
Full episode- 1:21:33Fail open or fail closed depends on the business context4:39
- 1:08:19Make retries safe with idempotency keys, not just fingerprints4:48
1:26:21Robustness is only one of four parts of resilience1:58
- 5 more moments in the full episode
Transcript
Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.
- 1:26:33
fails and kubernetes means a replacement now the pod failing that's a perturbation it's gone a bit wrong but we dealt with it great so that's the start and the thing is most engineers i speak to they focus entirely on this. Don't look at the other three. They focus entirely on this. One of the really nasty things about robustness is the things we often do to make our systems more robust in turn increases the complexity of our system, which in turn increases the surface area for new types of failure.
- 1:27:00
I bring Kubernetes in to deal with the failure of a container. Now I've got Kubernetes and that becomes... And that's not solvable, by the way. That's just something to be aware of. That is also why sometimes people don't go multi-region or multi-cloud because it's increasing the surface of other failure types. So that's number one, it's robustness, right? Can we just do one of those things? And for things to be robust, we have to know about them ahead of time.
- 1:27:22
This is predictable, we deal with it. Then there's rebound, which is when something does happen and goes wrong, how quickly can we recover? So this is typically the time to recovery, well, time to detection and time to recovery. Yeah, and there's different ways of measuring that. And I talk about in the DR chapter, I talk about, you know, data loss. Disaster recovery. Exactly, yeah. but that's like how quickly can we get back up and running so we've gone into a degraded functionality how quickly can we get up and running so that's that's thinking about the rebound and again for that you have to be very humble as a developer because the robustness is the system will never fail it's like but what if we got it wrong okay well we have to admit things go outside and then i guess for recovery on on how you can recover this is where i mean if you
- 1:28:02
want to do it well teams that are serious about this they they do uh simulations of the system going down this is where