TL;DR
Get business pricing on tech for your team
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
The Pragmatic Engineer published a podcast episode featuring software architect Sam Newman on building resilient distributed systems and choosing when microservices are appropriate. The discussion also covers failure handling, observability, idempotency and how AI tools may affect developers’ understanding of software.
The Pragmatic Engineer has published a podcast episode with software architect and author Sam Newman about building resilient distributed systems, including why he considers microservices an architecture of “last resort.” The conversation also addresses failure handling, observability and the effects of AI on how software teams design and maintain systems.
Newman, author of Building Microservices and the forthcoming Building Resilient Distributed Systems, discusses what teams can get wrong when adopting a service-based architecture. The episode emphasizes independent deployment: Newman’s clearer definition of a microservice is a service that can be changed and deployed without requiring other services to be deployed at the same time. He also offers a softer definition based on services having boundaries around business functions rather than technical layers.
For distributed systems, Newman reduces common failure causes to three constraints: information takes time to travel, a system or resource may be unavailable, and computing resources are finite. He says that, in his experience, many outages stem from the third problem: pools of resources such as CPU, memory, storage or network capacity running out. The episode also covers observability and the need to weigh business consequences when deciding whether a system should fail open or fail closed.
Other topics include idempotency, which helps prevent repeated requests from causing repeated effects, such as charging a payment twice. The source outlines two approaches: clients can send idempotency keys for servers to track, or servers can generate fingerprints from request details. The latter may be easier to add to an existing system, but the source notes that it can wrongly treat legitimate requests as duplicates. The discussion also considers AI-assisted development, specifications versus code as a source of truth, and the risks Newman calls “cognitive debt” and “cognitive surrender.”
Resilience Starts With System Limits
The discussion connects architectural choices to operational risks teams face in production. Independent deployment can give teams more autonomy, but dividing an application into services also means managing communication across systems that can be slow, unavailable or constrained by finite resources. Newman’s account points teams toward those failure conditions rather than treating service boundaries as a guarantee of resilience.
The advice also has practical implications for decisions made during incidents. Whether to fail open or fail closed depends on what a failure means for the business and its users; there is no single choice identified as right for every system. Likewise, observability can help teams detect and understand problems, while idempotency can reduce the consequences of retries in operations such as payments. These are subjects from a podcast conversation, not a report of new research or a measured comparison of architectures.
Newman’s comments on AI add a concern about maintaining human understanding as tools contribute more software. The episode presents modular architecture as one way teams might experiment while keeping systems understandable. It does not provide benchmark results or evidence that one AI workflow will work for every organization.
distributed system monitoring tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Newman’s Long View of Microservices
Newman’s perspective draws on years of work with software teams. The source says he was present when the term “microservices” was coined at an architecture symposium in England in the early 2010s. It recounts that James Lewis proposed “micro apps” for a pattern of services that could be replaced quickly, before someone else in the room suggested “microservices.” Lewis and Martin Fowler published an article defining the term in March 2014; Newman’s Building Microservices followed the next year.
That history helps explain why Newman distinguishes a service’s deployment independence from the looser idea of organizing software around business domains. He has also described microservices as a last resort, rather than a default starting point. The episode revisits that caution alongside his newer work on distributed-system resilience. The source identifies Building Resilient Distributed Systems as a new book but provides no publication date or further release details.
“Microservices are an architecture of “last resort.””
— Sam Newman, as quoted in The Pragmatic Engineer episode material
As an affiliate, we earn on qualifying purchases.
Publication Details and Advice Limits
The supplied source does not state when the episode was published, provide its full transcript, or give the release date for Newman’s new book. It also does not include a complete account of the episode’s discussion of idempotency: the material ends partway through its description of request fingerprints. The exact treatment of their trade-offs beyond the stated risk of rejecting legitimate requests as duplicates is therefore unclear.
The episode summarizes Newman’s professional experience and recommendations. It does not establish that his three rules cover every cause of system failure, quantify how often resource exhaustion causes outages, or compare the results of microservices with other architectures. Claims and advice in the conversation should be understood as Newman’s views, not as independently verified findings presented in the source.
idempotency request management software
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Listen for the Full Discussion
The source directs readers to listen to or watch the episode on YouTube, Apple and Spotify, and says a transcript appears at the top of the episode page, with timestamps at the bottom. Those materials are the next place to check for the full discussion, including the details omitted from the supplied excerpt. No follow-up announcement, release date for Newman’s book, or further episode-related milestone is specified.
observability tools for microservices
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Key Questions
What is the news?
The Pragmatic Engineer published a podcast episode featuring Sam Newman on resilient distributed systems, microservices and software development involving AI tools.
Why does Newman call microservices an architecture of last resort?
The source reports that Newman cautions against adopting microservices by default. He discusses their potential to support independent deployment and team autonomy, while the episode also addresses the mistakes teams can make when using them. It does not provide a single rule for when every team should adopt them.
What are Newman’s three rules for distributed systems?
Information takes time to travel; a resource may be unavailable; and resources such as CPU, memory, storage and bandwidth are finite. Newman says he has often seen resource exhaustion behind outages.
How can idempotency prevent duplicate payments?
Idempotency makes repeated operations have the same effect as performing them once. A payment system can use idempotency keys or server-generated request fingerprints to identify retries and avoid processing the same payment multiple times.
Where can readers find the episode?
The source lists YouTube, Apple and Spotify as listening or viewing options. It also points to a transcript and episode timestamps on The Pragmatic Engineer page.
Source: rss
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
