Monolith → microservices decomposition
A repeatable pattern for slicing a monolith into independently deployable services without rewriting the world.
Step 1 — Identify seams
Map every HTTP route and database table to a bounded context. Group by business capability, not by layer. If two tables share a foreign key but belong to different domains, mark the boundary.
Step 2 — Extract the data
Spin out a dedicated schema or database per context. Use change-data capture to keep the old monolith table in sync during the transition window. Never share a database across services.
Step 3 — Strangle the endpoints
Route traffic with a reverse proxy. Move one endpoint at a time from the monolith to the new service. Keep both implementations alive until the new one proves stable under production load.
Step 4 — Retire the old code
Once telemetry confirms zero traffic to the monolith path, delete the dead code and drop the legacy tables. Run a retro to capture latency deltas and schema drift surprises.
Anti-pattern: extracting services by layer (e.g. a standalone “user service” that only wraps the users table). Decompose by business capability, not by CRUD surface area.