Architecture is not just monolith versus microservices. There are other service-based styles, and many systems that claim to use microservices are actually something else.

SOA, microservices, and service-based architecture differ in where business logic lives, how data is owned, and how much coordination they require.

Microservices also evolved partly as a reaction to SOA, which often became too centralized and heavyweight.

This chapter covers how these styles differ and how to identify which one a system is actually using.

Service-Oriented Architecture was the dominant enterprise answer to "how do we build large systems out of services" through the 2000s. Its instincts were not wrong.

SOA wanted reusable services organized around business functions, integrated so that the whole enterprise could share capabilities instead of rebuilding them in every application. The problem was in how it tried to get there.

Three choices defined classic SOA, and all three pulled toward centralization. The first was centralized governance: a central architecture group defined standards, approved services, and controlled how they evolved.

The second was a shared canonical data model, a single enterprise-wide definition of what a "Customer" or an "Order" was, that every service had to conform to. The third, and the most consequential, was the Enterprise Service Bus.

The ESB was meant to be the integration layer that connected everything.

Services would talk to the bus, and the bus would handle routing, protocol translation, and message transformation between them. On paper this decouples services from each other, since none of them needs to know about the others directly. In practice it created the problem the next section is about.

The trouble with the Enterprise Service Bus was not that it routed messages. It was that, over time, it accumulated business logic.

Because the bus sat in the middle of every interaction, it became the convenient place to put orchestration ("when an order arrives, call inventory, then billing, then shipping") and transformation ("Service A speaks this format, Service B speaks that one, the bus translates").

Each addition seemed reasonable on its own. The cumulative result was that the smarts of the system migrated out of the services and into the pipe.

That migration is what makes the ESB a trap rather than just a tool. Once meaningful logic lives in the bus, the bus becomes a single point of failure: if it goes down, nothing can talk to anything. It becomes a performance bottleneck, since every interaction routes through one component.

And it becomes an organizational bottleneck, because changing how two services interact now means changing shared infrastructure that a central team owns and that every other integration also depends on. The thing that was supposed to decouple services ended up coupling all of them to a single shared component.

This is the specific failure mode microservices were designed to avoid, and it explains a phrase you will hear repeated: "smart endpoints, dumb pipes." It is a direct rejection of the smart-pipe, dumb-endpoint shape of ESB-centric SOA.

Microservices share SOA's basic ambition (build systems from independently useful services) but invert nearly every structural decision SOA made. The differences are easiest to see side by side.

The throughline of the right column is pushing intelligence and ownership outward to the edges. Microservices put business logic in the services and keep the communication layer deliberately thin, so no shared component becomes the place everything depends on.

They reject the shared canonical model in favor of each service owning its own data and its own definition of its concepts, which is why an "Order" can mean different things in different services without an enterprise committee reconciling them.

And they trade SOAP and the WS-* standards stack for lightweight protocols like HTTP and gRPC, which are easier to build, debug, and evolve.

None of this makes SOA's goals wrong. Reuse, integration, and consistency are real needs. Microservices bet that you get more of them, more cheaply, by decentralizing than by centralizing. For most modern web-scale systems that bet has paid off. As the last section of this chapter notes, it does not pay off everywhere.

Between a monolith and full microservices sits a less discussed option: service-based architecture, sometimes called "macro-services." It takes the part of microservices that is genuinely valuable (breaking a large application into separately deployable services around coarse domains) and deliberately skips the part that is genuinely expensive (giving each service its own database).

A service-based system typically has a handful of larger services (often four to a dozen) that deploy independently but share a database. That shared database is exactly what microservices forbid, and skipping it on purpose is the whole point.

By keeping one database, you keep ACID transactions across the whole domain, you avoid sagas and the outbox pattern and eventual consistency, and you sidestep the cross-service query problem entirely. You still get independent deployability for the application tier, which relieves a lot of the coordination pain, without taking on the hardest cost of distribution.

This style exists because the distributed-data problem is the part of microservices that is easiest to underestimate and most expensive to undo.

Service-based architecture is the considered answer for teams that want service boundaries and independent deploys but have a tightly related dataset that does not split cleanly, or do not yet have the operational maturity to run many databases well.

It accepts coupling at the data layer as a deliberate trade for simplicity everywhere else. The cost is real and worth naming: the shared database is a coupling point, schema changes still require coordination, and one service's bad query can hurt the others. But for many systems that is a smaller price than the full distributed-data bill.

There is one more variant worth a mention, because it sits at the opposite corner from service-based architecture. A self-contained service goes the other way on coupling: it bundles its user interface, its logic, and its data into a single deployable, specifically so that handling a request does not require calling out to other services.

The goal is autonomy taken to its conclusion. A self-contained service can serve its slice of the product end to end without depending on anyone being up, which maximizes availability and minimizes the network hops that the earlier chapters warned about.

Step back and these styles line up on a single axis, from least distributed to most. Seeing them as points on a spectrum, rather than rival camps, is what keeps the choice from feeling binary.

Each step to the right trades simplicity for autonomy. The monolith is one deployable with no internal boundaries. The modular monolith adds clean internal boundaries but still ships as one unit. Service-based architecture separates the deployables but shares the data. Microservices separate the data too.

And nano-services push granularity so far that the overhead of each service starts to dominate the work it does, which is the point where the spectrum stops being useful and becomes an anti-pattern.

The right answer for a given system is rarely the far end in either direction. It is the leftmost point that solves your actual coordination and scaling problems, because every step right is a cost you keep paying.

Given how this chapter has framed SOA, it would be easy to read it as purely a cautionary tale. That would be a mistake. SOA solved a problem that has not disappeared: integrating a large, heterogeneous set of systems across an enterprise, many of which you do not control and cannot rewrite.

In a big organization with decades of accumulated systems, mainframes, vendor packages, acquired companies' platforms, and regulatory systems that nobody is allowed to touch, the central integration layer and the canonical data model start to look less like bottlenecks and more like necessities.

When dozens of systems each have their own idea of what a "Customer" is and you cannot change any of them, a place that does the translation and a shared definition to translate toward is genuinely useful.

Organizations that already invested heavily in an ESB and canonical models, and whose problem is integration rather than rapid product iteration, are not obviously wrong to keep them.

The summary is that SOA and microservices optimize for different problems. SOA optimizes for enterprise integration and central governance across systems you do not own. Microservices optimize for independent delivery and scaling within systems you do own.

Recognizing which problem is actually in front of you, integration of the unchangeable versus fast evolution of the changeable, is more useful than declaring one style obsolete. Service-based architecture is the middle ground, and SOA remains the valid answer to a different question.

The map of service architectures has more than two points on it, and the differences between them come down to a few consistent bets.

SOA centralized logic in an Enterprise Service Bus, shared canonical data models, and governed services top-down, which is powerful for enterprise integration but turns the bus into a single point of failure and a bottleneck when business logic accumulates there.

Microservices inverted those bets: smart endpoints and dumb pipes, decentralized data, decentralized governance, and lightweight protocols, optimizing for independent delivery and scaling.

Between monolith and microservices sit the pragmatic options. The modular monolith keeps one deployable with clean boundaries. Service-based architecture separates the deployables but shares the database, deliberately trading data coupling for the chance to keep ACID transactions and skip the hardest part of distribution. Self-contained services go the other way, bundling UI, logic, and data to maximize autonomy.

Laid out as a spectrum from monolith to nano-services, each step right buys autonomy and pays in operational cost, and the right choice is usually the leftmost point that solves your real problem rather than the most distributed one available.

That choice, it turns out, is not made on technical grounds alone. The shape of the architecture you can successfully run is tied to the shape of the organization running it. The next chapter takes up that link directly, through Conway's Law and the team topologies that decide which of these architectures a given company can actually sustain.