Integrated monolith and autonomous services: two opposite answers to concept sharing
Customer, shop, project, organization: when several services of the same product handle the same concepts, two architectures dominate the market, and they optimize incompatible goals.
Imagine an online commerce software suite: a catalog service, a payment service, a shipping service, a customer support service. Very quickly, something becomes obvious: all these services talk about the same things. A “shop”. A “customer”. An “order”. The user, however, sees only one: their shop, which has products, transactions, parcels and support tickets.
This problem is in no way specific to commerce. An office suite shares the “document” and the “workspace” between editing, sharing and messaging. An ERP shares the “customer” and the “order” between sales, accounting and logistics. A development platform shares the “project” and the “environment” between code management, deployment and feature flags. A banking information system shares the “account” and the “holder” across dozens of applications. Everywhere, the same question shapes the architecture: who owns the concepts everybody handles?
The answer commits everything: the ability to ship services separately, the smoothness of the integrated experience, the cost of evolving the system, and even the organization of teams. By the end of this chapter, you will be able to recognize the two canonical models that dominate the market, explain their strengths and weaknesses, manipulate their trade-offs on concrete scenarios, and understand why neither is enough when you want both autonomous building blocks and an integrated experience.
The problem of cross-cutting concepts
Let us state the problem precisely, because it is more subtle than it looks.
The payment service needs to attach its transactions to something: call it a shop. The catalog service organizes its products by shop too. The shipping service attaches its parcels to orders, themselves placed in a shop. These concepts look extremely similar. Same name, same intuition, same position in the hierarchy: the organization owns shops, the shop contains resources.
The temptation is immediate: “it is the same concept, let us model it once”. That is exactly the temptation we need to examine, because the two big architecture families on the market answer it in opposite ways. And neither answer is a mistake: they are two coherent optimizations of different goals.
Model 1: the integrated monolith
The first model is the one used by integrated software suites: ERPs, all-in-one development forges, management suites. The shared concept is a single central entity, stored once, on which every feature depends: the catalog hangs off the shop, the transactions hang off the shop, the shipments hang off the shop, the tickets hang off the shop.
The benefits are real and immediate:
- Perfect integration. A “shop” page shows products, sales, parcels and tickets without inter-service calls, without synchronization, without any possible inconsistency. Navigation is smooth because everything is already joined.
- One model to learn. For the user as for the developer, there is only one definition of “shop”, with a single lifecycle.
- Trivial transactions. Creating a shop and its default catalog in the same database transaction: no distributed protocol to invent.
- Consistency guaranteed by construction. A transaction cannot reference a nonexistent shop: the integrity constraint lives in the schema.
The cost is just as real, but deferred:
- Impossible to ship one building block separately. The payment service cannot exist without the core that defines the shop. You cannot offer it as a standalone product, nor replace it with a better market component, nor open it to independent adoption.
- Evolution coupling. Any change to the central entity potentially impacts every feature. The “shop” schema becomes the bottleneck of every team.
- Limited organizational scale. Ten teams working on the same core step on each other.
The disciplined variant: the modular monolith
Before moving to the opposite model, let us mention an important variant: the modular monolith. Same single deliverable, same database, but strict logical boundaries between modules: the payment module accesses the shop module only through an explicit internal interface, never by joining its tables directly.
It is an excellent starting choice: it keeps the monolith’s benefits (transactions, integration, operational simplicity) while preparing the boundaries that will allow, one day, extracting a module into a service. Most successful migrations to distributed models start from a modular monolith, not from a spaghetti one. Remember this idea: logical boundaries precede physical boundaries; we will come back to it in chapter 4.
Model 2: autonomous services
The second model is the one used by the large public cloud providers and best-of-breed ecosystems. Here, each service owns its own resources and knows nothing about the others. The storage service has its buckets, the compute service has its instances, the database service has its clusters. There is no global entity shared across services.
How does the user find their way? Through three a posteriori federation mechanisms:
- Normalized identifiers. Every resource has a unique name structured by a global convention (a URI or hierarchical naming scheme). Any tool can designate any resource of any service without ambiguity.
- Labels (tags). Free key-value pairs attached to resources. The decentralized equivalent of grouping: you put
shop=my-shopon your resources in each service, and a grouping tool finds them. - An aggregation console. A presentation layer above the services, which queries each one and rebuilds a unified view. Integration is not in the data model: it is recomputed at display time.
The benefits mirror the monolith’s costs:
- Each service lives its own life. It is designed, deployed, versioned and sold separately. One team per service, independent release cycles.
- Local evolution. Changing a service’s internal model impacts nobody, as long as identifiers stay stable.
- Replaceability. The customer can compose their system with the best service of each category, and switch.
- Proven organizational scale. This is the model that allowed catalogs of hundreds of services to grow for twenty years.
And the costs mirror the monolith’s benefits:
- The integrated experience is a permanent construction site. Every cross-cutting view (billing per shop, deleting a whole shop, access rights per shop) must be built explicitly on top of the services, and maintained.
- Consistency is soft. Nothing guarantees that a
shop=my-shoplabel is set everywhere, or spelled the same. Orphaned resources and incomplete groupings are everyday life. - The shared concept exists nowhere. The “shop” is only a convention. No service can rely on it contractually.
Manipulate the trade-offs
The theory is laid out; now put it to the test. For each scenario below, compare what happens in each of the two models. Your mission: find the scenario where the monolith clearly wins, then the one where it definitively loses.
Integrated monolith
A single central Shop entity, every feature depends on it.
The central schema impacts every feature: each change to Shop must be approved by every team, then deployed as one block.
Autonomous services
Each service owns its resources, no shared entity at all.
Each service evolves its internal model freely, as long as its identifiers stay stable.
The fundamental incompatibility
Put the two models side by side and the dilemma appears:
| Integrated monolith | Autonomous services | |
|---|---|---|
| Shared concept | Single, central, contractual entity | Nonexistent (tag convention) |
| Ship one block alone | Impossible | Natural |
| Integrated experience | Native | Rebuilt, costly |
| Cross-cutting consistency | Guaranteed by the schema | Soft, best effort |
| Evolving one service | Coupled to the core | Free |
| Organizational scale | One core team as bottleneck | One team per service |
If your strategy requires both: autonomous building blocks, adoptable and replaceable one by one, and an integrated experience where the shared concept really exists, then neither canonical model is enough. You need a third one, borrowing from both without inheriting their disqualifying flaws. That is the federated model, the subject of the next chapter.
Check your understanding
1. In the integrated monolith, why is it impossible to ship one building block separately?
2. What distinguishes the modular monolith from the classic monolith?
3. In the autonomous services model, how does the user group resources from different services?
4. What does Conway’s law predict for a system whose core is shared between ten teams?
Key takeaways
- Cross-cutting concepts (customer, shop, order, project) are the structuring question of any multi-service system: who owns them?
- The integrated monolith centralizes: perfect integration and consistency, but no building block can live alone and the core becomes the bottleneck of evolutions and teams.
- The modular monolith is the disciplined variant: same benefits, logical boundaries ready for a future extraction.
- Autonomous services decentralize: each service is free, shippable and replaceable alone, but the integrated experience must be rebuilt and cross-cutting consistency stays soft.
- The two models optimize opposite goals; when the strategy demands both at once, a third model is needed: federation, in the next chapter.