Microservices from Zero: Architectures, Trade-offs, and Migration

115 min read

Published August 30, 2026

A senior-engineer reference from architecture foundations through Domain-Driven Design (DDD) service boundaries, transactional consistency patterns, migration playbooks, design anti-patterns, and a full worked design for money-moving commerce.

Microservices are an architectural style for structuring a system as independently deployable services that own their data and collaborate over the network. They are a rational response to specific scaling, team, and release constraints—not a default for every product. This guide teaches the vocabulary, decision rules, and failure modes you need before you split a complex transactional application (orders, payments, stock, ledger).

1. Software architecture

Software architecture is the set of structural decisions that are expensive to reverse: the major components (or services), their responsibilities, their interfaces, where state is stored, how failures propagate, and how the system is built, deployed, and operated over time. Architecture is not the choice of framework, language, or cloud vendor—those are implementation details that should be replaceable within the architectural constraints.

Why it matters: every team already has an architecture, even if nobody drew it. Accidental architecture concentrates coupling in the wrong places: shared mutable tables, undocumented call chains, and “temporary” modules that become permanent choke points.

1.1 Qualities you actually trade

Architecture is a continuous trade among competing qualities. Name them explicitly so debates stop being about fashion.

• Deployability — How independently and safely can you ship a change? Definition: the ability to release a unit of software without forcing unrelated units through the same pipeline. Why it matters: release cadence is often the real bottleneck once the product works. Example: extracting Notifications so marketing copy ships without touching Payments. Failure if ignored: every change waits for the slowest, riskiest module. Decision rule: if release coordination cost dominates feature cost for a boundary, that boundary is a candidate for independent deployability.
• Evolvability — How cheaply can you change behavior inside a boundary without rewriting neighbors? Related to modularity and stable contracts. Example: replacing the fraud rules engine behind a Payments interface. Failure: leaking domain models across APIs so every consumer must change when the model changes.
• Availability — The fraction of time a capability serves correct responses within an SLO (Service Level Objective). In distributed systems this interacts with partial failure: one dependency down must not take the whole product down unless you deliberately couple them. Example: Catalog browse remains up while Fulfillment is degraded. Decision rule: draw failure domains on the same diagram as service boxes.
• Consistency — Whether readers see the same facts after writes, and whether multi-step business invariants hold. Strong consistency inside one database transaction is easy; across services you usually accept eventual consistency (replicas and readers converge after a delay) and design sagas. CAP trade-offs (see below) force explicit choices under partition.
• Operability — How well you can observe, diagnose, roll back, capacity-plan, and secure the running system. Microservices multiply operability surface area: more processes, more queues, more credentials, more dashboards.

CAP (Consistency, Availability, Partition tolerance — as a decision lens, not a slogan): Brewer’s CAP conjecture (and the PACELC elaboration: if Partitioned then Availability vs Consistency; Else Latency vs Consistency) says that under a network partition, a replicated data system cannot simultaneously guarantee linearizable consistency and full availability. Even without partitions, you trade latency vs consistency (PACELC’s “else”). For checkout money paths, prefer consistency of the ledger and payment capture; for product search rankings, prefer availability and accept stale reads. Decision rule: classify each read/write path as C-preferring or A-preferring under failure, and design the UI/support process accordingly.

  Deployability  <----->  Coordination cost
  Evolvability   <----->  Contract stability / coupling
  Availability   <----->  Blast radius of failure
  Consistency    <----->  Latency / partition tolerance
  Operability    <----->  Number of independently failing parts

2. Architecture styles in depth

An architecture style is a named family of structural constraints (how you package deployable units, share data, and communicate). Real systems mix styles; naming the dominant style still helps you choose deliberately and spot anti-patterns.

2.1 Monolith

Definition: A monolith is one primary deployable application that contains most business capabilities in a single process (or a tightly versioned set of processes shipped as one unit), typically against one primary transactional database.

Why it matters: ACID (Atomicity, Consistency, Isolation, Durability) transactions across catalog, cart, order, and payment tables are straightforward; local method calls are cheap and typed; debugging is one stack trace.

        [ Clients ]
             |
        [ Web / API ]
             |
   +---------+---------+
   |   Commerce Monolith|
   | catalog cart order |
   | pay ship notify    |
   +---------+---------+
             |
      [ One primary database (DB) ]

2.2 Modular monolith

Definition: A modular monolith is still one deployable unit, but the codebase is partitioned into modules with enforced dependency rules: modules expose public APIs; other modules must not reach into private persistence or domain types. In practice this is Ports and Adapters inside one process: modules depend on ports, not on each other’s ORM tables.

Why it matters: You keep single-process transactions and cheap calls while practicing the same boundary discipline microservices require. Extraction later becomes swapping an in-process adapter for a remote one—not archaeology.

   +---------------- Commerce deployable ----------------+
   |  [Catalog] --> [Cart] --> [Orders] --> [Payments]   |
   |       ^            |           |            |       |
   |       |            v           v            v       |
   |   module DBs logically separated (schemas/tables)   |
   +-----------------------------------------------------+
                         one process / one release train

2.3 SOA versus microservices (historical differences)

Service-oriented architecture (SOA) emerged in the 2000s as an enterprise approach: coarse-grained services, often shared via an enterprise service bus (ESB), with heavyweight standards (SOAP — Simple Object Access Protocol; WS-* web-service standards), centralized governance, and shared canonical data models. Services were frequently large, multi-capability applications; integration logic often lived in the bus.

Microservices (popularized in the 2010s) emphasize: smaller services aligned to business capabilities, decentralized data management (database-per-service), smart endpoints / dumb pipes (prefer thin messaging or HTTP over a logic-heavy ESB), independent deployability, and product-aligned teams. Governance is distributed; contracts are versioned APIs and events, not a single enterprise schema.

2.4 Microservices definition

Definition: A microservice architecture structures an application as a suite of services that (1) are independently deployable, (2) are organized around business capabilities, (3) own their persistent state, and (4) communicate via network protocols with explicit contracts (APIs and/or events).

“Micro” is relative to the capability boundary—not a line-count target. A Payments service that owns capture, refund, and provider adapters may be large in code and still be one correct microservice.

  Clients --> [ API Gateway / BFF ]
                 |        |        |
            [Orders]  [Payments] [Inventory]
               | DB      | DB       | DB   (each = Database)
                 \        |        /
                  \       v       /
                   [ Message broker ]
                          |
                   [Notifications] ...

2.5 Distributed monolith and nanoservice anti-patterns

Distributed monolith: many network-separated processes that must be released, tested, and reasoned about as one unit—because of shared databases, synchronous call webs, shared libraries that require synchronized versions, or ambient temporal coupling.

Nanoservices: services split below a useful business capability (e.g., separate deployables for CreateUser, UpdateUser, DeleteUser). Chatty RPC, distributed transactions, and operational noise dominate.

2.6 Serverless as runtime, not architecture

Serverless (functions-as-a-service, managed containers that scale to zero) is a hosting and scaling model. You can implement a monolith, modular modules, or microservices on serverless runtimes. Serverless does not choose your bounded contexts, data ownership, or consistency model.

3. Comparison tables

  Autonomy / independent scale
        ^
        |                          * microservices (if mature)
        |                    *
        |              * SOA
        |        * modular monolith
        |  * monolith
        +-------------------------------------------> ops & consistency cost

4. When each style is the rational choice

4.1 Choose a monolith when

• Domain boundaries are still unstable (you are still learning the ubiquitous language).
• One or few teams deliver the product; Conway alignment does not require many deployables.
• Business invariants routinely span what would become multiple services (money + stock + order status in one user action) and you lack saga/ops maturity.
• Time-to-learning and simplicity dominate scale-out needs.

4.2 Choose a modular monolith when

• You need clear ownership and testability but not yet independent deploy or heterogeneous scale.
• You plan a future extraction and want seams (ports, schemas, module APIs) ready.
• You want ACID within the process while forbidding cross-module table reach-through.

4.3 Choose microservices when

• Independent deployability is a measured bottleneck (release queue, blast radius, or regulatory isolation).
• Scale profiles differ sharply (search vs checkout vs batch settlement).
• Team topology already has (or will fund) capability-aligned teams with on-call ownership.
• You can afford the operational tax: platform for deploy, observe, secure, and message reliably.
• Bounded contexts are known enough that network boundaries will not thrash monthly.

5. Microservices pillars and Domain-Driven Design (DDD) essentials for boundaries

5.1 Pillars

1. Business capability alignment — Services reflect what the business does (fulfill an order, capture a payment), not technical layers (UserRepositoryService).
2. Independent deployability — A service ships on its own cadence with backward-compatible contracts.
3. Data ownership — Only the owning service writes its store; others use APIs/events/read models.
4. Automation and observability — CI/CD (Continuous Integration / Continuous Delivery), health, metrics, traces, and correlation are prerequisites, not optional polish.

5.2 Domain-Driven Design essentials

Ubiquitous language — The shared vocabulary of domain experts and developers inside one model. Definition: terms like “reservation,” “capture,” “settlement,” and “refund” mean one thing in that context. Why it matters: ambiguous language produces wrong service cuts (Order vs Payment “status” wars). Example: Inventory’s “reserved” is not Payments’ “authorized.” Failure if ignored: APIs that reuse the same word for different invariants. Decision rule: write a glossary per bounded context; forbid overloaded terms across contexts without translation.

Bounded context — A boundary within which a particular domain model is valid and consistent. Definition: Catalog’s Product (marketing attributes, SEO) differs from Inventory’s StockItem (SKU, on-hand, reserved). Why it matters: forcing one enterprise Product entity across teams creates coupling. Example: Catalog publishes ProductPublished; Inventory consumes SKU identity only. Failure: one shared Product table edited by five teams. Decision rule: split services primarily along bounded contexts, not along database tables of an old ER diagram.

Aggregate — A cluster of domain objects treated as a consistency boundary with a root that enforces invariants. Definition: all changes that must be atomic together go through the aggregate root and are persisted in one transaction in that service’s database. Why it matters: aggregates define the maximum size of strong consistency you should expect without a saga. Example: InventoryItem aggregate enforces on_hand - reserved >= 0. Failure: updating stock from Orders and Payments concurrently without a single enforcer. Decision rule: if an invariant spans two aggregates in different services, design a saga or rethink the boundary—do not reach across databases.

Domain events vs integration events — A domain event records something meaningful that happened inside a model (often used inside a service). An integration event is a published contract for other bounded contexts (stable name, versioned payload, no leakage of private entity graphs). Decision rule: never publish ORM entities; publish intent-focused integration events with correlation and causation IDs.

  [Identity] --customerId--> [Cart] --checkout--> [Orders]
       |                                          |     \
       |                                          v      v
       |                                    [Payments] [Inventory]
       |                                          |
       +------------------------------------> [Ledger]
  Catalog --SKU--> Inventory / Pricing
  Orders --> Fulfillment --> Notifications

5.3 Context mapping relationships

Bounded contexts collaborate through explicit relationships:

• Partnership — Two contexts succeed or fail together; coordinate releases carefully (use sparingly).
• Customer/Supplier — Downstream (customer) negotiates contracts with upstream (supplier); supplier cannot break consumers casually.
• Conformist — Downstream accepts upstream model as-is (e.g., Identity’s customerId).
• Anti-corruption layer (ACL) — Downstream translates foreign models into its own ubiquitous language (Payments translates PSP — Payment Service Provider — payloads into PaymentIntent). Full card: §7.2.
• Published language — Integration events/APIs form a shared kernel of wire contracts without sharing domain code.

6. Benefits and costs (operational tax)

6.1 Benefits (when earned)

• Independent release of high-churn capabilities.
• Independent scale and capacity planning.
• Failure isolation when bulkheads and async edges are real.
• Technology choice per context (use sparingly).
• Team cognitive load bounded to a context—if ownership is real.

6.2 Costs — the operational tax

Think in categories you must budget for continuously:

• Network and partial failure — Timeouts, retries, idempotency, degraded modes become product requirements.
• Consistency engineering — Sagas, outbox/inbox, reconciliation jobs, support tooling for “eventual” states.
• Multiplied runtime — N services ≈ N deploy pipelines, N credential sets, N saturation points, N on-call runbooks (unless a strong platform amortizes this).
• Data gravity — Reporting and “customer 360” need read models or a warehouse; naive joins across service DBs are gone.
• Contract management — Versioning, consumer-driven contracts, poison-message handling.
• Cognitive and org cost — Distributed tracing literacy; clearer ownership or chaos.

7. Design patterns catalog (what they are before we use them)

A design pattern is a reusable solution to a recurring design problem, with known trade-offs—not a product and not a framework. In distributed systems the same names (Saga, Outbox, Circuit Breaker) appear everywhere; teams fail when they adopt the name without the responsibilities, failure modes, and decision rules. Each card below follows: problem → definition → how it works → example → failure if ignored → decision rule.

7.1 Ports and Adapters (Hexagonal Architecture)

Problem: Domain logic becomes entangled with HTTP controllers, ORM entities, message SDKs, and vendor APIs—so you cannot test invariants without standing up infrastructure, and extraction means rewriting the core.

Definition: Keep the domain (use-cases / aggregates) at the center. A port is an interface the domain needs or exposes (e.g., PaymentsPort.authorize(...), PlaceOrder application service). An adapter is a concrete implementation at the edge (HTTP controller, Kafka consumer, Postgres repository, Stripe client). Dependencies point inward: adapters depend on ports; the domain does not depend on frameworks.

How it works: Orders orchestrates checkout against InventoryPort and PaymentsPort. In a modular monolith those ports are in-process adapters; later the same ports become HTTP/gRPC or messaging adapters without rewriting aggregates.

7.2 Anti-Corruption Layer (ACL)

Problem: An upstream system (legacy monolith, PSP, partner API) speaks a different language and model. Consuming it raw infects your ubiquitous language with foreign fields and invariants.

Definition: An ACL is a translation layer at the boundary of your context: inbound foreign payloads/models become your domain types; outbound calls map your intents into the foreign API. It is a form of adapter focused on model isolation, not just transport.

How it works: Payments receives Stripe webhooks → ACL maps to PaymentIntentCaptured / reason codes → domain updates. Your ledger never stores Stripe’s raw enum soup as truth.

7.3 Database-per-service

Problem: Multiple services reading and writing the same tables couple release schedules, create distributed race conditions, and destroy independent deployability—the schema becomes the real monolith.

Definition: Each service is the only writer of its persistent data (dedicated database, schema, or credentials that forbid foreign writers). Other services get data through APIs, integration events, or projected read models—not shared joins.

How it works: Inventory alone updates stock and reservations. Orders stores order lines and saga state. Reporting builds a denormalized store from events.

7.4 Saga

Problem: A business transaction spans multiple services (reserve stock → authorize payment → capture → ledger). You cannot wrap them in one ACID database transaction without distributed Two-Phase Commit (2PC), which couples availability and holds locks across slow external calls.

Definition: A saga is a sequence of local transactions, each inside one service’s database, coordinated so the overall business outcome is either completed or semantically compensated. It provides process-level consistency, not single-commit atomicity. Named after long-lived transactions literature (Garcia-Molina & Salem); popularized for microservices by Richardson and others.

How it works:

1. Each step commits locally (e.g., Inventory reserves stock).
2. Progress is recorded (saga state machine and/or events).
3. The next step runs (command or reaction to an event).
4. On failure, previously successful steps run compensating transactions (release reservation, void auth)—undoing business effect, not necessarily bitwise DB rollback.
5. Timeouts and reconciliation close gaps when messages are lost or PSP state diverges.

  2PC (usually avoided across services):
  Coordinator --prepare--> A,B,C  then --commit--> A,B,C
  (locks + availability coupled; PSP latency inside the TX = disaster)

  SAGA (preferred):
  Local TX Inventory.reserve     COMMIT
  Local TX Payments.authorize    COMMIT
  Local TX Payments.capture      COMMIT
  Local TX Ledger.post           COMMIT
  on fail after reserve: Local TX Inventory.release  COMMIT
  UI may show intermediate states (Pending / AwaitingPayment)

7.5 Compensating transaction

Problem: Step N of a saga failed after steps 1…N−1 already committed. You cannot roll back those commits with a global undo log across services.

Definition: A compensating transaction is a deliberate business action that reverses or neutralizes a prior local commit’s effect (refund, void authorization, release reservation, reverse ledger entry). Compensation is designed up front as part of the saga—not improvised in support chat.

How it works: Each forward step that is not naturally idempotent-terminal declares its compensation, ordering rules (compensate in reverse order), and what “already compensated” means under retries.

7.6 Saga choreography vs saga orchestration

Problem: You need a saga, but must choose where the workflow “brain” lives.

Choreography — definition: Each service reacts to events from others; there is no central coordinator. The workflow is the emergent graph of subscriptions. Best for fan-out after a terminal business fact (OrderConfirmed → notify, index, analytics).

Orchestration — definition: A coordinator (often the Orders/Checkout service, sometimes a workflow engine) owns an explicit state machine, sends commands to participants, and interprets replies. Best when steps are conditional, ordered, and must compensate (checkout, refund).

7.7 Transactional Outbox

Problem: A service must update its database and publish a message. Doing them as two separate steps is a dual-write: either can succeed alone, leaving silent divergence (DB says confirmed; no event; downstream never moves).

Definition: In the same local database transaction as the business write, insert a row into an outbox table describing the message to publish. A separate publisher process (polling or log-tail / CDC) reads unpublished outbox rows, publishes to the broker, and marks them published. Atomicity of “state change + intent to publish” is guaranteed by local ACID.

How it works:

1. BEGIN → update business tables → insert outbox row → COMMIT.
2. Publisher: read outbox → publish → mark published (idempotent publish).
3. Consumers process with inbox/idempotency (at-least-once delivery still applies).

7.8 Inbox (idempotent consumer)

Problem: Brokers deliver at-least-once: the same message can arrive twice. Handlers that are not idempotent double-charge, double-reserve, or double-email.

Definition: An inbox (or processed-message store) records message IDs (or idempotency keys) that have already been applied. In one local transaction the consumer: checks inbox → applies side effects → inserts inbox row → commits → acknowledges. Duplicates short-circuit.

Related: Idempotency on command APIs uses a client-supplied key with the same idea for HTTP retries, not only messaging.

7.9 CQRS and read-model projection

Problem: Write models optimized for invariants (normalized OLTP) are poor for dashboards, search, and cross-context reports. After database-per-service, SQL joins across services disappear.

Definition: CQRS (Command Query Responsibility Segregation) separates the command side (writes, invariants, aggregates) from the query side (read models shaped for specific screens/reports). In microservices, read models are often projections: projectors subscribe to integration events and upsert denormalized rows in a read store.

How it works: Orders/Payments/Inventory remain systems of record. A projector builds OrderFacts for support UI. Lag is expected; SLOs define how stale is acceptable.

7.10 API Gateway and Backend for Frontend (BFF)

Problem: Browsers and mobile apps should not discover dozens of internal services, terminate TLS unevenly, or orchestrate checkout business rules at the edge.

API Gateway — definition: A shared edge entry for cross-cutting concerns: TLS, authentication, rate limiting, routing, request logging. It is infrastructure, not the home of domain invariants.

BFF — definition: A Backend for Frontend is an API tailored to one client experience (web BFF vs mobile BFF). It composes downstream calls and shapes DTOs for that UI. It may aggregate reads; it must not become the system of record for money or stock.

7.11 API Composition

Problem: A screen needs data owned by multiple services; clients should not fan out to all of them.

Definition: A composer (often BFF or gateway) calls several services (sync) and merges the response. Simple and fine for low fan-out reads; dangerous when used to implement write workflows (hidden sync saga).

7.12 Publish/Subscribe messaging

Problem: The producer should not know or wait for every consumer. Side effects must not block the core transaction path.

Definition: Producers publish events to a broker (topic/exchange); zero or more subscribers consume independently. Enables temporal decoupling and fan-out. Requires durable storage, consumer acknowledgements, poison-message policy (DLQ), and idempotent handlers.

7.13 Dead-Letter Queue (DLQ)

Problem: A poison message (bad payload, bug) fails forever; infinite retries block the partition/queue and amplify load.

Definition: After a retry budget, the broker/consumer moves the message to a Dead-Letter Queue for isolation, alerting, and manual or automated replay after a fix.

7.14 Timeout, Retry, Bulkhead, Circuit Breaker

These are stability patterns (popularized in release-it! / microservices resilience literature). They prevent one slow or failing dependency from taking down the caller.

Timeout — definition: Every outbound call has a deadline. Without timeouts, threads/connections wait forever and exhaust the process.

Retry — definition: Re-attempt a failed call. Safe only for idempotent operations; use exponential backoff and a retry budget. Blind retries on non-idempotent captures cause double charges and retry storms.

Bulkhead — definition: Isolate resources (thread pools, connection pools, even processes) per dependency so exhaustion of pool A cannot starve pool B. Named after ship compartments that limit flooding.

Circuit Breaker — definition: After error/latency thresholds, the breaker “opens” and fails fast (optionally serving a fallback) without calling the dependency; periodic probes (“half-open”) test recovery. Protects both sides from pile-on traffic during outages.

  Caller
    |-- bulkhead pool for Payments
    |-- timeout 300ms
    |-- retry only if idempotent (max 2, exponential backoff)
    |-- circuit breaker: open after N failures → fail fast / fallback
    +-- never retry non-idempotent capture without idempotency key

7.15 Correlation ID and Causation ID

Problem: A single user action fans out across services and messages. Without shared identifiers, logs and traces cannot reconstruct what happened.

Definition: A correlation ID identifies the whole conversation (one checkout attempt). A causation ID identifies the immediate parent message/request that caused this one. Propagate both on every RPC and broker message; include them in structured logs and traces.

7.16 Strangler Fig

Problem: Replacing a monolith in a big-bang rewrite is high risk; you need incremental replacement with production traffic.

Definition: Named after strangler fig vines that grow around a tree: a new implementation gradually intercepts requests for a capability at the edge (routing, facade, or branch-by-abstraction). The old code path shrinks until it can be deleted. Migration is incomplete until the old path is gone.

How it works: Route /notify/* to Notifications service; everything else to monolith. Expand routes over time; delete monolith mailer when metrics prove parity.

7.17 Branch by Abstraction

Problem: You want to change how a capability is implemented (local module → remote service) without a long-lived source-control branch war.

Definition: Introduce an abstraction (port/interface) in the monolith; implement the old behavior behind it; add the new remote adapter; flip traffic via config/feature flag; remove the old implementation when stable. Complements strangler for in-process seams.

7.18 Eventual consistency (as a designed property)

Problem: After you split writes across services, readers cannot always see a single globally up-to-date snapshot immediately after a write.

Definition: The system is eventually consistent when, given no new updates, all replicas/readers converge on the same values. During convergence, different components may disagree briefly. This is not a bug if product, UI, and support are designed for workflow states; it is a bug if you pretend strong global consistency still exists.

8. Communication between services

8.1 REST vs gRPC vs messaging

Synchronous request/response — Caller waits for callee. REST (Representational State Transfer) over HTTP (Hypertext Transfer Protocol) with JSON (JavaScript Object Notation) is ubiquitous, cache-friendly for reads, easy to debug at the edge. gRPC (a Remote Procedure Call framework using HTTP/2 and Protocol Buffers) suits internal low-latency, strongly typed APIs and streaming; worse for ad-hoc browser clients without a gateway.

Asynchronous messaging — Producer publishes to a broker (queue/topic); consumers process later. Enables temporal decoupling and fan-out. Requires durable messaging, idempotent consumers, and poison-message strategy.

Sync chain anti-pattern: Client → A → B → C → D all synchronously. Definition: a request’s success depends on the entire chain being up within stacked timeouts. Why it matters: tail latency multiplies; one slow dependency saturates thread pools upstream. Example: Checkout calls Orders calls Payments calls Fraud calls Ledger inline. Failure: cascading timeouts and retries amplify load (retry storms). Decision rule: keep sync depth short (ideally one hop from gateway to an orchestrator or owning service); push the rest to async saga steps with explicit compensations.

  BAD (sync chain):
  Client -> Orders -> Inventory -> Payments -> Ledger -> Notify

  BETTER:
  Client -> Orders (accept command, return 202/orderId)
             |
             +-- outbox: OrderCheckoutStarted
                    |-> Inventory (reserve)
                    |-> Payments (authorize/capture)
                    |-> Ledger (journal)
                    |-> Notify (email)

8.2 API gateway vs BFF

Pattern cards: §7.10 and §7.11.

API gateway (applied): Edge entry for TLS termination, authn, rate limits, routing—not a second ESB of checkout rules.

BFF (applied): Purpose-built API for one client experience; composes downstream calls and shapes DTOs. Keep money invariants in domain services; BFF/gateway only compose and authorize.

8.3 Applying sagas, compensations, idempotency, delivery, outbox

Full definitions live in the design patterns catalog (Saga, compensation, Outbox, Inbox, eventual consistency). This section applies them to service communication.

Eventual consistency in the UX: After a write, not all readers immediately see the new state; the system converges. For commerce, “order placed” may briefly show “payment pending.” Design UI and support for that—see §7.18.

Saga (applied): Coordinate checkout across Inventory and Payments as local transactions plus compensations—not distributed 2PC. Prefer an explicit Orders state machine for money/stock (§7.4, §7.6).

Idempotency (applied): Same command/message twice → same business effect once. Keys are part of the API contract. See §7.8.

At-least-once delivery: duplicates are normal; “effectively once” = idempotent handlers + outbox—not broker magic alone.

Transactional outbox / inbox (applied): Same local TX as the business write inserts an outbox row; publisher relays to the broker. Consumers dedupe via inbox. See §7.7 and §7.8. Ban dual-write (“update then publish”) on money/stock paths.

  BEGIN TRANSACTION (TX)
    update orders set status='Confirmed' where id=...
    insert into outbox(id, type, payload, created_at) values (...)
  COMMIT
  -- separate publisher --
  read outbox -> publish to broker -> mark published
  consumer: BEGIN TRANSACTION; inbox dedupe; apply; COMMIT; ack

8.4 Choreography versus orchestration in practice

Definitions: §7.6. Both styles implement sagas; they differ in where workflow state lives. This section is the commerce application.

Choreography example (order confirmation fan-out): Orders emits OrderConfirmed. Fulfillment creates a shipment; Notifications sends mail; Analytics records conversion. No central step list—each consumer’s subscription is the workflow. This fits reactive side effects after a terminal business decision.

Orchestration example (checkout): Orders (or CheckoutOrchestrator inside that context) owns states Pending → AwaitingReserve → AwaitingAuth → AwaitingCapture → Confirmed | Failed. It issues commands and interprets replies/events. Money and stock require this clarity because compensations are ordered and conditional.

  CHOREOGRAPHY (implicit graph):
  OrderConfirmed --> Fulfillment
                 --> Notifications
                 --> Search "purchased" signal

  ORCHESTRATION (explicit state machine):
  [Orders saga]
     |-- command Reserve --> Inventory -- reply -->|
     |-- command Authorize -> Payments -- reply -->|
     |-- on fail: command Release / Void ---------->|
     +-- emit OrderConfirmed only from Confirmed state

Why it matters: choreographed checkout often hides “what happens if auth fails after reserve?” in tribal knowledge. Orchestrated notification fan-out often recreates an ESB inside Orders.

Failure if ignored: hybrid accidental workflows—half the steps in events, half in undocumented sync calls—defeat both operability and autonomy.

8.5 Message semantics: commands, events, queries

• Command — Imperative, addressed to one owner, expects acceptance/rejection (ReserveStock). Idempotency keys belong here.
• Event — Past tense, broadcast fact (InventoryReserved). Producers do not know all consumers.
• Query — Read without changing invariants; prefer dedicated read models for cross-context dashboards.

Decision rule: Do not pretend a command is an event (“StockReservationRequested” consumed by five services that all try to reserve). One aggregate owns the mutation.

9. Data ownership and multi-step workflows

Database-per-service — Each service owns its persistent store (physical database, schema, or tightly controlled database with only that service’s credentials). Others obtain data via API, events, or projected read models. Full card: §7.3.

Shared database anti-pattern — Multiple services reading/writing the same tables. This recreates a monolith schema with distributed race conditions and coupled releases.

  Orders database <--only-- Orders service
  Payments database <--only-- Payments service
  Inventory database <--only-- Inventory service
  Reporting database <-- writers: projectors from events (CQRS read side)

CQRS — Separate write models from query-optimized read models/projections. Full card: §7.9; reporting application in §9.1 below.

Why distributed 2PC (Two-Phase Commit) is usually avoided — Two-phase commit across services (prepare/commit with a transaction coordinator) couples availability: any participant or the coordinator blocking stalls the transaction; locks are held longer; failure modes are operationally harsh; cloud databases and polyglot stores often lack cooperative 2PC. Prefer local ACID + saga compensations + reconciliation—see the Saga vs 2PC diagram in §7.4.

9.1 CQRS and reporting without shared joins

Pattern definition: §7.9 CQRS and read-model projection. Here is the reporting application.

Problem: Finance wants “all captured payments with order lines and ship dates.” In a monolith that was a SQL join. After a split, those tables no longer share a database.

Approach: Keep command models normalized per service. Build read models (projections) updated by integration events into a reporting store or warehouse. The projection is eventually consistent by design; finance jobs run after lag SLO, not inside the checkout request.

9.2 Multi-step workflows without 2PC — worked sketch

Suppose checkout must (1) reserve stock, (2) authorize payment, (3) capture, (4) post ledger. A distributed 2PC would hold locks across Inventory and Payments while the PSP round-trip runs—an availability and latency disaster.

Instead:

1. Each step is a local transaction with its own commit.
2. Progress is stored in saga state (Orders).
3. Timeouts move the saga into compensation or “needs operator” with reason codes.
4. Reconciliation closes gaps (e.g., capture succeeded at PSP, local Payments row missing → repair from webhook/PSP query).

10. Cross-cutting platform concerns

• Service discovery — How callers find healthy instances (DNS — Domain Name System, service mesh, cloud service discovery).
• Configuration — Externalized config per environment; no secret prod values in images.
• Secrets — Short-lived credentials from a vault/KMS (Key Management Service); rotation runbooks.
• Authentication / authorization —
  • User tokens (OIDC — OpenID Connect / JWT — JSON Web Token): who the human/customer is.
  • Service identity (mTLS — mutual Transport Layer Security; SPIFFE — Secure Production Identity Framework For Everyone; cloud IAM — Identity and Access Management roles): which service is calling which.
  Decision rule: authorize both—user entitlement and service allow-list—on sensitive commands.
• Observability — Structured logs, metrics (RED — Rate, Errors, Duration; USE — Utilization, Saturation, Errors), distributed traces; correlation ID and causation ID propagated on every RPC and message. Without this, microservices are unoperable.
• Resilience — See full pattern cards in §7.14.
  • Timeouts — Every outbound call has a deadline; without them, hung dependencies exhaust threads.
  • Retries — Only on idempotent operations; exponential backoff; budget caps; never blind-retry captures.
  • Bulkheads — Isolate thread/connection pools so one dependency cannot flood the whole process.
  • Circuit breaker — After error/latency thresholds, fail fast (optional fallback); half-open probes test recovery.

11. Why migrate versus fashion

Legitimate drivers

• Measured release contention: high-value teams blocked on a shared pipeline or regression suite.
• Uneven scale or cost: one capability dominates CPU/IO; scaling the monolith wastes money.
• Blast-radius reduction: regulatory or reliability need to isolate payments / PII (Personally Identifiable Information).
• Org scaling: multiple teams need clear ownership with independent delivery.
• Technology constraint: a capability needs a different runtime for good reasons (not preference alone).

Non-reasons

• “Everyone uses Kubernetes/microservices.”
• Resume-driven development or vendor demos.
• Hoping architecture alone will fix unclear product domain or weak engineering practices.
• Splitting before modular monolith discipline exists.

12. When not to migrate

• Team cannot operate one production system well (no CI, no metrics, no on-call hygiene).
• Domain model and ubiquitous language are still thrashing.
• You need frequent cross-entity ACID and will not invest in sagas/reconciliation.
• Headcount cannot own services end-to-end (you would create orphan deployables).
• The pain is code quality inside modules, not deployability—modularization fixes that cheaper.
• “Migration” is actually a big-bang rewrite with dual-running unclear cutover.

13. Migration strategies and failure modes

13.1 Strangler fig

Full pattern: §7.16. Applied: New implementation gradually intercepts traffic for a capability; the old monolith shrinks until the strangler owns the path. Failure modes: proxy complexity; dual writes without outbox; never deleting the old path (“strangler” becomes permanent duplication).

13.2 Extract service

Definition: Move a modular capability and its data to a new deployable; the monolith (or peers) call it via API/events. Requires database-per-service ownership for the extracted data and usually a strangler or branch-by-abstraction cutover. Failure modes: incomplete data ownership (monolith still writes extracted tables); chatty sync extraction of a non-boundary.

13.3 Branch by abstraction

Full pattern: §7.17. Applied: Introduce an interface in-process; flip implementations from local to remote behind the abstraction; remove the old implementation when stable. Failure modes: abstraction leaks monolith types; feature flags never cleaned up.

13.4 Incremental cutover

Definition: Shadow traffic, percentage rollout, or customer cohort migration with clear rollback. Failure modes: no parity checks; cutting 100% before reconciliation of money/stock divergences.

  Clients -> Edge routing
               |-- /notify/*  -> Notifications service (new)
               |-- /*         -> Monolith (old)
  Over time more paths move; monolith modules deleted, not abandoned.

14. Migration playbook (phases with entry/exit criteria)

15. Common microservices design mistakes and anti-patterns

15.1 Shared database across services

Definition: Two or more services write (or even heavily share write-coupled reads of) the same tables. Why it matters: schemas become a released contract across teams; invariants cannot be enforced in one place. Example: Orders and Inventory both UPDATE stock. Failure: lost updates, coupled migrations, “who broke checkout?” ambiguity. Decision rule: one writer service per table; others use APIs/events/read models.

15.2 Entity-oriented CRUD services

Definition: Services named after nouns in the Entity-Relationship Diagram (ERD) (UserService, OrderService as pure Create/Read/Update/Delete — CRUD) rather than business capabilities and aggregates. Why it matters: workflows still span many sync calls; no home for invariants. Example: Checkout is an orchestration of CreateOrder + UpdateUser + CreatePayment with no owner. Failure: nanoservice mesh of repositories. Decision rule: name and shape services around capabilities and aggregates that own invariants (Checkout/Orders, Payments, Inventory).

15.3 Chatty fine-grained services

Definition: Client or service requires dozens of RPCs to render one screen or complete one command. Why it matters: latency and partial failure explode. Example: Mobile calls 15 endpoints to open cart. Failure: timeouts; over-fetching; BFFs reinvented poorly. Decision rule: coalesce by use-case (BFF or richer service APIs); prefer events for fan-out side effects.

15.4 Distributed monolith (lockstep deploys)

Definition: Separated processes that must ship together. Why it matters: you pay distribution cost without autonomy. Example: Shared library of domain entities forces fleet rebuild. Failure: release trains return. Decision rule: version contracts; ban releasing shared domain models as required lockstep libraries—share only stable kernels (logging, metrics) carefully.

15.5 Synchronous “saga” across many services without timeouts/compensations

Definition: A long sync call graph treated as a transaction, without saga state or compensations. Why it matters: holds resources; unclear recovery. Example: HTTP checkout waits on five services; on timeout, stock reserved and card charged inconsistently. Failure: manual finance cleanup. Decision rule: async saga with persisted state machine, deadlines, and tested compensations.

15.6 Missing idempotency on money/stock commands

Definition: Handlers assume exactly-once delivery. Why it matters: at-least-once is the norm. Example: Double capture after client retry. Failure: customer double-charged; ledger imbalance. Decision rule: idempotency keys on all money/stock/ledger commands; unique constraints in the database.

15.7 Dual-write without outbox

Definition: Update database and publish message in two non-atomic steps. Why it matters: either side can succeed alone. Example: Order confirmed but OrderConfirmed never published. Failure: silent stall of downstream fulfillment. Decision rule: transactional outbox (or CDC (Change Data Capture) from the write store) for integration events.

15.8 Ignoring Conway / no owning team

Definition: Services exist without a durable product owner and on-call. Why it matters: architecture mirrors communication paths. Example: “Platform” team owns twenty domain services. Failure: abandoned queues; slow incident response. Decision rule: no service without a named owning team and SLO.

15.9 Big-bang rewrite

Definition: Rebuild everything as microservices before cutting over. Why it matters: long dual-roadmaps; requirements drift. Example: Two-year rewrite; monolith still serves prod. Failure: rewrite abandoned or rushed incomplete. Decision rule: strangler/extract with production traffic and delete criteria.

15.10 Premature Kubernetes as “architecture”

Definition: Equating orchestration tooling with sound boundaries. Why it matters: Kubernetes (K8s) does not fix a shared database or missing sagas. Example: Monolith on Kubernetes called “migration done.” Failure: ops complexity without design progress. Decision rule: choose runtime for density/ops needs after boundaries and data ownership are clear.

15.11 Shared libraries that force coupled releases

Definition: A “common” package containing domain entities, SQL, or API DTOs that all services must upgrade together. Why it matters: invisible distributed monolith. Example: company-domain-1.2.3 required everywhere. Failure: cannot deploy Payments alone. Decision rule: share only truly generic utilities; duplicate DTOs or generate from contract schemas; never share persistence models.

15.12 Leaking domain models across APIs

Definition: Publishing internal aggregates/ORM graphs as the public contract. Why it matters: every internal refactor breaks consumers. Example: REST returns nested Hibernate entities with lazy-load surprises. Failure: brittle clients; security over-exposure. Decision rule: explicit request/response and event DTOs; anti-corruption layers at boundaries.

15.13 No correlation IDs / unobservable estate

Definition: Logs and messages lack a shared request/workflow identifier. Why it matters: cannot reconstruct a checkout across services. Example: Support sees “payment failed” with no link to order saga step. Failure: long MTTR; unverifiable money trails. Decision rule: propagate correlation and causation IDs on every hop; index them in logs and traces.

15.14 Treating eventual consistency as optional in UI/support

Definition: Assuming users and agents always see strongly consistent global state. Why it matters: races are normal after split. Example: UI shows “paid” while fulfillment still “awaiting payment event.” Failure: duplicate support tickets; agents issue manual refunds incorrectly. Decision rule: model workflow states in UI; expose reason codes; give support tools that read saga state, not ad-hoc database guesses.

15.15 Unversioned or orphan event catalogs

Definition: Events renamed casually; consumers unknown. Why it matters: integration becomes folklore. Example: order_updated means five different things. Failure: poison messages; silent wrong automations. Decision rule: maintain an event catalog (producer, consumers, payload intent, compatibility rules).

16. End-to-end design: transactional commerce system

16.1 Domain map and bounded contexts

  Identity ----customerId----> Cart ----checkoutCommand----> Orders
  Catalog --SKU--> Cart / Inventory
  Pricing --quoteId--> Cart / Orders (optional)
  Orders --reserve--> Inventory
  Orders --pay--> Payments --journal--> Ledger
  Orders --fulfill--> Fulfillment --notify--> Notifications
  Payments --notify--> Notifications

16.2 Aggregates and invariants

• InventoryItem (SKU) — Invariant: on_hand >= reserved >= 0; reservations have TTL; only Inventory mutates stock.
• Order — Invariant: terminal states mutually exclusive (Confirmed, Cancelled, Failed); amounts frozen at confirmation from quoted lines; saga state persisted on the order (or companion process table).
• PaymentIntent — Invariant: capture ≤ authorized; refund ≤ captured; transitions idempotent by key.
• LedgerAccount + JournalEntry — Invariant: every journal entry balances (Σ debits = Σ credits); entries append-only; corrections via reversing entries, never silent edits.
• Cart — Soft state; does not own money or stock; checkout converts a cart snapshot into an Order command.

16.3 Sequence: checkout, capture, refund

  1. Client -> Orders: StartCheckout(cartSnapshot, idempotencyKey)
  2. Orders: create Order(Pending), outbox OrderCheckoutStarted
  3. Orders -> Inventory: ReserveStock(orderId, lines, ttl)  [sync or command]
  4. Inventory: reserve locally; emit InventoryReserved / fail InventoryReserveFailed
  5. Orders -> Payments: CreateAndAuthorize(orderId, amount, currency, key)
  6. Payments: PSP authorize; emit PaymentAuthorized / PaymentAuthFailed
  7. On auth OK: Orders -> Payments: Capture(...)  (or capture at fulfill—policy choice)
  8. Payments: capture; outbox PaymentCaptured
  9. Ledger consumer: post balanced journal (cash/receivable vs revenue clearing)
 10. Orders: status Confirmed; outbox OrderConfirmed
 11. Fulfillment + Notifications consume OrderConfirmed

  Compensations:
  - Auth fail after reserve -> ReleaseStock; Order Failed
  - Capture fail -> void/cancel auth if needed; ReleaseStock; Order Failed
  - Post-confirm refund -> Payments Refund + Ledger reversing entry + Inventory restock policy

Policy choice: authorize-at-checkout / capture-at-ship vs capture-at-checkout. Capture-at-ship reduces refund volume but prolongs authorization holds; document the policy in the saga.

16.4 Event catalog (integration events)

16.5 Sync vs async choices per edge

16.6 Consistency strategy

Local ACID inside Inventory, Payments, Ledger, Orders. Cross-service: orchestrated saga on Orders (or a dedicated Checkout orchestrator in the Orders context) + transactional outbox on every producer + inbox idempotency on consumers. Reconciliation jobs: expired reservations without payment; captures without ledger posts; orders stuck in non-terminal states beyond SLO.

16.7 Suggested service APIs (outline)

  Orders
    POST /orders/checkout          Idempotency-Key required
    GET  /orders/{id}
    POST /orders/{id}/cancel

  Inventory
    POST /reservations             {orderId, lines, ttl}
    POST /reservations/{id}/release
    GET  /availability?sku=

  Payments
    POST /payment-intents          {orderId, amount, currency, customer}
    POST /payment-intents/{id}/capture
    POST /payment-intents/{id}/refund
    POST /webhooks/psp

  Ledger
    POST /journals                 (usually internal consumer; admin post rare)
    GET  /accounts/{id}/entries

  Fulfillment
    POST /shipments
    POST /shipments/{id}/dispatch

  Notifications
    (consume events; optional POST /admin/preview)

16.8 Failure scenarios and compensations

16.9 Minimum deploy topology (conceptual)

  [clients]
      |
  [api-gateway / BFF]
      |
  +---+---+----+------+----------+------------+
  |       |    |      |          |            |
orders inventory payments ledger fulfillment notifications identity catalog cart
  |       |    |      |          |            |
  db-o   db-i  db-p  db-l      db-f          db-n  ...

  [message-broker] <-- outbox publishers / consumers

  [otel-collector] -> traces/metrics/logs backends
  [secrets] [config]

This is deliberately vendor-neutral: any managed Postgres/MySQL, any broker (NATS/Kafka/RabbitMQ), any gateway. The architecture is the boundaries, contracts, and saga—not the brand of orchestrator.

16.10 Ledger design notes (money invariants)

A minimal chart of accounts for the first cut:

• Assets: PSP Clearing — increases on capture; decreases on payout/settlement or chargeback.
• Liabilities: Customer Credits — gift cards / store credit if applicable.
• Revenue: Product Sales — recognized per your revenue policy (capture vs shipment).
• Contra / Refunds — refunds as reversing or contra-revenue entries.

  Journal entry (paymentId=pay_9, orderId=ord_9, amount=100.00 USD):
    DR  PSP Clearing          100.00
    CR  Revenue - Product     100.00
  Constraints:
    - unique (paymentId, entryType=CapturePost) for idempotency
    - sum(DR) == sum(CR) enforced in Ledger aggregate transaction
    - no UPDATE of posted lines; refund creates a new balanced entry

Refund sequence: Support/API → Orders validates refundability → Payments Refund with idempotency key → PSP → RefundSucceeded → Ledger reversing entry → Inventory restock command (policy) → Notifications. Orders stores refund workflow state; it does not invent balances.

16.11 Support and UI under eventual consistency

Expose to operators: saga state, last reason code, paymentId, reservationId, correlation ID, and links to PSP dashboard. Never instruct agents to “just UPDATE the orders table.” Build a support command API that reuses the same idempotent domain commands.

17. From zero to a running first cut

17.1 Prerequisites

Skills

• Comfortable with one backend stack (HTTP APIs — Application Programming Interfaces, relational database transactions, migrations).
• Understand ACID vs eventual consistency at a conceptual level (this guide’s earlier sections).
• Can read distributed traces and structured logs.
• Basic message broker concepts: publish, consume, ack, retry, dead-letter.

Environment

• Local container runtime; ability to run 2–3 app processes + 1 database + 1 broker.
• CI that can build more than one deployable artifact.
• A staging environment that mirrors correlation-ID propagation.

17.2 Week / phase plan

Phase A — Modular monolith (weeks 1–3)

Goal: one deployable commerce app with module boundaries and separate schemas (or schema namespaces) for Catalog, Cart, Orders, Inventory, Payments (facade), Notifications.

Work: define ubiquitous language glossary; implement checkout as in-process ports; architecture tests forbidding illegal imports; single database OK but no cross-module table writes.

Definition of done: place-order test passes in one local ACID transaction where still in-process; module dependency graph is acyclic; glossary reviewed with a domain partner.

Measure: build time; test time; count of illegal dependency violations (should be zero).

Phase B — Add broker + outbox in-process (weeks 3–5)

Goal: publish integration events via transactional outbox even while consumers may still live in-process or as a worker.

Work: outbox table; publisher relay; at-least-once consumer with inbox; correlation IDs on messages.

Definition of done: kill the process after database commit but before publish; relay recovers event; duplicate delivery does not double-send email in a test.

Measure: outbox lag; duplicate delivery test green.

Phase C — Extract Notifications (weeks 5–7)

Goal: first independently deployable service; lowest money risk.

Work: Notifications service owns its database; consumes OrderConfirmed / PaymentCaptured; strangler delete of monolith mailer.

Definition of done: monolith contains no email-sending code path; deploy Notifications without redeploying monolith; traces show correlation across both.

Measure: notification success rate; deploy frequency of Notifications vs monolith.

Phase D — Extract Payments with ledger constraints (weeks 7–12)

Goal: money path with idempotency and ledger posting.

Work: Payments service + Ledger service (or Ledger module extracted with Payments if staffing is thin—prefer separate write models even if co-deployed initially, then split); saga compensation with Inventory still in monolith or extracted; PSP sandbox; webhook inbox.

Definition of done: duplicate capture and duplicate webhook tests pass; journal always balanced; reconciliation report for “captured but not posted” is empty in staging soak; compensations covered by automated tests.

Measure: payment success, saga completion time, reconciliation exceptions count, refund correctness sample.

Phase E — Gateway / BFF + harden (weeks 12–16)

Goal: edge composition, resilience, operability.

Work: API gateway or BFF; timeouts/bulkheads/circuit breakers on sync edges; contract tests; load test checkout; runbooks.

Definition of done: dependency failure (Notifications down) does not fail checkout; Payments down fails checkout gracefully with reason codes; dashboards for RED metrics per service; on-call owners named.

Measure: error budget burn; p95 checkout; MTTR with correlation-ID drills.

17.2.1 Detailed activities inside each phase

Phase A daily practice: Write three architecture tests (Orders cannot import Inventory persistence; Payments cannot import Orders entities; Catalog cannot write stock). Pair with a domain expert for one hour on glossary conflicts (“status,” “reserve,” “capture”). Deliver a thin vertical checkout that still uses in-process adapters.

Phase B daily practice: Implement outbox polling or log-tail publisher; add consumer that writes inbox + side effect in one database transaction (TX); run chaos: kill publisher, duplicate message, poison payload → Dead-Letter Queue (DLQ). Document message headers: correlationId, causationId, messageId, contentType, schemaVersion.

Phase C cutover: Shadow-send emails from both monolith and service for 48h; compare; route 10% → 50% → 100%; delete monolith mailer; remove feature flag.

Phase D rehearsal script (staging):

1. Checkout happy path; assert ledger balanced.
2. Replay identical idempotency key; assert no second capture.
3. Fail reserve; assert no payment object in Captured.
4. Authorize then kill Payments before capture response; recover via PSP query + resume.
5. Refund partial amount; assert ledger + order state.
6. Expire reservation TTL; assert stock returns.

Phase E resilience drills: Block Notifications network; checkout must succeed. Inject 500ms–2s latency on Inventory; verify timeouts and user-visible errors, not thread exhaustion. Break the broker; verify outbox lag alerts fire before customer impact on already-accepted commands.

17.3 What to measure (ongoing)

• Saga state histogram (how many orders in each non-terminal state, age).
• Outbox/consumer lag.
• Idempotency conflict counts (should be benign short-circuits).
• Ledger imbalance alerts (must be zero).
• Deploy lead time per service; change fail rate.
• Incident blast radius (services touched per SEV (severity) incident).

17.4 Skills ladder (what to study alongside the build)

1. Relational transactions and isolation levels (why idempotency unique keys matter).
2. HTTP timeouts and retry semantics.
3. One broker deep enough to configure a Dead-Letter Queue (DLQ) and consumer acknowledgement.
4. OpenTelemetry traces across HTTP and messaging.
5. DDD tactical patterns (aggregate, domain event) from a primary text—then apply here.
6. Payment provider sandbox webhooks and signature verification.

Avoid starting with service mesh, multi-cluster Kubernetes, or polyglot rewrites. Those amplify mistakes before you have boundaries.

18. Conway’s law and organization

Conway’s law — Organizations design systems that mirror their communication structure. If all domain changes require a central committee, your “microservices” will behave like a distributed monolith. Inverse Conway maneuver: deliberately shape teams to the bounded contexts you want (Orders team, Payments team), with a platform team providing paved roads—not owning business invariants.

19. Closing checklist

• Bounded contexts named with glossaries; aggregates and invariants written down.
• Each service has one owning team, SLO, and on-call.
• Database-per-service (or exclusive schema credentials); no cross-service writes.
• Sync depth bounded; chatty edges redesigned; Backend for Frontend (BFF) / gateway without domain god-logic.
• Money/stock flows use saga + compensations + idempotency keys.
• Outbox/inbox (or proven Change Data Capture — CDC) on integration events; event catalog maintained.
• Ledger (or equivalent books) for financial truth; reconciliation jobs exist.
• Timeouts, retries (idempotent only), bulkheads, circuit breakers on sync calls.
• Logs/metrics/traces with correlation and causation IDs.
• Authentication / authorization (authn/authz): user tokens and service identity on sensitive paths.
• Migration path is strangler/extract with delete criteria—not big-bang only.
• UI and support tooling expose workflow states under eventual consistency.
• Shared libraries reviewed for lockstep risk.
• Operational tax budgeted; platform thin slice exists before many extractions.

20. Wrapping up

Software architecture is the set of hard-to-reverse decisions about boundaries, contracts, data ownership, deployment, and failure. Monoliths and modular monoliths remain excellent defaults. Microservices are justified when independent deployability, heterogeneous scale, or org isolation outweigh the tax of partial failure, eventual consistency, and operability.

For complex transactional systems, competence means designing aggregates and invariants, choosing sync versus async edges deliberately, coordinating with sagas rather than Two-Phase Commit (2PC), publishing via outbox, and keeping a ledger for money. Migration succeeds as an incremental strangler with exit criteria—not as a fashion rewrite.

If you can draw the commerce context map, name the saga states, and operate the first extracted service with correlation-quality observability, you are ready to deepen the cut. If you cannot, modularize first; the network will not invent the missing design.