Why: the goal or problem

Stable business capabilities need different release schedules or owners. One shared release can force unrelated teams to coordinate every change.

How: work toward a solution

  1. Fictional reading app: one team; Catalog, Library and Billing each v1. A17 has no tag.
  2. Deploy only Library v2 with a compatible tag feature; Catalog and Billing stay v1.
  3. Library queries Catalog over the network, then writes travel to its own store. A lookup timeout before writing leaves no tag; report failure and retry after recovery.
Independent releases introduce remote failure cases

Illustrative example

One capability can release alone

Reading app · one team · A17 has no tag

Change: add a Library tag; Billing behavior stays unchanged.

Compatible contract: only Library needs a new release.

  1. Deployment unit · 1

    Catalog

    v1 → v1

    Behavior unchanged

    Owned storeCatalog

  2. Deployment unit · 2

    Library

    v1 → v2

    Tag feature added

    Owned storeLibrary

  3. Deployment unit · 3

    Billing

    v1 → v1

    Behavior unchanged

    Owned storeBilling

Network lookup · before the tag write

Library → Catalog API

A remote return is not guaranteed. Billing is outside this lookup path.

  1. 1 · Success

    Lookup succeeds → write travel → A17 has tag travel.

  2. 2 · Catalog lookup timeout

    Lookup fails before writing → no tag. Report failure; retry after recovery.

Each service owns its data; no direct reads of another service's tables. Independent releases still need monitoring and failure handling; downstream failures can propagate.

Ownership boxes describe access rules, not database-machine counts.

What: the concept

Microservices are independently deployable capability services with explicit contracts and owned data. Separate processes alone do not ensure independence. Lewis and Fowler

Network failures and cross-service data require coordination. Remaining capabilities can stay a modular monolith.