Fault Isolation
In a monolithic application, a memory leak in one component, or even a third-party library, can affect the entire application and be hard to track down.
One of the benefits of a microservices architecture is the isolation of components or features. If one service crashes, it’s quite possible the rest of the application can continue to operate until that service recovers. This of course assumes the service is implemented to handle the faults. Also, if one service is suffering from growing memory pressure due to a leak, it can be much easier to identify the service causing the issue. We might still be able to handle requests for the application even though one of its services is down. As depicted in Figure 1.4, even though one service is unhealthy and can be causing the process to crash, other services remain unaffected. As long as they are implemented correctly they can remain healthy.
For example, if our recommendation service goes down, customers are still able to make their purchase. Customers might not be presented with recommendations and some potential sales could be lost, but not all of them. The authentication service going down can be more devastating, but instead of a complete service outage, users could still fill their carts, and when they are ready for check-out, can be presented with a screen warning them that if they are not be able to complete their purchase at that moment, they should try again later. Because we can quickly roll back when there is a failure, the outage is short and the business impact, although potentially significant, is minimized.