Resilience Patterns in Distributed Systems: Handling Transient Failures with Retry and Circuit Breaker Strategies

Hariprasad — Sun, 28 Jan 2024 16:50:15 +0000

Transient Failures: In distributed systems, including microservices, failures are often transient. These can be due to temporary network glitches, short-lived unavailability of a service, etc

Retry Pattern: This pattern is typically used to handle transient failures by retrying the failed operation after a short delay, in the hope that the issue resolves itself quickly. However, excessive retries can lead to resource exhaustion and can compound the problem if the service is already under stress.

Circuit Breaker Pattern:

Preventing Cascade Failures: In a distributed system, if one microservice fails and other services continually try to use it, this can lead to a cascade of failures. A circuit breaker helps prevent this by "opening" and stopping calls to the failing service.
System Resiliency: It enhances system resiliency by allowing failed services time to recover, and it avoids overwhelming a struggling service with further requests.
Fallback Mechanisms: Circuit breakers often provide mechanisms for a fallback action, allowing the system to continue functioning in a degraded state instead of complete failure.

Critical Considerations for Embracing a Microservice Architecture: Three Key Questions Developers Must Contemplate

Hariprasad — Mon, 12 Jun 2023 17:46:38 +0000

These Three Questions Developers Should Contemplate Before Adopting a Microservice Architecture:

What are you hoping to achieve?
For example, independent rollout and scalable components are the primary advantages of microservices. However, these advantages also come with certain drawbacks, such as increased technological diversity, heightened operational complexity, and the need for better team coordination.
Have you considered alternatives to using Microservices?
For example, Monolith architecture.
How will you know if the transition is working?
If you have successfully reduced the complexity of the application and achieved the desired outcomes.

Sam Newman's List of Four Situations Where Microservices Might Be a Bad Idea:

Unclear domain: Getting service boundaries wrong can be expensive
Start-ups: A start-up needs to focus all its attention on finding the right fit for its product. Microservices primarily solve the sorts of problems start-ups have once they have found that fit with their customer base.
Customer installed and managed software: Microservices push a lot of complexity into the operational domain. Coping with this complexity is not something you can typically expect of your end customers.
Not having a good reason: Do not adopt microservices if you don’t have a clear idea of what exactly it is that you are trying to achieve.

Reference:

The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture

DEV Community: Hariprasad

Resilience Patterns in Distributed Systems: Handling Transient Failures with Retry and Circuit Breaker Strategies

Critical Considerations for Embracing a Microservice Architecture: Three Key Questions Developers Must Contemplate