Decision Record · ADR-001

Modular monolith as the starting point, microservices on evidence

New systems start as a modular monolith with explicit module boundaries. Individual services are extracted only when a concrete requirement justifies it.

What is this? · Decision Record

A documented architecture decision in ADR format — context, options considered, rationale and consequences. One concrete decision, not a general guide. Go to overview

Status
Accepted
Identifier
ADR-001
Review
To be revisited as soon as a module demonstrably requires independent scaling or independent deployment.

Context

New systems have to choose between a single deployment (monolith) and distributed services (microservices). The choice shapes operations, changeability and costs for years.

Problem

Distributed systems solve real problems — independent scaling, independent deployment — but they bring network boundaries, eventual consistency and operational overhead with them. When do the benefits justify these costs?

Options

What we considered.

  1. A

    Modular monolith

    One deployment, clear module boundaries in a single codebase.

  2. B

    Microservices from the start

    Multiple services, independently deployable and scalable.

  3. C

    Distributed monolith

    Multiple services without real decoupling — the worst option.

Decision

What we decided.

New systems start as a modular monolith with explicit module boundaries. Individual services are extracted only when a concrete requirement justifies it.

Why this decision

The modular monolith keeps the expensive decisions open. Boundaries are explicit, but crossing them doesn't cost a network hop, and operations stay simple. Clean modules can be distributed selectively later — going the other way is considerably more expensive.

Consequences

  • The service scales as a whole; individual parts can't be scaled independently.
  • Module discipline has to be actively maintained, or the system risks becoming a big ball of mud.
  • Extracting a module later is a deliberate decision in its own right.

Rejected alternatives

  • Microservices as the defaultPays the costs of distributed systems before the benefits are established.
  • Serverless-firstLocks in an operating model and a provider early, before load profiles are known.
Knowledge graph

Continue your engineering journey.

Related concepts, decisions, playbooks and perspectives — as one connected path, not a list of links.

Facing a similar decision?

We don't make it on gut feeling. Talk to our management — technical, no sales pitch.