Microservices divide a system into services that can be changed and deployed independently. Each service owns a business capability and the data behind it. The useful boundary is deployment independence: separate processes alone do not make a microservice architecture.

This style starts paying for itself when teams block one another’s releases or parts of the system need sharply different scaling and availability. It also moves work out of the compiler and into production. Network latency, partial failure, asynchronous consistency, and a larger operational surface become everyday design constraints.

Core Principles

Boundaries follow business capabilities. Orders, Inventory, Billing, and Shipping are plausible boundaries because each contains its own rules and language.
Data has one owner. A service controls its schema and persistence model. Other services use its contract instead of reading its tables. Separate database servers are optional. Exclusive ownership is not.
Integration happens through contracts. Versioned APIs and events carry data across boundaries. Shared libraries stay small enough that one team’s release cannot force another’s.
Deployment is independent. A service can ship, roll back, and scale without coordinating a full-system release.
Governance stays thin. Platform standards cover cross-cutting concerns while teams retain control of domain choices.

flowchart LR
    Client[Client App] --> APIGW[API Gateway]
    APIGW --> Orders[Orders Service]
    APIGW --> Payments[Payments Service]

    Orders --> OrdersDb[(Orders DB)]
    Inventory[Inventory Service] --> InventoryDb[(Inventory DB)]
    Payments --> PaymentsDb[(Payments DB)]
    Shipping[Shipping Service] --> ShippingDb[(Shipping DB)]

    Orders -- REST or gRPC --> Inventory
    Orders -- OrderCreated --> Broker[(Event Broker)]
    Broker -- OrderCreated --> Inventory
    Broker -- PaymentCaptured --> Shipping

Communication Patterns

A synchronous call fits a decision that must complete before the caller can continue. REST and gRPC both serve that case. Keep the path short. A chain such as A -> B -> C -> D adds every dependency’s latency and gives each failure another route back to the client.

Message Queues and Software Architecture/System Architecture/Event-Driven Architecture fit work that can continue later. An immutable OrderPlaced event can start reservation or notification work after the request has returned. Consumers still need idempotency because a broker may redeliver a message after an uncertain acknowledgement.

The boundary is the business decision. Use a direct call when an immediate answer is part of that decision. Publish a fact when independent work can happen afterward.

Implementation and Operations

An independently deployable service can run in a container, virtual machine, managed application platform, or function service. Docker and Kubernetes are delivery choices, not defining properties of microservices.

Each service needs a small operating contract:

an owner and escalation path.
supported API or event versions, plus the build artifact and rollback procedure.
service-level indicators with alert thresholds.
correlation across logs, metrics, traces, synchronous calls, and messages.
request deadlines, bounded retries, circuit breaking, and load shedding.
audited configuration and secret delivery.
datastore ownership, migration order, backup, and restore evidence.

A platform should make these basics cheap without forcing one topology onto every service. A low-volume internal API can run on App Service. A partitioned consumer fleet may justify Kubernetes, while a scheduled job can remain a managed container task.

Kubernetes supplies declarative rollout, service discovery, probes, and resource controls. It cannot supply correct service boundaries or safe database migrations. Resource requests should come from measurements. Disruption budgets come from the required availability. Readiness should report whether this instance can serve traffic. If every pod fails readiness during a shared database outage, the cluster removes all routes even though another pod cannot improve the result.

Microservices vs. Monolith vs. Modular Monolith

Dimension	Monolith	Software Architecture/System Architecture/Modular Monolith	Microservices
Deployments	Single unit	Single unit with strict module boundaries	Independent service deployments
Team model	Shared ownership	Team ownership by module	Team ownership by service
Data model	Shared database	Shared database with modular access rules	Database per service
Runtime calls	In-process	In-process	Network calls
Operational complexity	Low	Low to medium	High
Best fit	Small team, early product	Growing product, clear domains, limited ops capacity	Large org, high release velocity, independent scaling needs

Software Architecture/System Architecture/Monolith Architecture is usually the safest starting point while domain boundaries are still moving. It keeps refactoring local and failure modes visible. Distribution can wait until a real constraint appears.

Migration Boundary

A migration should remove a measured constraint. Moving the same coupling across a network only makes it harder to see. A good first candidate has clear ownership, isolatable data, and release or scaling pressure that already costs the organization. The most central workflow is usually a poor first extraction because it hides the most dependencies and makes rollback hardest.

Staged Extraction

Measure the pressure. Record deployment wait time, change collisions, uneven load, and incidents caused by the candidate boundary.
Create an in-process seam. Put the capability behind a contract inside the monolith and block direct table or internal-code access.
Assign data ownership. Move writes behind that contract. Replace cross-boundary joins with explicit queries, replicated read models, or events.
Introduce the remote implementation. Route a controlled cohort through HTTP, gRPC, or messaging while keeping the old path available.
Prove independent operation. Deploy and roll back the service alone, exercise dependency failure, and verify traces and alerts.
Retire the old path. Remove duplicate code and tables only after traffic, reconciliation, and rollback windows show the new owner is stable.

This is a strangler migration. The replacement grows around a working system, one boundary at a time.

Extraction Gate

Billing is ready to leave Orders when it owns payment-intent state behind a versioned contract, Orders has stopped touching Billing tables, and either side can release alone. Its outage policy must be explicit: Orders rejects, queues, or degrades. Trace and causation identifiers connect the request to later messages, and reconciliation catches orders whose payment state does not converge. Until those conditions hold, the boundary belongs in-process.

Data Migration

Prefer one writer during transition:

Backfill the new store from a consistent snapshot.
Capture later changes through an outbox or change-data-capture stream.
Compare counts and business invariants between stores.
Route reads to the new owner for a small cohort.
Switch writes only when lag is zero and rollback can replay the retained change stream.
Stop the old writer, then remove its tables after the recovery window.

Uncontrolled dual writes create two sources of truth. If a transition cannot avoid them, name the authoritative store and build reconciliation before the first production write.

Migration Evidence

Claim	Evidence before extraction	Evidence after extraction
Faster delivery	Candidate changes wait on shared pipeline	Service releases without monolith release
Independent scaling	Candidate saturates while rest is idle	Service scales without multiplying whole app
Better isolation	Candidate incidents affect whole deploy	Failure drill contains impact at contract boundary
Clear ownership	Multiple teams modify same internals	One team owns contract, data, SLO, and pager

Stop when the next candidate lacks a measurable constraint. One monolith beside a few services can be a stable architecture. The visuals below show Airbnb’s historical migration rather than a universal sequence.