Which One When? Comparing Architectures and Criteria of Choice

Objectives

By the end of the lesson, you can compare the styles discussed so far along the seven aspects, state the decision questions of the choice, and justify why there is no single best architecture.

Why a separate lesson?

The individual styles can be learned on their own, but the practical question is always: which one, when? The answer lies not in a ranking of the styles, but in how well they fit the requirements, the team and the operational capability.

The comparison

The table shows typical consequences, not absolute rules. A badly operated monolith is not necessarily cheap, and two simple services are not necessarily more complicated than one giant application.

Aspect	Monolith	Modulith	Service-based	Microservices	Serverless
Coupling	Held by discipline	Checked module interface	Service contract, often shared data	Service contract, own data	Via events and services
Deployability	One unit	One unit	Few units	Many independent units	Per function
Scaling	As a whole	As a whole	Per service (coarse)	Per service (fine)	By the platform, automatic
Data management	Shared	Shared, with module owners	Often shared	Per service	In an external store
Consistency	Local transaction	Local transaction	Local transaction possible	Mostly eventual consistency	Depends on the external store
Failure handling	One process	One process	A few network calls	Many network calls, partial failure	Platform + network calls
Team and operations cost	Low	Low	Medium	High	Low operations, provider dependence

Decision questions

1. How much do the parts change together? If usually together, the shared unit (monolith/modulith) is simpler.
2. Is separate release or separate scaling needed? It is worth drawing a network boundary only if the boundary gives real independence.
3. Is a shared transaction needed? If yes, and it cannot be relaxed, shared data is important.
4. How many teams work, how big is the organisation? By Conway, the structure follows the organisation (1.2).
5. Are there automation, observability and operational capability? Fowler names automated release, monitoring and failure handling as part of the microservices premium.
6. How certain are the boundaries? With uncertain boundaries the monolith/modulith allows cheaper mistakes.

flowchart TD
  A{"Do the parts change<br/>together?"} -->|"Yes"| B["Monolith or modulith"]
  A -->|"No"| C{"Is there operational<br/>and automation capability?"}
  C -->|"No"| D["Modulith or<br/>service-based"]
  C -->|"Yes"| E{"Separate scaling, separate life cycle,<br/>several teams?"}
  E -->|"Yes"| F["Microservices<br/>(or serverless)"]
  E -->|"No"| D

The diagram is an illustrative decision aid, not an algorithm: for a real decision, the requirements must be weighed and the result documented (1.5).

Several styles at once

Styles can be mixed. A system can have a modular core with a few separate services next to it (for example a heavily loaded processor), or serverless functions in the background. The measure is always the cost and benefit of the concrete boundary, not "purity".

Space-based architecture in brief

The space-based style was designed for extreme scaling and concurrency problems. According to the typical descriptions, the system consists of processing units and virtualised middleware, the bottleneck of the central database is replaced by replicated in-memory data grids, and processing units can be started and stopped according to the load. The name "space" comes from the tuple space model, in which components cooperate through entries stored in a shared space, not through a message broker. Because it is meant for a special, rare need, the course does not discuss it in detail; it is mentioned here to show that extreme scaling needs have a style of their own, and that replacing the central database comes with serious consistency and complexity costs.

Common misconceptions

Statement	Clarification
"There is always one best architecture."	Every style is a trade-off; the requirements decide.
"The more advanced style is always the more expensive, therefore better."	Cost is not a quality measure; cost can also be superfluous.
"The choice is final."	Systems evolve; the decision can be reviewed (1.5, 3.7).
"Only one style can exist in a system."	Styles can be mixed.

In short

• Styles are compared along the same seven aspects.
• The decision questions: co-change, need for separate release/scaling, transactions, organisational size, operational capability, uncertainty of boundaries.
• Styles can be combined.
• Space-based is a special style for extreme scaling needs.

Review questions

1. When would you choose the modulith over service-based, and when the reverse?
2. How does the choice change if the team is small and there is no operational automation?
3. What does it mean that the style is not the goal?

Learning resources

• Architecture styles (Azure Architecture Center) — styles as constraints; the criteria and challenges of choice.
• Microservice Premium (Martin Fowler) — when microservices are worth it.
• Space-based architecture (Wikipedia) — an overview of the style of tuple space origin.