Deployment Styles

Monolith, modulith, microservices, event-driven, SOA, space-based. Comparing tradeoffs.

How the system is delivered and scaled in production. These are not code patterns, but architectural styles that affect the team, deployment, operational cost, and, above all, how long it takes for a change to reach production.

#The Problem

Choosing the wrong deployment style is expensive to reverse. A monolith that grows without boundaries becomes impossible to scale surgically: you either scale everything, or you scale nothing. But breaking it into thirty microservices without operational maturity gives you the worst of both worlds: the complexity of a distributed system and the couplings of the monolith you left behind.

#The Solution

There is no "correct" style; there is a style that is appropriate for your team, domain, and operational budget. Knowing the options—monolith, modulith, microservices, event-driven, space-based, SOA—and understanding their real tradeoffs allows you to choose rationally, not by fashion. Most projects are better off with a good modulith than with bad microservices.

#The Real Question

It's not "monolith or microservices?". It's:

  • How many independent teams will touch this system?
  • What parts need to scale differently?
  • Does your team have the operational maturity to run 30 services?
  • How much does an hour of downtime cost you?

The answers matter; trends do not.

#In this chapter

  • Monolith — a single deployment, as relevant as ever.
  • Modulith — monolith with explicit internal boundaries (the right choice 80% of the time).
  • Microservices — autonomy per service, complexity per system.
  • Distributed Microservices vs Distributed Monolith — the difference almost nobody teaches.
  • SOA — the grandparent of microservices.
  • Event-driven — asynchronous communication as the backbone.
  • Space-based — horizontal scaling without a database as a bottleneck.
  • Microkernel / Pipeline / P2P — less popular styles but useful in their niche.

#How to read this chapter

Each page describes strengths, weaknesses, operational cost, and signs you chose wrong. There is also a side-by-side comparison page to facilitate the decision.

Spoiler: for most projects, a good modulith beats a bad set of microservices.

  • Microservices — A set of small, autonomous, independently deployable services, communicating over a network.
  • Monolith — The entire application in a single deployable process.
  • Event-Driven Architecture — Decoupled components communicate by publishing and reacting to events, rather than calling each other directly.
  • Microservices — Multiple autonomous services, each with its own deployment and database.
  • Modulith (Modular Monolith) — A single deployment, but internal modules with strict boundaries and explicit communication.
  • SOA — Reusable services within an enterprise, typically sharing a service bus (ESB).
  • Comparison: Monolith vs Microservices vs Modulith — Comparative table of the three main architectural styles.
  • Space-Based Architecture — Replicates data and processing in an in-memory grid to scale elastically and eliminate the database bottleneck.
  • Microkernel (Plugin) — Minimal core offering base services, extended by plugins.
  • Pipes & Filters (architectural) — Processing in stages connected by pipes — system-level version of the Pipeline pattern.
  • Peer-to-Peer — Each node acts as both client and server; there is no central server.