Architectural Styles II: Distributed Systems

Welcome to Chapter 6: Architectural Styles, part two, Distributed Systems. Chapter 5 described styles in which the whole system is deployed as one unit. This chapter takes the same questions across a network. It explains when distributing a system is worth its cost, the main distributed styles, and the mechanisms they all depend on. And it is precise about failure, delivery guarantees and consistency.

Almost every system of any size is now distributed in some way. A mobile app talks to back-end services, which call payment providers, mapping services and message brokers, and the services themselves run on many machines. Splitting a system can bring independent scaling, fault isolation, independent releases and autonomous teams. It also brings problems that cannot occur inside one process: messages lost or duplicated, services that are slow rather than dead, data that disagrees between copies, and failures in machines you did not know you depended on.

The chapter is rated intermediate to advanced. It is written for developers and architects who are designing or reviewing systems made of many services. It builds on Chapter 5's styles and Chapter 2's qualities, now under network conditions. In particular, it uses availability in series and parallel, coupling and Conway's law, and the architecture quantum, the modular monolith and bounded contexts. And it leads into Chapter 7, which deals with the hardest part of distribution: the data.

The single most important idea in the chapter is that distribution is a trade, not an upgrade. Each benefit is bought with latency, consistency, observability and operational effort. A good architect can say which benefit is being bought, at what price, and why a cheaper option inside a monolith will not do.

The chapter moves from why to how. Section six point one sets out the reasons to distribute, the eight fallacies of distributed computing, and partial failure, and gives you the arithmetic to price the trade before you commit to it. Section six point two covers service-based architecture, a pragmatic middle ground of a few coarse domain services, and the classic service-oriented architecture, including why it fell out of favour. Section six point three covers microservices: services aligned to bounded contexts, independent deployment, a database per service, how to decide how big a service should be, and the distributed monolith. Section six point four covers event-driven architecture: events and commands, brokers and mediators, delivery guarantees, and consumers that can safely receive the same message twice.

Here is the arithmetic from Section six point one. Placing an order passes through five services: the API gateway, then order, menu, pricing and payment. Each waits for the next to answer, and each on its own is available ninety-nine point nine per cent of the time. But availabilities multiply. Together they give a request path of only about ninety-nine and a half per cent: about three point six hours of downtime a month. And latencies add. With twenty milliseconds of work in each service, plus a little for each network hop, the median is about a hundred and ten milliseconds. Five individually respectable services have produced a much weaker request path. That is the price of distribution, worked out on paper before you build anything.

This diagram shows partial failure, the defining problem. An order service asks a payment service to authorise twenty four pounds fifty, and waits for the reply. Three different things can go wrong. The request is lost, and no charge was made. The payment service crashes or stalls, and nobody knows. Or the reply is lost, and the card was charged. To the caller, all three look identical: no reply before the timeout. So any operation that may be retried must be idempotent, which means that doing it twice has the same effect as doing it once.

The second half turns to the mechanisms every distributed style depends on. Section six point five compares synchronous and asynchronous communication and the coupling each creates, and covers API design, versioning and contract testing. Section six point six is about what readers of copied data can expect: consistency models, what the CAP theorem really says, and PACELC. Section six point seven explains why two-phase commit is avoided between services, and how sagas, compensating transactions and the outbox pattern keep business processes correct without it. Section six point eight closes with two styles for particular load profiles: serverless functions, which scale to zero, and space-based architecture, which keeps data in memory to survive extreme spikes, such as tickets going on sale.

Three habits run through every section. First, count synchronous dependencies, not services. The number of things that must all be working at the same moment for a request to succeed decides its availability and latency. Second, assume messages are lost, delayed, duplicated and reordered, and design receivers so that a repeated message does no harm. Third, decide who owns each piece of data, because ownership decides where transactions are possible, and where consistency must be managed across services. Chapter 7 develops that habit into a full treatment of data architecture.

If you are new to the topic, read each section's opening summary and the boxes headed If you are new to this first. Experienced engineers will find the precision where it matters. The chapter takes about three and a half hours to read. Two examples recur. The food-delivery platform shows ordinary distributed design. A ticketing system for a stadium tour shows what changes when tens of thousands of people want the same few seats at the same second. Each section ends with a few self-check questions. Answer them in your head before you look. When you are ready, take the optional chapter test: twenty multiple-choice questions and two written answers, in about forty five minutes. The pass mark is eighty per cent.

That is the map of Chapter 6. Start with Section six point one, where we weigh the reasons to distribute against the fallacies that make it harder than it looks. See you there.