Do not start with microservices

Start with a monolith. Microservices are an optimisation for team scale and independent deployment. A team of 5 does not need them. Extract services when the monolith's boundaries become a bottleneck.

The strangler fig pattern

  1. Build the new service alongside the monolith.
  2. Route traffic to the new service via a facade/proxy.
  3. Once the new service handles 100% of the traffic for that capability, delete the code from the monolith.

Identifying good extraction candidates

  • High-churn modules with independent deployment needs.
  • Modules with different scaling requirements (a PDF generator needs different resources than an API server).
  • Clear data ownership — the module owns a set of tables that nothing else writes to.

The distributed monolith anti-pattern

Services that must deploy together, share a database, or make synchronous chains of calls are a distributed monolith. It has all the complexity of microservices with none of the benefits. The solution is data ownership: each service owns its data and exposes it only through its API.