TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
The Pragmatic Engineer published excerpts from Sam Newman’s 2026 book, Building Resilient Distributed Systems, covering disaster recovery and resilience for AI-powered software. The material explains recovery targets and failover patterns, while arguing that teams should plan for changing models, provider constraints and service interruptions.
The Pragmatic Engineer has published excerpts from Sam Newman’s 2026 book, Building Resilient Distributed Systems, addressing disaster recovery and the reliability challenges of AI-powered software. The material sets out ways for engineering teams to define acceptable data loss and downtime, choose recovery arrangements, and plan for uncertainty involving AI models and infrastructure providers.
In the published excerpt, Newman focuses on disaster recovery (DR): procedures for restoring systems after failures that affect large parts of an organization’s infrastructure. Examples include fires, floods, electrical problems and failures in underlying cloud infrastructure. The excerpt emphasizes that no single recovery arrangement suits every service; reducing acceptable downtime or data loss generally brings greater cost and complexity.
Newman describes two measures for setting recovery requirements. A recovery point objective (RPO) is the maximum acceptable period of data loss, determined by how recently data was backed up or synchronized. A recovery time objective (RTO) is the acceptable time a system can remain unavailable while teams restore data, provide computing resources and redirect traffic to another site.
The broader article says the book also discusses different recovery patterns: backup and restore, pilot-light failover, warm failover and multisite active-active operation. Its AI-related topics include model-provider resilience, changes to models over time, observability, and strategies such as using multiple models or vendors, making costs transparent and regularly reviewing vendors. The source presents these as subjects covered in the book, not as evidence that any one approach guarantees reliability.
Recovery Targets Shape System Resilience
The practical value of the excerpt is its focus on turning general expectations of reliability into measurable recovery targets. A team that has not agreed how much data it can lose or how long a service can be down may find it difficult to choose a recovery plan or judge whether that plan meets business needs.
Those decisions also matter as software teams incorporate AI services. The article identifies changing models and reliance on external providers as resilience concerns. If a model or provider becomes unavailable or changes in a way that affects a product, teams need to understand their alternatives and observe how their systems behave. Multiple providers or models may be among the tactics considered, but the source does not claim that this removes dependency, cost or operational risks.
Infrastructure capacity is another constraint raised by the article. It says ongoing CPU and GPU shortages mean teams cannot assume resources will always be available when needed. Disaster recovery plans that depend on obtaining replacement capacity quickly may not work as expected unless organizations account for vendor constraints and prioritize critical services.
As an affiliate, we earn on qualifying purchases.
From Site Outages to AI Dependencies
The material comes from an article in The Pragmatic Engineer featuring an interview with Newman and excerpts from his book. The article says Newman spent three years writing it, rather than the two he had originally planned, and reworked sections to account for AI. The book is published by O’Reilly Media; the excerpts are reproduced with permission, according to the source.
Newman uses “site” as a general term for the location of computing infrastructure, whether that is a public-cloud region, a private-cloud environment or a traditional data center. The recovery patterns discussed are intended to apply across these settings, though implementation details vary. The article notes that questions about combining cloud vendors are covered elsewhere in the book.
The publisher excerpt supplied here begins with disaster recovery and defines RPO and RTO. The article’s introduction also previews a second area: how to build resilience into AI-powered systems amid provider changes, infrastructure limits and uncertainty. That framing reflects the book’s engineering guidance; it is not an independently documented survey of outage trends.
“As you reduce your period of acceptable downtime or data loss, cost and complexity increase.”
— Sam Newman, in an excerpt from Building Resilient Distributed Systems
Capacity and Recovery Risks Remain
The source does not provide outage statistics, quantify how often AI-related failures occur, or establish that AI coding tools have caused a measured increase in production incidents. The article says it is seeing more outages and links that trend to more deployments and bugs, including code written by AI agents, but supplies no dataset or baseline in the provided material. That observation should be read as the article’s account, not as a verified industry-wide measurement.
The excerpt also does not prescribe specific RPO or RTO values for readers’ systems. Appropriate targets depend on each service’s needs, and the material provided does not state the costs or performance of particular recovery patterns. It remains unclear how much replacement CPU or GPU capacity would be available during a widespread disruption, or how a team’s model and vendor choices would perform in a real incident.
Teams Must Set Their Own Targets
The immediate next step for engineering teams is to determine acceptable downtime and data loss for their own systems, then assess recovery arrangements against those RTO and RPO targets. That work includes accounting for the time needed to restore data, secure replacement compute and redirect users—not simply estimating how quickly a service can restart.
For AI-powered products, the article points toward reviewing provider dependencies, tracking model behavior and making costs and alternatives visible. It does not announce a deadline, a new standard or a specific follow-up event. The book’s remaining chapters and the full disaster-recovery discussion provide further detail, but organizations will need to test their own plans against their services, vendors and available infrastructure.
Key Questions
What is the news development?
The Pragmatic Engineer published excerpts from Sam Newman’s 2026 book, Building Resilient Distributed Systems, covering disaster recovery and resilience issues for AI-powered software.
What do RPO and RTO mean?
RPO is the maximum acceptable period of data loss, based on the last backup or synchronization. RTO is the maximum acceptable time a system remains unavailable while it is restored.
Which disaster recovery patterns does the article mention?
The article lists backup and restore, pilot-light failover, warm failover and multisite active-active operation. The right choice depends on the service’s recovery needs, cost and operational complexity.
What AI-specific resilience issues does the source identify?
It points to model-provider reliability, models changing over time, observability, limited computing capacity and uncertainty about vendors. The article mentions multiple models or vendors as possible tactics, not as guaranteed solutions.
Does the source prove AI coding tools are causing more outages?
No. The article describes more outages and associates them with increased deployments and bugs, including code written by AI agents, but the supplied material includes no data or comparison baseline that establishes the cause or scale.
Source: rss
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
