GuideIntermediate
Resilience And Reliability Patterns
Learn to make a distributed system survive the failure of its parts: timeouts, retries with backoff and jitter, idempotency, circuit breakers, bulkheads, graceful degradation, and load shedding. The guide's core is partial failure — in a distributed system something is always down or slow — and how to stop a dependency's failure from taking down the whole system. You work through a single case study from start to finish: Mercado's checkout flow, where `orders` calls `payments` and `shipping`, and those dependencies genuinely fail and slow down. Everything is simulated and measured in Python with configurable failure rates and latency: you'll measure thread exhaustion without a timeout, a retry storm without backoff, how many calls a circuit breaker saves when a service is dead, how a bulkhead isolates a slow dependency so it doesn't drain the others, and the checkout's success rate before and after hardening it. The capstone combines every pattern over Mercado's full checkout flow and measures the result.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Understand partial failure and cascading failure: why something is always down or slow in a distributed system
- Set correct timeouts (connection and read) and measure how they prevent thread/connection exhaustion
- Retry with exponential backoff and jitter to avoid a retry storm, and know when NOT to retry
- Implement idempotency with an `idempotency_key` so a retry doesn't charge or execute an operation twice
- Apply circuit breakers (`CLOSED`/`OPEN`/`HALF_OPEN` states) to stop hammering a dead service, and measure automatic recovery
- Isolate dependencies with bulkheads so a slow one doesn't drain the pool for the others
- Design graceful degradation and load shedding so the system fails soft, not hard, under overload
- Harden a real flow end to end by combining every pattern, measuring success rate and latency before and after
Before you start
What you need to bring
It's for you if...
- Backend devs whose service calls unreliable dependencies (network, third parties, other microservices) and don't know how to harden it
- Devs who've already wrapped a `try/except` around an external call but never measured whether it actually helps
- Anyone who needs to understand circuit breakers, bulkheads, or backoff before reaching for a library like resilience4j or Polly
- Teams that suffered a cascading failure and want to learn to design against it with judgment, not patches
Requirements and materials
- Basic Python (every simulation and measurement in this guide runs in Python)
- Having built a backend service that calls another service or external API
- No prior experience with resilience libraries or distributed systems required
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: the day `shipping` took down the whole checkout
- 2. Partial failure: in distributed systems, something is always broken
- 3. The fallacies of distributed computing
- 4. Cascading failure: how a slow dependency takes everything down
- 5. Pool exhaustion: why a slow `shipping` exhausts `orders`' threads
- 6. Why the monolith didn't have this problem
- 7. The map of Mercado's checkout failure points
- 8. Mini-project: map the failure modes of Mercado's checkout
- 1. Module introduction: the retry that charges twice
- 2. The retry's double charge, measured
- 3. The idempotency key
- 4. How the server deduplicates and saves the result
- 5. Operations idempotent by design
- 6. PUT vs POST vs GET
- 7. The exactly-once myth
- 8. Project: make Mercado's `charge` idempotent and test it with retries
- 1. Module introduction: stop hitting a dead one
- 2. The cost of keeping calling a dead one, measured
- 3. The three states of the circuit breaker
- 4. From CLOSED to OPEN: opening by threshold
- 5. HALF_OPEN and automatic recovery
- 6. Circuit breaker vs. retry: insisting vs. giving up
- 7. Choosing the threshold and the cooldown
- 8. Project: put a breaker on `shipping` in Mercado and measure
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!