Preventing Cascading Failures with Circuit Breaker Pattern

Modern microservices rarely operate in isolation. A single user request often triggers multiple synchronous calls between services to complete an operation. While this distributed model improves scalability and flexibility, it also introduces new failure modes. If a critical downstream dependency becomes slow, throttled, or unavailable, upstream services may block while waiting for responses. Over time, these blocked requests consume compute resources, threads, and network capacity, degrading the overall system.

In this Cloud Lab, you’ll explore how AWS Lambda and Amazon DynamoDB can be used together to implement the Circuit Breaker pattern. Lambda is used to build both the upstream service and its downstream dependency, while DynamoDB acts as a persistent store for circuit state across stateless Lambda executions.

By the end of this Cloud Lab, you will understand the Circuit Breaker pattern in theory, implement it in a serverless application, and observe firsthand how it prevents cascading failures and improves system stability.

The following is the high-level architecture diagram of the final infrastructure that you will build in this Cloud Lab:

Cascading failures in microservices

Serverless systems are built from small, composable pieces, often a chain of Lambda functions, APIs, queues, and databases. That modularity is great for speed and scale, but it also introduces a classic distributed-systems failure mode: cascading failures.

A cascading failure occurs when one unhealthy dependency (slow, throttling, or down) causes its callers to pile on retries, timeouts, and resource consumption until they become unhealthy as well. AWS describes this problem as “cascading of timeouts or failures” during synchronous execution, which can degrade performance across the entire application when callers repeatedly retry and consume shared resources, such as network capacity and thread pools.

The Circuit Breaker pattern is a practical way to stop this domino effect. It sits between a caller and a dependency (callee) and prevents repeated calls to a resource that is very likely to fail, while still providing a controlled way to detect recovery.

What is a circuit breaker?

A circuit breaker trips when it detects atypical behavior and blocks further flow until it’s safe again. In software, the breaker monitors failures/timeouts, and when failures exceed a threshold, it opens the circuit and fails fast, returning an immediate error instead of continuing to call the downstream system.

The circuit breaker model has three states:

• CLOSED: Requests flow normally, while failures are tracked.

• OPEN: Requests are rejected immediately (fail fast) without calling the downstream service.

• HALF-OPEN: After a cool-down period, the breaker allows a limited “probe” request(s). If it succeeds, the breaker closes; if it fails, it reopens.

This “open → probe → close” behavior is what stops cascading failures: it reduces pressure on the failing dependency and frees the caller to remain responsive, instead of waiting on timeouts and burning resources.