Skip to content

ADR-0011: Do Not Create 1,500 Microservices

  • Status: accepted
  • Deciders: ConnectSoft Architecture Team
  • Date: 2026-06-10

Context and Problem Statement

The ecosystem catalog lists ~1,500 candidate items. A naive reading would create ~1,500 microservices. That would be operationally and financially unsustainable and would contradict our modularization and clean architecture & DDD principles.

How many independently deployed services should the ecosystem actually have, and how do we decide?

Decision Drivers

  • Operational cost and complexity scale with the number of deployables.
  • DDD favors a small number of well-bounded contexts, not many tiny services.
  • Most catalog items are capabilities within a context, not independent products.

Considered Options

Option 1: One microservice per catalog item

  • ~1,500 deployables. Unsustainable. Rejected.

Option 2: One monolith

  • Contradicts cloud-native and independent-scaling goals. Rejected.

Option 3: Bounded-context services with modules; microservices only when justified (Selected)

Decision

The default delivery shape is module-in-service: most items are modules inside a small number of bounded-context services. An item becomes a standalone microservice or platform only when it satisfies most of the microservice justification rule:

  1. Independent lifecycle, 2. Clear bounded context, 3. Distinct scalability, 4. Distinct data ownership, 5. Distinct security/compliance boundary, 6. External API/product boundary, 7. Independent team ownership.

We therefore expect on the order of a few dozen independently deployed services and platforms across the ecosystem - not 1,500. The rule is documented in the service classification model and proposals use the microservice candidate template.

Rationale

  • Keeps the runtime topology intentional and affordable.
  • Aligns with DDD bounded contexts and clean architecture.
  • Lets verticals compose rather than re-implement (see ADR-0013).

Consequences

Positive

  • Sustainable operations; less duplication; clearer ownership.

Negative

  • Requires architecture review for any standalone-service proposal.
  • Some teams may push for premature service splits; the rule guards against this.