Fault isolation

As explained in Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform

Fault isolation is the containment of a failure within one component so that it has minimal effect on other components or users.

Fault isolation contains a failure within one component so it has minimal effect on users and the rest of the application. In a microservices system, the gateway can stop a failing service from propagating errors to the frontend, allowing the application to continue in a degraded state. section 11.4.5

Implement fault isolation with safeguards that limit waiting, repeated failure, and resource consumption:

• Set timeouts so unresponsive internal or external requests abort quickly instead of waiting indefinitely. section 11.4.6
• Use retries for potentially temporary failures, while bounding attempts and adding a wait between them. section 11.4.6
• Combine timeouts and retries with circuit breakers and bulkheads to prevent a local failure from overwhelming dependent components. section 11.4.5
• Return a focused error for the unavailable feature while keeping unrelated application functions available. section 11.4.5

Video upload becomes unavailable

If the video-upload microservice stops responding, an unprotected request can carry the error to the frontend and disrupt the whole service. With gateway safeguards, the fault remains inside the cluster: users see that video upload is unavailable, but can continue using the rest of the application. section 11.4.5

Figure 11.13 Isolating faults within the cluster from the user

Trace the contrast between an error propagating to the user and a gateway containing the fault within the cluster. section 11.4.5

How Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform covers it

How deep it goes

Explains containment through timeouts, retries, circuit breakers, and bulkheads, with implementation examples for timeouts and retries.

Examples

Uses a failed video-upload service, Dropbox requests, Axios configuration, and a bounded JavaScript retry function.

What it assumes

Assumes internal HTTP requests and microservice architecture while introducing failure handling through concrete request examples.

What you can do after

Operate/configure microservice requests with bounded timeouts, retries, and user-visible degraded behavior.

How it connects

Connects microservices with graceful degradation, fault tolerance, timeouts, retries, circuit breakers, and bulkheads.

liveBookmanning.com

Read Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Akka in Action, Second EditionFault isolation is the containment of a component failure so that the failed component can be terminated without necessarily stopping unrelated components.

Compare how 2 books explain fault isolation →

Related concepts

• microservice architectureaddressed by · Microservice architecture is a software architectural style that organizes an application as independently deployable services with focused responsibilities that communicate through defined interfaces.
• monolithic architecturecontrasts with · Monolithic architecture is a software architecture in which an application's major functionality is organized and deployed as a single integrated unit.
• hierarchyused by · A hierarchy is an organization of entities into nested or ordered levels connected by parent-child, containment, or broader-to-narrower relationships.
• API gatewayimplemented by · An API gateway is an intermediary that provides an entry point for client requests to backend APIs or services and routes or otherwise mediates those requests.

This explainer was generated by Manning's knowledge graph from the text of Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform. The section links point to the parts of the book it draws on.