Several reasons this doesn’t pan out in practice. 1) Retries. When one replica of a microservice is down, the calling service can retry, get service from an up

Several reasons this doesn’t pan out in practice. 1) Retries. When one replica of a microservice is down, the calling service can retry, get service from an up replica, and the outage is routed around 2) Queues. Microservices lend themselves to queue and worker patterns where downtime on individual services has less effect on overall service availability 4) Outages have narrower impact. One microservice losing access to its database breaks the functionality that relies on that microservice; other functionality runs fine. 5) Changes have smaller blast radius. Most outages are caused by changes; changes in monoliths that cause outages are more likely to take the whole system offline (eg stack overflows and infinite loops crash processes). Changes that cause outages in microservices can’t knock other services offline.