Choosing your model: decision grid, warning signs and migration trajectories

The first three chapters described the models; this one answers the practical question: which one to choose, and how to change your mind without breaking everything? Because that is the reality of systems: you do not choose once and for all, you choose for a context, and the context changes.

By the end of this chapter, you will be able to weigh the five criteria that dominate the decision, recognize the warning signs of the wrong choice, and walk through the two proven migration trajectories towards the federated model.

The five criteria that dominate the decision

Dozens of factors influence the choice, but five crush all the others:

1. The distribution strategy. Will you sell (or open) the services separately? This is the most discriminating criterion: if you must ship piece by piece, the integrated monolith is eliminated outright, whatever its other qualities.
2. The number of teams. Conway’s law is non-negotiable: one or two teams live very well in a monolith; ten teams on a shared core paralyze each other.
3. The integration requirement. If the unified view is the product (cross-cutting dashboards, smooth navigation between domains), you need either the monolith or a federated control plane; pure autonomous services will make you pay for every integrated screen.
4. The consistency requirement. Immediate guaranteed consistency: monolith. Acceptable eventual consistency: federated. Sufficient best-effort conventions: autonomous.
5. The existing system. A healthy working monolith is an asset, not a shame; already scattered services call for federation, not a central rewrite.

Test the grid on your own case

Answer the five questions for your system (real or imaginary) and watch the tendency. Your mission: find a combination of answers that eliminates the monolith from the first question, then one that makes the federated model unavoidable.

The warning signs of the wrong choice

Failed architectures give warnings. Here are the symptoms to recognize, each pointing to a precise diagnosis:

Lockstep deployments. Your services are “independent” but every release requires deploying them together, in a precise order, after a coordination meeting. Diagnosis: distributed monolith, almost always caused by a shared kernel or implicit contracts. You pay for distribution without autonomy; either re-assume the monolith, or break the shared core.

The swelling integration backlog. Every quarter, new requests for “consolidated view”, “cross-cutting report”, “global deletion”, and every request is a project. Diagnosis: autonomous services facing an underestimated integration need. The durable answer is not the nth aggregation screen, it is a federated control plane.

Orphaned resources and inconsistent tags. Nobody can say how many “shops” really exist, audits find resources without owners. Diagnosis: federation by convention (tags) without contract. What is missing: contractual external references and reconciliation.

The core-team bottleneck. All the other teams wait for the central module’s evolutions; the core’s backlog is six months deep. Diagnosis: monolith beyond its organizational scale. That is the starting signal for an extraction.

Trajectory 1: from the monolith to the federated model

The most frequent migration, and the best documented. It follows the strangler fig pattern: the new system grows around the old one, which keeps working until it becomes replaceable.

The steps, in order:

1. Modularize first. Draw the logical boundaries inside the monolith (chapter 1: the modular monolith). No new infrastructure; all the work is in the code and internal interfaces.
2. Extract the most autonomous module, the one with the fewest incoming dependencies. Give it its own local projection of the shared concept, fed at first by calls to the monolith.
3. Introduce the federation contract on the extracted service: external reference, idempotent upsert. The monolith becomes its first de facto control plane.
4. Repeat module by module, always starting with the most decoupled.
5. Promote the remaining core to control plane: when only the topology remains at the center (organizations, shops, users), the monolith has become, without any brutal switch, the central referential of the federated model.

The beauty of this trajectory: each step has value even if the migration stops there. A modular monolith is better than spaghetti; an extracted service gives a team back its autonomy; the federation contract also serves infrastructure tools.

Trajectory 2: from autonomous services to the federated model

The reverse path, typical of ecosystems that grew best-of-breed and whose customers demand the unified experience.

1. Publish the common language: the minimal vocabulary and the identifier scheme (chapter 3). It is a governance decision, not code.
2. Add the federation contract to each service: external_ref and managed_by fields, idempotent upsert. Each service stays 100% autonomous; it simply becomes federable.
3. Build the control plane, first read-only (consolidated inventory), then read-write (provisioning).
4. Adopt the existing: the adoption procedure of chapter 2 pairs the historical entities with the referential, service by service, without data migration.

Check your understanding

Quiz

1. 1. Which criterion eliminates the integrated monolith outright, whatever its other qualities?

   • More than three development teams
   • The need to sell or open the services separately
   • A high availability requirement
   • A limited infrastructure budget
   Submit

2. 2. What do systematically coordinated deployments between "independent" services diagnose?

   • Insufficient CI/CD infrastructure
   • A distributed monolith: services technically separated but logically welded
   • A lack of automated tests
   • A team that is too small
   Submit

3. 3. Why is the strangler fig trajectory preferred over the big bang?

   • It executes faster
   • Each step produces value on its own, and the system keeps working throughout the migration
   • It requires no modification of the monolith
   • It avoids having to train the teams
   Submit

4. 4. Why is the "transitional" shared kernel a migration trap?

   • Because it is too costly to develop
   • Because the temporary that works becomes permanent: you build a distributed monolith while believing you are migrating
   • Because it prevents unit testing
   • Because it forces using the same programming language
   Submit

Key takeaways, from the whole course

• Chapter 1: the integrated monolith and autonomous services optimize opposite goals (integration and consistency versus autonomy and scale); the choice shapes the product AND the organization.
• Chapter 2: the federated model reconciles both: a control plane sovereign over the topology, services sovereign over their resources, convergence through idempotent reconciliation.
• Chapter 3: bounded contexts legitimize local definitions; between them circulate identifiers and messages of a published language, never shared types.
• Chapter 4: you choose with five criteria (distribution, teams, integration, consistency, existing system), you watch for the warning signs, and you migrate through steps that each carry their own value: never big bang, never via a “transitional” shared kernel.
• The durable skill is not knowing the “best” model: it is knowing how to read a product’s strategy in its architecture, and vice versa.