Typorithm · medium

Service Decomposition

service-decompositionarchitecturemicroservicesbounded-contextdecomposition

Saved on this device

Full lesson · 8 learning steps Open any exercise for focused practice

Step 1 of 8 · intro card

Learn Service Decomposition

Microservices

Decompose by business capability or DDD bounded context, with each service owning its data (database-per-service). Services stay loosely coupled behind contracts and independently deployable; the anti-pattern is a distributed monolith whose services must deploy together.

Microservices are split along business capabilities or domain-driven design bounded contexts — Orders, Payments, Inventory — rather than along technical layers like one service per database table.

Each service privately owns its data with a database-per-service. No other service reaches into those tables directly; data is exposed only through the owning service's API or events.

Services stay loosely coupled behind contracts and remain independently deployable. The classic anti-pattern is a distributed monolith: separate processes that must be released in lockstep, so you pay network latency without gaining autonomy.

Boundaries follow business capabilities / bounded contexts.

Each service owns its data (database-per-service).

Independently deployable behind loose contracts.

microservices:
  boundary: by-business-capability
  data: database-per-service
  coupling: loose-via-contracts
  size: independently-deployable
  pitfall: distributed-monolith

Read the implementation

Connect each part of the code to the concept before you type.

1. Service boundary

Split services along business capabilities (or DDD bounded contexts), not technical layers.

boundary: by-business-capability

2. Owned data

Database-per-service means each service privately owns its data and no one else reads its tables.

data: database-per-service

3. Loose coupling

Services interact only through stable contracts, so internals can change without breaking others.

coupling: loose-via-contracts

4. Deploy unit

A good service can be built, tested, and deployed on its own release cadence.

size: independently-deployable

5. Anti-pattern

A distributed monolith is the failure mode where services must deploy together, paying network cost for no autonomy.

pitfall: distributed-monolith

A complete learning loop

Understand

Read the concept map and follow the code breakdown.

Reconstruct

Type the implementation, repair mistakes and work through every recall exercise.

Verify

Use the final check without hints; revisit weak concepts in short practice sessions.