Microservices Patterns — From Monolith to Services

We decided to break our monolith into microservices. Rewrite from scratch? No — that’s a recipe for disaster. The Strangler Fig pattern: gradually extracting services from the monolith. Piece by piece, without a big-bang migration.

Strangler Fig Pattern¶

Like a fig tree that grows around another tree. New features are implemented as microservices. Existing features are gradually extracted. A proxy (API Gateway) routes requests — to old code or to a new service. The monolith shrinks over time.

API Composition¶

A client needs data from multiple services. An API Composer (in the gateway or as a dedicated service) calls services in parallel and assembles the response. Watch out for latency — N calls add up. Caching and asynchronous calls help.

Saga Pattern¶

A distributed transaction across multiple services. Instead of 2PC (two-phase commit), a sequence of local transactions with compensating actions. Order flow: reserve inventory → charge payment → ship. On failure: compensate (refund → release inventory).

Database per Service¶

Each service owns its own data. No shared tables. Data duplication is acceptable — eventual consistency via events. This is the biggest mental shift for developers accustomed to a single shared database.

Patterns, Not Frameworks¶

Microservices are not about technology — they are about patterns. Strangler for migration, Saga for transactions, CQRS for read/write separation. Knowledge of patterns matters more than knowledge of any particular framework.