Resilience
Resilience is the capacity of a system or organization to withstand disruption, adapt, recover, or continue functioning acceptably.
Elixir in Action, Third Edition
Fault tolerance is the ability of a system to continue providing acceptable service when components fail or errors occur.
- How it is used
- Frames fault tolerance as the operational foundation for continuously available, responsive, concurrent, and distributed server systems.
- How deep it goes
- Explains failure isolation, detection, recovery, supervisors, process links, fallbacks, and distribution, while deferring detailed production diagnosis.
- Examples
- Uses a spawned-process crash, an isolated to-do system, database-cache fallback, queued writes, and multi-machine failover scenarios.
- What you can do after
- Build it with BEAM processes, links, supervisors, and distribution to isolate failures and recover service.
Read how Elixir in Action, Third Edition explains resilience →
Amazon Web Services in Action, Third Edition: An in-depth guide to AWS
A fault-tolerant service continues providing its intended functionality despite failures in components or infrastructure.
- How it is used
- Guides the design of AWS applications that continue serving users when components or infrastructure fail.
- How deep it goes
- Explains architectural redundancy and code practices, but the supplied evidence does not specify deployment commands.
- Examples
- Uses failed EC2 instances, Availability Zone outages, and load-balanced or queue-based workloads to show how service can continue.
- What you can do after
- Build it from scratch using redundant stateless EC2 instances across Availability Zones, decoupled work, retries, and idempotent operations.
Quarkus in Action
Fault tolerance is the ability of a system to continue providing acceptable service despite failures in its components or dependencies.
- How it is used
- Protects cloud-native service requests from cascading failures when components or dependencies fail.
- How deep it goes
- Defines five fault-tolerance patterns and works through annotated retry and fallback; defers the programmatic API.
- Examples
- Uses a Reservation-to-Inventory availability request with 25 delayed retries and an empty-list fallback.
- What you can do after
- Apply it via MicroProfile Fault Tolerance annotations to protect a Quarkus service call with retry and fallback.
Effective Platform Engineering
Resilience is the ability of a system to continue providing acceptable service or recover when experiencing faults, disruption, or degraded conditions.
- How it is used
- Positions resilience as the primary architectural outcome for platforms that must protect service and data during failures.
- How deep it goes
- Distinguishes resilience from availability, then connects it to self-healing orchestration and measurable service objectives.
- Examples
- Uses data-center failures, Kubernetes recovery actions, and contrasting response-time and outage profiles as concrete examples.
- What you can do after
- Operate/configure it by defining service objectives, tracking them observably, and applying orchestration that restores undesired states.
Read how Effective Platform Engineering explains resilience →
Platform Engineering on Kubernetes
Resilience is the ability of an application or service to continue providing useful functionality despite failures in its components or dependencies.
- How it is used
- Keeps distributed applications partially usable when services, networks, or dependencies fail.
- How deep it goes
- Demonstrates caches, replicas, retries, and exponential backoff, but does not standardize behavior across technology stacks.
- Examples
- Uses a scaled-down Agenda service, cached agenda entries, unhealthy-service reporting, replicas, and Java or Go retry libraries.
- What you can do after
- Apply it via Kubernetes scaling, cached fallbacks, service replicas, and language-specific retry libraries.
Read how Platform Engineering on Kubernetes explains resilience →
The Art of Code
Resilience is the ability of a software system to continue providing acceptable behavior during disruptions and recover from failures.
- How it is used
- Supports reliable operability by helping systems recover from failures and remain stable when demand exceeds safe capacity.
- How deep it goes
- Defines two resilience dimensions and names recovery, overload-control, containment, and degradation patterns without detailing their implementations.
- Examples
- Uses traffic spikes, dependency outages, a slow payment service, product-catalog isolation, caches, watchdogs, and reduced noncritical features.
- What you can do after
- Apply it via retries, circuit breakers, fallbacks, rate limiters, bulkheads, time limiters, caches, watchdogs, and graceful degradation.
Architecting an Apache Iceberg Lakehouse
Fault tolerance is the ability of a system to continue operating correctly or recover without unacceptable data loss or corruption after component failures.
- How it is used
- Frames storage and ingestion choices around continued operation, recovery, data quality, and trustworthy downstream analytics.
- How deep it goes
- Explains replication, delivery semantics, checkpointing, retries, resumability, and atomic commits, but stops short of detailed implementation configuration.
- Examples
- Uses HDFS replication, Apache Flink checkpointing, and Apache Iceberg snapshot commits to illustrate recovery and consistency.
- What you can do after
- Evaluate ingestion architectures by comparing delivery guarantees, replayability, retry behavior, checkpointing, and commit coordination.
Read how Architecting an Apache Iceberg Lakehouse explains resilience →
Data-Driven Cybersecurity
An organization’s ability to prepare for, withstand, adapt to, and recover from disruptive events such as cyberattacks.
- How it is used
- Guides planning for disruptions and uses cybersecurity metrics to inform risk and resource decisions.
- How deep it goes
- Explains capacity, dependencies, monitoring, response exercises, and measurement without prescribing a numeric resilience score.
- Examples
- Illustrates hybrid-cloud and vendor dependencies, then compares oversight dashboards showing performance-related adjustments rising from five to fifteen per quarter.
- What you can do after
- Evaluate/understand resilience through availability, incident response, and oversight trends to identify gaps and prioritize resources.
Kafka for Architects
Fault tolerance is the ability of a system to continue providing its required behavior despite failures in components or dependencies.
- How it is used
- Protects business data and service communication from component failures in distributed, event-driven architectures.
- How deep it goes
- Explains partition replication and durable storage, but leaves availability dependent on correct configuration and broader deployment choices.
- Examples
- Uses financial, healthcare, e-commerce, clickstream, fraud-scoring, telemetry, and operational-alerting scenarios.
- What you can do after
- Evaluate Kafka deployment and replication choices against data-loss tolerance, scalability, compliance, and operational constraints.
Latency
Fault tolerance is the ability of a system to continue providing acceptable service despite failures of components or dependencies.
- How it is used
- Uses replication to keep production systems operating through component failures while preserving acknowledged updates.
- How deep it goes
- Explains failure classes, linearizability, replica counts, and quorum arithmetic, but does not detail a replication protocol.
- Examples
- Uses three- and five-node clusters, server crashes, power outages, network disconnections, disk failures, and Byzantine behavior.
- What you can do after
- Apply via state machine replication by selecting replica counts that preserve a quorum after non-Byzantine failures.
Lead Developer Career Guide
The ability to remain effective and recover while facing difficulty, pressure, or setbacks.
- How it is used
- Applies resilience to interviews, career setbacks, mentoring, and emotionally intelligent workplace interactions.
- How deep it goes
- Illustrates resilience through attitudes, preparation, reflection, mentoring, and lived failure rather than formal psychological theory.
- Examples
- Uses stressful interviews, a failed application migration, layoffs, mentorship conversations, and workplace learning resources as examples.
- What you can do after
- Practice/perform resilience by preparing for stress, responding honestly, seeking perspective, and recovering without over-personalizing failure.
Think Distributed Systems
The ability of a system or protocol to continue providing acceptable behavior despite component or network failures.
- How it is used
- Frames distributed-system behavior and failure handling around guarantees that remain meaningful when components or networks fail.
- How deep it goes
- Defines states, transitions, recovery, safety, and liveness, then stops short of detailed implementation mechanisms.
- Examples
- Uses a one-process variable with legal, illegal, and intolerable values plus normal, repair, and failure transitions.
- What you can do after
- Evaluate failure behavior by identifying legal states, failure transitions, recovery paths, and preserved safety or liveness guarantees.
Go in Practice, Second Edition
Fault tolerance is the ability of a system to continue operating or recover when components or operations fail.
- How it is used
- Handles unreliable HTTP connections by detecting failures, retrying recoverable operations, and exposing persistent errors to alerting.
- How deep it goes
- Classifies several timeout forms and implements bounded recursive retries with resumable downloads, without covering broader failure policies.
- Examples
- Uses a timeout classifier, an HTTP request, a resumable file download, and a five-minute HTTP client timeout.
- What you can do after
- Builds Go HTTP operations that detect timeout errors, resume downloads, retry bounded failures, and report unrecoverable errors.
Read how Go in Practice, Second Edition explains resilience →
Related concepts
- uptimecontrasts with · Uptime is the duration or proportion of a specified period during which a system or service is operational and available to provide its intended function.
- replicationaddressed by · Replication is the creation or maintenance of multiple copies of data, state, or functionality across separate locations or components.
- retryuses · A retry is a subsequent attempt to perform an operation after an earlier attempt fails or does not complete successfully.
- redundancycontrasts with · Redundancy is the presence of duplicate or overlapping information, components, or resources, whether intentional or unnecessary.
- Tree-of-thoughtproduced by · Tree-of-thought is a reasoning technique that explores and evaluates multiple branching paths of intermediate reasoning to develop a solution.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.