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 discusses recovery objectives, failover options, model and vendor uncertainty, and the need to plan for infrastructure constraints; it does not report a specific outage or new reliability data.
The Pragmatic Engineer has published excerpts from Sam Newman’s 2026 book, Building Resilient Distributed Systems, outlining how software teams can prepare for major infrastructure failures and make AI-powered services more resilient. The report focuses on practical planning, including recovery targets, failover approaches and dependence on AI model providers; it is guidance from a book excerpt, not a report of a particular outage or a measured rise in failures.
Newman’s excerpt explains that disaster recovery planning addresses failures that can take out a large part of a system at once, such as fire, flooding, power problems or failures in cloud infrastructure. It distinguishes this from measures designed to keep individual service instances running. Recovery plans involve trade-offs: reducing acceptable downtime or potential data loss generally adds cost and operational complexity.
Two measures help teams set requirements. The recovery point objective (RPO) sets the maximum acceptable period of lost data, based on how recently it was backed up or synchronized. The recovery time objective (RTO) sets how long a service can remain unavailable. Newman says RTO must account not only for restoring data but also for securing computing resources and redirecting traffic to an alternative site.
The wider report also covers backup-and-restore, pilot-light, warm-failover and active-active recovery patterns. For AI-powered software, it highlights provider resilience, model changes and observability, alongside strategies such as using multiple models or vendors, tracking costs and reviewing vendors regularly. The source notes that ongoing GPU and CPU shortages can constrain infrastructure availability, making it important to prioritize critical services.
Recovery Targets Shape Outage Planning
These practices matter because a recovery plan is only useful if it matches the service’s tolerance for downtime and data loss. Teams that set explicit RPO and RTO targets can compare recovery designs against operational needs, rather than treating backup or failover as a one-size-fits-all solution. The appropriate design depends on the consequences of an interruption and the resources available to restore service.
AI adds dependencies that can change outside a team’s direct control. If a service relies on an external model provider, changes to model availability or behavior may affect the application even when its own infrastructure is operating. Observability and provider planning can help teams detect and manage those dependencies. Multi-model or multi-vendor approaches may offer options, but they also bring costs and integration work; the excerpt presents them as tactics for handling uncertainty, not guarantees against failure.
As an affiliate, we earn on qualifying purchases.
From Site Failover to Model Risk
The material comes from two chapters of Newman’s book, published by O’Reilly Media and reproduced with permission, according to The Pragmatic Engineer. The publication says Newman spent three years writing the book rather than the two he initially planned, reworking material to account for AI. It presents the excerpt as a selection rather than a complete account of the book’s 16 chapters.
For disaster recovery, Newman uses “site” as a general term for the location of computing infrastructure, whether that means a public-cloud region, private cloud or conventional data center. The recovery patterns span different levels of readiness and resource use. The report also places AI reliability within the broader question of vendor and infrastructure dependence, including access to computing capacity.
“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
Limits of the Published Excerpt
The source does not provide new outage statistics or evidence quantifying whether AI-generated code has increased incident rates. It says the report’s author has observed more outages and attributes much of this to more deployments and bugs, but that is not accompanied here by data or an independent assessment. It should be read as the author’s characterization, not an established industry-wide finding.
The excerpt also does not prescribe a single recovery design or give a specific RPO or RTO that applies to all systems. Actual targets, costs, vendor arrangements and recovery capabilities depend on each organization’s services and infrastructure. The report’s discussion of AI model and provider resilience does not establish how frequently providers change models or how much risk any one mitigation reduces.
Teams Must Set Their Own Targets
The next step for engineering teams is to define how much data loss and downtime their services can tolerate, then assess recovery options against those limits. That includes testing whether backups can be restored, whether alternate capacity can be obtained and whether traffic can be redirected within the stated RTO. Plans also need to account for constrained compute resources and the services that should receive priority.
For AI-dependent systems, teams can map model and vendor dependencies, monitor service behavior and costs, and review alternatives as providers or requirements change. The source does not announce a specific industry response or follow-up milestone; it presents these measures as planning guidance in Newman’s book.
Key Questions
What is the actual news?
The Pragmatic Engineer published excerpts from Sam Newman’s 2026 book on disaster recovery and resilient AI-powered software. The material is guidance, not breaking news about an outage.
What do RPO and RTO mean?
RPO is the maximum acceptable period of data loss, measured by the time since data was last backed up or synchronized. RTO is the acceptable time a service can remain unavailable after an incident.
Which recovery approaches does the excerpt discuss?
It covers backup-and-restore, pilot-light failover, warm failover and multisite active-active. The excerpt frames these as options with different costs, complexity and recovery capabilities.
How does AI affect resilience planning?
The report points to model-provider dependence, model changes and observability as issues for AI-powered services. It also discusses multi-model or multi-vendor strategies, cost transparency and regular vendor reviews as ways to manage uncertainty.
Does the report prove AI-written code is causing more outages?
No quantified evidence is provided in the supplied report. Its author says outages and production bugs are increasing and links much of that to more deployments involving AI-written code, but the excerpt does not present data establishing that claim.
Source: rss
Columbus Day / Indigenous Peoples' Day Picks
long weekend sales
As an affiliate, we earn on qualifying purchases.
