Here’s my controversial but 100% correct advice on system design reviews: You don’t need a 40-slide architecture deck to find out if a system will survive production. Now the irony is that a lot of those decks are actually good. Boxes, arrows, a cache here, a queue there. The people who build them want the system to work. My problem with architecture diagrams is that they often make the happy path obvious and failure behavior invisible. Everything you need to know about a system’s resilience shows up when something fails. And one question gets you there faster than any diagram. Ask: who retries? Take a typical request path. The user hits “Try again.” The SDK retries. Envoy retries. The worker gets the message twice. Every answer is correct. That’s the problem. Now pull the thread. -> Timeouts. The gateway gives up at 2 seconds. The service behind it retries 3 times at 1 second each. You’re paying for work nobody is waiting for. -> Idempotency. Maybe the payment failed. Maybe it succeeded and the response got lost. No idempotency key? You just charged someone twice. -> Overload. Three layers. Each allows three total attempts. One request can become 27 calls to a service that’s already drowning. Now you might be thinking “but Raul, retries make systems more reliable!” They do. When retry ownership is explicit, attempts are bounded, and retries respect the operation’s deadline. Not when every layer independently decides to try again. So here’s the insight for today: Before you approve a design... find out who retries. If the answer is “all of them,” ask what prevents their retries from multiplying. If nobody knows, the review isn’t finished. Draw the boxes, but most of all, ask who retries.