Table of contents
Explore the 15 chapters of Building Distributed Systems in the Age of AI: Designing Intelligent, Resilient Architectures. Chapter titles, page ranges, and abstracts are from Springer Nature.
- The Modern Technology — Chapters 1–8
- The New Engineer — Chapters 9–12
- The New Audience — Chapters 13–15
Front matter (PDF), pages i–xxiii, includes the introduction.
The Modern Technology
1. Setting the Focus on the Right Things
Pages 3–12
Some things from hundreds of thousands of pages written about software architecture and design are more important today than ever before. Architecture is an investment. Today’s demand on the system can almost always be satisfied simpler and cheaper; it’s tomorrow that we think of when drawing lines between boxes: introducing queues to handle the back pressure, adding the load balancers to scale a service, and batching writes to cope with the load.
2. Revising Microservice Architecture
Pages 13–49
When it comes to designing microservices, two opposing schools of thought dominate the landscape: domain-driven and process-driven approaches.
3. Message-Driven Architecture
Pages 51–80
Distributed systems rely on effective communication between their components. Unlike reliable in-process communication methods like function calls, channels, and queues, which are built into programming languages, communication between services is a form of inter-process communication (IPC) that crosses network boundaries. This requires careful consideration of various factors.
4. Streaming Architecture
Pages 81–99
Traditional web services are focused on delivering functions to the users. Services, as computer programs, are digital equivalents of services in economics, defined loosely as an act or use for which a consumer, company, or government is willing to pay. Based on this, they are formed around use cases. Services are intangible; they must be consumed within a limited time and can’t be stored for future use.
5. Agentic Architecture
Pages 101–154
This chapter should rather be called “Modern Agentic Architecture,” for Agents as a distinct type of software systems appeared long before the recent generative AI hype. As you will see, modern lower-level architectures of LLM-based agentic systems are not different in this aspect and only use tools and technologies appropriate to their technical nature to deliver successfully.
6. Real-World System Example
Pages 155–170
The previous chapters explored three architectural patterns—microservices for clear domain boundaries, streaming for real-time intelligence, and agentic systems for autonomous decision-making. Each pattern addresses specific challenges in building distributed systems. But modern applications rarely need just one. They need structure with clear boundaries, temporal awareness, and intelligence based on human-designed logic and machine-learned optimization.
7. Observability in Unpredictable Systems
Pages 171–190
In a traditional system, you would open the logs, follow the traces, find the bug in the code, and fix it. The path from symptom to root cause is well-trodden. In an agentic system, the code did exactly what it was supposed to: it called the LLM with the given prompt and tools. The decision that went wrong was made during the model’s reasoning. This chapter examines what observability means when behavior is no longer written in code.
8. Systems Powered by AI
Pages 191–206
The preceding chapters explored specific architectural patterns for building distributed systems: microservices, message-driven communication, streaming data processing, and agentic architecture. Chapter 6 combined them in a real-world system, and Chapter 7 examined the observability challenges that agentic systems introduce. This chapter steps back from specific technologies and patterns to ask a broader question: at what depth does AI participate in our systems, and what does each depth mean for the engineers who build them?
The New Engineer
9. Using AI to Build Systems
Pages 209–237
If you’re writing code by hand, you might be seriously falling behind.
10. From Code for People to Code for AI
Pages 239–253
For decades, software engineering has been mainly governed by a simple yet not obvious idea: Programs must be written for people to read and only incidentally for machines to execute.
11. Programming Language for AI
Pages 255–277
The previous chapter ended on a question, and that question is the seed of this one. If we know that code in our repositories is being read, written, and continuously edited by language models, why are we still using languages designed for human cognition?
12. A Full-Stack Team for Distributed Systems
Pages 279–299
Previous chapters looked at what changed for the individual engineer: how we use AI to build systems, how code is now written for a different reader, and how programming languages themselves might evolve. This chapter looks at the team. The people sitting next to you, the processes that tie you together, the agents that recently joined the party, and the communication that keeps all of it coherent.
The New Audience
13. Making Systems Approachable
Pages 303–329
This chapter is all about AI agents. For as they are spawning and occupying the internet. According to a report by the cybersecurity vendor Imperva, automated, machine-generated traffic already surpassed human-generated traffic in 2024, with bots accounting for 51% of all web traffic.
14. Growing Privacy Pressure
Pages 331–346
The previous chapter was about opening your system up: new doors for agents, new surfaces for integrations, and new ways to reach users through channels you don’t own. Every one of those doors is also a path along which data travels. Once a caller is let in, a new question follows them: What happens to their data now? Who sees it, where does it travel, how long is it retained, and what is it used for? This chapter is about that question and about the pressure building around it from several directions at once.
15. Changing and Increasing Expectations
Pages 347–364
The last two chapters looked at your system as something you build and protect: how to make it approachable to agents, integrations, and new kinds of callers, and how to hold the line on privacy once data starts flowing through it. This final chapter flips the perspective. It asks: What do users actually expect from the systems now? And where is that expectation heading?
Back matter
Back matter (PDF), pages 365–373.