The Runtime Theory
Architecture Styles

Choosing an Architecture Style From Constraints

An architecture style shapes how components communicate, deploy, and fail.

The Runtime Theory Team5 min read#architecture#monolith#services
▸ On this page

The model

An architecture style shapes how components communicate, deploy, and fail. A modular monolith can preserve one deployment unit while enforcing code-level boundaries. Services add independent deployment and scaling but also require network contracts, operations, and failure handling.

A concrete walk-through

A small team with one release cadence may benefit from a monolith whose internal modules have explicit interfaces. A high-volume subsystem with a distinct scaling profile may justify extraction once measurement shows deployment or resource isolation is valuable. The decision should account for team ownership as well as runtime behavior.

Costs and failure cases

Microservices turn local calls into remote interactions with timeouts, partial failure, data ownership, and observability requirements. A monolith can still have poor boundaries, and splitting it does not repair them automatically. Architecture should follow constraints that exist, not scale imagined for later.

Check your understanding

Your team proposes extracting search into a service. List the evidence that would justify the operational cost and the data ownership boundary the new service would need.

Further reading

Martin Fowler: Microservices

Not started

Sign in to save your learning progress.

Sign in to save