Skip to main content

Module 2: Microservices & Service Decomposition: Worked Examples

Example 1: Avoid an Entity-Service Decomposition​

Splitting an order system into Customer, Order, LineItem, and Address services follows database nouns, not business capabilities. Placing an order now requires synchronous calls across four services and no service owns the invariant.

Correct reasoning. Start from workflows and bounded contexts. Ordering owns order acceptance; Inventory owns reservation; Payment owns authorization. Exchange contracts express outcomes rather than exposing tables. Keep the first implementation modular and extract only where independent ownership, scale, compliance, or delivery evidence pays the operational tax.

Example 2: Give Each Service Its Data​

Wrong attempt. Two services share tables to avoid duplication. This creates runtime and migration coupling with invisible ownership.

Define a single writer, published API/event contracts, local read models where necessary, and reconciliation for drift. Duplication is acceptable when ownership and freshness are explicit.

Example 3: Bound a Synchronous Call Chain​

A request traversing five services multiplies latency and failure probability. Collapse nonessential calls, move side effects behind durable asynchronous handoff, set deadline budgets, and degrade optional data. Retries consume the original deadline and require idempotency.

Completion Standard​

  • Produce capability-based boundaries with owners and invariants.
  • Record a distribution-tax ledger for one extraction.
  • Demonstrate failure behavior for one synchronous and one asynchronous collaboration.