Fundamentals and Decomposition

7 pages · ~5 min✓ Reviewed

Start here. Next up: Service Communication.

MicroservicesPage 1

Monolith vs Microservices: The Mental Model

1. Two Shapes

Monolith: one deployable, one process, usually one database
Modules call each other in-process
Microservices: small services, each owns one business function and its data
They talk over the network: HTTP, gRPC, events

	Monolith	Microservices
Deploy	one unit	per service
Calls	function call	network
Data	one DB	DB per service

2. Trade-offs

	Wins	Fits / price
Monolith	one deploy, local calls, ACID, easy debugging	small teams, unclear domains
Microservices	independent deploys, per-service scaling, team autonomy, fault isolation	network failure, latency, distributed data consistency

3. Modular Monolith

One deployable with strict module boundaries
The usual best starting point
Cheapest path to splitting later

Default

Start with a modular monolith. Extract a service only when a clear pain appears.

MicroservicesPage 2

Bounded Contexts and Business Capabilities

1. Bounded context

Bounded context (DDD): a boundary where a domain model and its terms have one consistent meaning
Same word, different models: each context owns its own version

Term	Billing	Shipping
`Customer`	payment method, invoices	address, delivery window

2. Drawing the boundary

Decompose by business capability: Orders, Payments, Inventory, Shipping
Capability = what the business does
Not by technical layer: UI service, DB service
Size rule: one team owns it, changeable with no coordinated release

3. Context map

Relationship	Meaning
Customer/Supplier	upstream supplies, downstream needs shape its API
Shared Kernel

MicroservicesPage 3

Database per Service and Data Consistency

1. Own Your Data

Database per service: only the owner touches its data
Others use its API or events, never its tables

Shared DB couples services by schema
One column change breaks several teams
Blocks independent deploys

2. Queries Across Services

Need	Use instead
Cross-service join	API composition: query services, merge result
Cross-service join, fast reads	CQRS read model built from events
ACID across services	Saga (below)

3. Saga and Eventual Consistency

Saga: local transactions, each with an undo

1Reserve stockundo: release
2Charge paymentundo: refund
3Ship orderundo: cancel

Choreography: services react to each other's events
Orchestration: a coordinator commands each step

MicroservicesPage 4

Strangler Fig Migration

1. The Pattern

Strangler fig: a facade (API gateway or reverse proxy) sits in front of the monolith
Route traffic to new services one capability at a time
Old code shrinks until nothing is left to serve

Client
Facadegateway / proxy
New servicemigrated slice
Monolitheverything else

2. The Loop

1Identify a seam
2Build new service
3Route a slicesmall % of traffic
4Verify
5Retire old codethen repeat

First slice: low coupling, clear value (notifications, search)
Leave the tangled core for last

3. Data and Rollback

Approach	Verdict
Dual writes	Risky: one write can fail, data drifts
Change data capture	Preferred: stream DB changes to the new service

MicroservicesPage 5

Common Mistakes and Trade-offs

1. Splitting Mistakes

Distributed monolith: services must deploy together or share a DB
Pays all the cost of microservices, gets none of the benefit
Split too early: guessed boundaries are costly to move
Start with a modular monolith

2. Chatty Calls

Clientone request
Orderssync hop
Pricingsync hop
Stocksync hop
Taxsync hop

Each sync hop adds latency and failure rate
Five hops at 99.9% each give about 99.5% available
Fix: coarser services or async events

3. Ops and Team Fit

Missing basic	Why you need it
Tracing	follow one request across services
Centralised logs	one place to search
CI/CD per service	independent deploys
Timeouts, retries, circuit breakers

MicroservicesPage 6

Cheat Sheet: Monolith vs Microservices

1. Default Path and Boundary Test

Start with a modular monolith
Extract only for a clear pain: scaling, team conflict, deploy cadence
Boundary test: one team, one capability, one bounded context, one data store

2. Data Rules

Own your data: only the owner touches its tables
No shared tables, no cross-service joins

Need	Use
Read another service's data	API or events
Query across services	API composition, CQRS read model
Multi-service write	Saga with compensations
DB change + event, atomically	Outbox, idempotent consumers

3. Migration Recipe

1Facadegateway or proxy
2New service
3Route slice
4Verify
5Retire old code
6Data ownershiplast

MicroservicesPage 7

Check yourself

Orders and Payments share one database, each with its own deploy pipeline. Payments renames a column. What happens, and what is this called?

Orders breaks, so the two must coordinate releases
A distributed monolith: microservice costs, no independent deploys
Fix: Payments owns its data; Orders uses its API or events

Checkout calls Payments, which calls Inventory. Inventory fails after Payments charged the card. How do you restore consistency?

No cross-service ACID transaction exists
Use a saga: run a compensating action, such as a refund
Orchestrate via a coordinator or choreograph via events

A team of 4 engineers has an unclear domain. They plan 12 services. What is wrong, and what is the better start?

Boundaries guessed early are wrong and costly to move
More services than engineers: tracing and CI/CD overhead
Start with a modular monolith, extract only on clear pain