Making Your Microservices Resilient and Fault Tolerant

If Service A calls Service B, which in turn calls Service C, what happens when Service B is down? What is your fallback plan in such a scenario?

• Can you return a pre-decided error message to the user?
• Can you call another service to fetch the information?
• Can you return values from the cache instead?
• Can you return a default value? There are a number of things you can do to make sure that the entire chain of microservices does not fail with the failure of a single component.

What Can Go Wrong in a Microservice Architecture?

There are a number of moving components in a microservice architecture, hence it has more points of failure. Failures can be caused by a variety of reasons — errors and exceptions in code, release of new code, bad deployments, hardware failures, datacenter failure, poor architecture, lack of unit tests, communication over the unreliable network, dependent services, etc.

Why Do You Need to Make Services Resilient?

A problem with distributed applications is that they communicate over a network — which is unreliable. Hence you need to design your microservices so that they are fault-tolerant and handle failures gracefully. In your microservice architecture, there might be a dozen services talking with each other. You need to ensure that one failed service does not bring down the entire architecture.

How to Make Your Services Resilient?

Identify Failure Scenarios
Avoid Cascading Failures
Avoid Single Points of Failure
Handle Failures Gracefully and Allow for Fast Degradation
Design for Failures

https://dzone.com/articles/making-your-microservices-resilient-and-fault-tole-1