Microservices Design Patterns Series — Part 2/5

Building Resilient Systems with Design Patterns

---

Source: Image from configcat

This article is Part 2 of the Microservices Design Patterns series, focusing on the Circuit Breaker Pattern and Event Sourcing Pattern.

Previously, in Part 1, we explored the fundamentals of microservices, emphasized the importance of design patterns, and dissected the Service Registry Pattern and the Service Mesh Pattern.

This article explores two key components in microservices architecture: the Circuit Breaker Pattern and the Event Sourcing Pattern. The Circuit Breaker Pattern enhances system resilience by detecting and managing failures, preventing widespread disruptions. In contrast, the Event Sourcing Pattern captures and stores sequential events, enabling reconstruction of the system state at any time. 

Microservices Design Patterns

Circuit Breaker Pattern

The circuit breaker pattern functions akin to an electrical circuit breaker. Once the count of consecutive failures surpasses a specific threshold, the circuit breaker is triggered, halting any further connections to the remote server for a predetermined period. During this interval, the remote service has the opportunity to recover or restart itself. Following this timeout, the circuit breaker conducts tests to determine if requests can successfully pass through. If the test succeeds, it resumes directing requests to the remote service. However, if the test fails, the circuit breaker waits for the specified duration once more before reattempting.

Source: Image from jstobigdata

A circuit breaker can exist in one of three states:

CLOSED : The remote service is operating normally, and no intervention is needed.

OPEN: The remote service is not responding as anticipated, potentially due to being down or unresponsive. All requests are blocked. This state is activated only after a specified number of failures have been encountered.

HALF OPEN : The circuit breaker keeps track of successful attempts to initiate remote calls. This enables verification of whether the remote server has resumed operation and is functioning correctly.

Below are the primary stages in the process:

1. Monitoring: The Circuit Breaker consistently monitors the health and performance of the services it safeguards.

2. Setting Thresholds: It establishes thresholds for various metrics like response times, error rates, or resource utilization.

3. Tripping: If the monitored metrics surpass predefined thresholds, the Circuit Breaker “trips,” effectively halting further requests from reaching the failing service.

4. Fallback: Instead of instantly rejecting requests, the Circuit Breaker might offer a fallback response or utilize cached data to sustain some level of service availability.

5. Retry Mechanism: Following a specified time period or when the failed service recuperates, the Circuit Breaker may endeavor to redirect traffic back to the service.

Example: Consider a popular e-commerce website with multiple microservices handling different functions like product catalog, payment processing, and order fulfillment. If the payment processing service experiences a sudden surge in traffic or encounters technical issues, the Circuit Breaker Pattern kicks in.

Source: Image from www.alvarolorente

It detects the problem, prevents further requests from reaching the failing service, and possibly redirects users to a cached version of the payment page or displays a message indicating temporary unavailability. Once the payment service recovers, the Circuit Breaker gradually resumes normal operation, ensuring minimal disruption to the overall shopping experience.

You can utilize the Python Circuit Breaker library to implement the Circuit Breaker pattern in Python, while for Java, you can use the Resilience4j library to achieve the same functionality.

Event Sourcing Pattern

The Event Sourcing Pattern operates by capturing and persisting a sequential log of events that occur within a system. Each event represents a state change or action, providing a comprehensive history of system behavior over time. By storing events rather than current state, developers can reconstruct the system’s state at any point in time, enabling scalability, auditability, and resilience in distributed environments.

Source: Image from cloud-native-daily

Instead of simply storing the current state of each order as a row in an ORDERS table, the application persists each Order as a sequence of events. The CustomerService can subscribe to the order events and update its own state. [ 3]

Below are the main Components of Event Sourcing Pattern:

1. Event: Represents a discrete system occurrence or state change, containing essential details such as event type and associated data.

2. Event Store: Central storage for all system-generated events, maintaining an immutable log of activities in sequential order.

3. Event Handler: Processes events and updates system state accordingly, performing tasks like database updates or triggering further actions.

4. Aggregate: Domain-specific grouping of related events, encapsulating business logic and ensuring consistent event application to maintain entity state.

5. Event Stream: Sequence of events for a particular aggregate instance, representing its history.

6. Event Publishers: Components responsible for disseminating events to interested parts of the system, such as other bounded contexts or external systems.

7. Event Subscribers: Components that subscribe to events they are interested in, including other aggregates or event processors that take action upon event occurrence.

8. Command: Client-initiated requests to execute actions within the system, resulting in event generation reflecting the command outcome.

Example: Consider a banking application implementing the Event Sourcing Pattern. Each transaction, such as deposits, withdrawals, or account transfers, is recorded as an event in the event log. If there is a need to reconstruct the balance of an account at any given time, the system can replay the relevant events to derive the current balance accurately.

---

This concludes Part 2 of the five-part series. Stay tuned for Part 3, where we will explore into Saga and API Gateway Pattern.

References

1. Jstobigdata. (n.d.). Circuit Breaker Pattern in Microservices. Retrieved from https://jstobigdata.com/architecture/circuit-breaker-pattern-in-microservices/

2. Microsoft Learn. (n.d.). Event Sourcing pattern — Azure Architecture Center. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

3. Microservices.io. (n.d.). Event Sourcing Pattern. Retrieved from https://microservices.io/patterns/data/event-sourcing.html