Page
1
Building Distributed Systems in the Age of AI Designing Intelligent, Resilient Architectures — Max Hopei
Page
2
Building Distributed Systems in the Age of AI Designing Intelligent, Resilient Architectures Max Hopei
Page
3
Building Distributed Systems in the Age of AI: Designing Intelligent, Resilient Architectures ISBN-13 (pbk): 979-8-8688-2393-0 ISBN-13 (electronic): 979-8-8688-2394-7 https://doi.org/10.1007/979-8-8688-2394-7 Copyright © 2026 by Max Hopei This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Aditee Mirashi Editorial Assistant: Gryffin Winkler Cover designed by eStudioCalamar Cover image designed by Derek Thomson on unsplash.com Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a Delaware LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail booktranslations@springernature.com; for reprint, paperback, or audio rights, please e-mail bookpermissions@springernature.com. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub. For more detailed information, please visit https://www.apress. com/gp/services/source-code. If disposing of this product, please recycle the paper Max Hopei Munich, Bayern, Germany
Page
4
I dedicate this book to my beloved wife, Olivia.
Page
5
(This page has no text content)
Page
6
(This page has no text content)
Page
7
(This page has no text content)
Page
8
(This page has no text content)
Page
9
(This page has no text content)
Page
10
(This page has no text content)
Page
11
(This page has no text content)
Page
12
(This page has no text content)
Page
13
xiii About the Author Max Hopei is a software engineer, architect, and engineering leader with over 15 years of experience building distributed systems at scale. Throughout his career, he has navigated the complexity of modern software architecture, from high-throughput messaging platforms to resilient microservices and AI- integrated systems. His work spans startups and enterprise environments, where he has led cross-functional teams, established engineering best practices, and guided organizations through complex technical transformations. Max has deep expertise in software architecture, cloud infrastructure, and developer experience and brings a pragmatic, use-case-oriented mindset to everything he builds. He believes great engineering isn't just about technology—it's about designing systems that are understandable, evolvable, and aligned with the human context in which they operate. As a Principal Engineer at Regiondo, he led the re- platforming of one of Europe's largest B2B booking systems, migrating it from a monolithic architecture to a microservice architecture. He learned to be pragmatic and to focus on market needs and systems adaptability. In the Celonis Labs team, part of the Strategy & Innovation department, he investigates emerging technologies, identifies trends, and drives the design and development of new business models to shape the future of process intelligence.
Page
14
xv About the Technical Reviewer Shruti Tyagi is a senior technology and operations leader with over 15 years of experience in AI, cloud computing, distributed systems, enterprise software, and operational excellence. She currently serves in a senior leadership role at ServiceNow, leading high- impact initiatives across large-scale enterprise environments with a focus on software reliability, risk mitigation, and AI-enabled transformation. Her work combines deep practical experience in complex systems with a strong interest in applying emerging technologies to scalable, real-world business solutions.
Page
15
xvii Acknowledgments First, I would like to thank my wife for her support and patience. Writing a book while working full-time means many evenings spent poring over words, sentences, and diagrams. Countless times she had to remind me it was not all pointless. She gave me the strength to keep going when so many chapters were still ahead. I’m extremely grateful to my technical reviewer, Shruti Tyagi, for her excellent comments and recommendations. Whenever I was too vague, she demanded structure. Whenever I was too excited and absolute, she reminded me that the world is diverse. Her professional opinion framing is something I took with me as an extra learning. I’m equally grateful to my colleagues for our lively discussions over lunch and in the office about all matters covered in this book. I deeply appreciate them sharing their opinions and challenging my beliefs, which provided fertile soil for improving and sharpening my knowledge. Finally, I’d like to thank all the participants in my “Munich, 8 o’clock” coffee meetups, which I organized to gain more industry insights into the book's topics. These people, coming to talk about nerdy subjects before the day starts, hungry for knowledge and full of enthusiasm, gave me a lot of inspiration to continue my work.
Page
16
xix Introduction It’s been more than 50 years since software engineering emerged as a discipline after the Software Engineering Conference held in 1968 in Garmisch, a small, picturesque town in Bavaria, Germany, just about an hour and a half’s drive from where I live now. The phrase “software engineering” was deliberately chosen to be provocative, implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering.1 It is fascinating to see the resemblance between the emerging computer hardware and software industry in the late 1960s and the current AI field, experiencing a big boom after the latest development of large language models. The report from the Garmisch Conference opens by noting the tremendous growth rate of software—viewed at the time more with alarm than with pride. The concerns of the day were related to the high expectancy of errors in ever-growing systems with an ever-growing demand due to the lack of proven techniques in their proper development and an ad hoc approach in doing so. “We undoubtedly produce software by backward techniques,” said Malcolm Douglas McIlroy, an American mathematician, engineer, and programmer, at the venue, comparing software crafting to the hardware industry. Five decades after the conference, the software engineering field was green and blooming on a cozy, wide plateau. A well-established set of 1 Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 October 1968.
Page
17
xx techniques, architectural and design patterns, and best practices ruled the everyday work of an engineer. Big Tech companies set the bar for designing distributed systems; developers from businesses of all kinds and sizes had plenty of examples showing how to build a required system. Many developments contributed to the evolution of the software as we know it today. Perhaps the biggest, or at least the most transformational one, after the Internet appeared in the early 1970s, was the rise of cloud services. This only further emphasized the inherently distributed nature of software systems, which had, in truth, always been so. Amid all this tranquility, the appearance of large language models on the software engineers’ radars felt like an earthquake, shattering the sense of settledness. The waves only grew stronger as generative AI competitors caught up. Improvements were arriving daily from all directions: text, code, image, video, music, and speech generation were advancing rapidly. To many engineers, including myself, these changes brought excitement: Look how many things are now feasible that we could only have dreamed of before. But the joy was quickly followed by anxiety: How on earth am I supposed to keep up with the pace of this development? I don’t have a machine learning degree—am I good for nothing now? Will it finally take over my job? Or the whole world? A wish for progress coexists with a wish for it to plateau, at least for a little while, so we can figure out what to do next. Today, I’m astonished to see coding agents recover from an error in an API response and retry the corrected request, all within a long pipeline, following pagination, and without a single instruction in the prompt to do so. By the time this book is out, that may sound laughably ordinary, which only proves my next point. The software engineering world is shaking, and most have already understood: new mountains will arise. Be skeptical, and you’ll be buried in dust. Be pragmatic, and you’ll see new horizons. It’s time to revisit what’s valuable in this new age. We must focus on the approaches, technologies, and practices that will lift us up—those InTroduCTIon
Page
18
xxi that matter in an accelerating, ever-changing world. We need to reshape ourselves to be even more flexible and productive. We have to start thinking anew. It would be comforting to treat AI as just one more tool, another box on the architecture diagram. It is that, but it is also much more. AI changes what we build, because systems can now reason, act, and decide rather than merely store and serve data. It changes how we work, because code is increasingly written, read, and reviewed by machines. And it changes the world our systems are born into: the internet is filling with autonomous agents, users expect software to understand them and act on their behalf, and the pressure on privacy and trust keeps rising. A system designed today enters a different environment than one designed five years ago. This book follows all three of these shifts at once. I’m writing for software engineers with a broad understanding of this term who already have distributed systems under their belts and now want to make sense of how AI reshapes the way we design, build, and run them. You don’t need a machine learning degree. Curiosity and hands-on experience are enough. This book has three parts, one for each of these shifts. Part 1 focuses on technology—on what we build. It explores how system architecture must evolve to meet the demands of the AI age. It aims to equip engineers with the concepts and technologies likely to shape the next decade of systems design. The journey starts with Chapter 1, which argues that AI and other shifts have changed what matters in system design and makes the case for building with microservices and serverless from the start. Chapter 2 revisits microservices themselves, proposing the three-dimensional service model and a domain-centric design that puts business use cases at the center. Chapter 3 turns to message-driven architecture, the asynchronous communication that lets services stay responsive and integrate across the enterprise. Chapter 4 moves to continuous flows with streaming architecture, the source of the fresh data that AI and InTroduCTIon
Page
19
xxii machine learning depend on. Chapter 5 examines agentic architecture in depth: how large language model-based agents reason and act, how they remember and retrieve, how they are secured, and how they collaborate. Chapter 6 ties these patterns together in a single real-world system, a vehicle-sharing platform where microservices, streaming, and agents work as one. Chapter 7 asks how we observe such systems when their behavior no longer lives in the code and shows how observability merges with regulatory explainability. Chapter 8 closes the part with a map of how deeply AI can participate in a system, across three levels: AI as a tool, AI using tools, and AI creating tools. Part 2 focuses on engineers and on how we work. As AI systems evolve, so must the people who build them. This part explores how the role of the software engineer is being reshaped by fundamental shifts in how we write code, build teams, and organize development processes. Code is no longer written for people but increasingly for large language models that read, interpret, and generate it. The teams building distributed systems must adapt. New skills— spanning infrastructure, AI literacy, and secure system integration—are becoming foundational. Agile practices, once revolutionary, are now losing traction and are deemed overstructured unless refitted for the age of autonomy and asynchronous tooling. This part proposes a new model for teams: multidisciplinary, dynamic, and driven by an understanding of both human and machine collaboration. Chapter 9 looks at using AI to build systems, how coding agents change the daily practice of engineering, and how that acceleration ripples into review, testing, education, and hiring. Chapter 10 explores what happens to our conventions when code is written and read by machines: which rules we can relax and which matter more than ever. Chapter 11 pushes the question further and asks what a programming language designed for AI might look like, all the way to the idea of natural language as source code. Chapter 12 turns to the team, examining how roles, processes, and agile practices adapt when agents join the work. InTroduCTIon
Page
20
xxiii Part 3 focuses on the ecosystem—on the world our systems live in. The Internet was built for people. But that’s changing. This final part examines another shift: software systems are increasingly designed not for human eyes and hands, but for autonomous agents. This change rewires the assumptions that have guided internet architecture for decades. At the same time, human expectations are also evolving. Users will demand that AI assistants understand them deeply, act on their behalf seamlessly, and operate across systems with minimal friction. Yet behind the convenience lies rising complexity and increasing scrutiny. From privacy regulations to infrastructure stress, engineers must prepare for a world where both machines and people are powerful, demanding users of software. Chapter 13 is about making your system more approachable to this new kind of caller, with agent-friendly APIs, MCP servers, and events offered as public contracts. Chapter 14 confronts the growing pressure on privacy and trust and the architectural disciplines that keep data safe as it flows through AI systems. Chapter 15 closes the book by looking at how user expectations are shifting toward delegated, almost invisible interaction, what that means for identity across trust boundaries, and why the problems left for professional engineers are only getting harder. InTroduCTIon