Microservices Architecture
Splitting one large Node application into small, independently deployable services
- explain what a service boundary is and how to find one (bounded contexts, not layers);
- choose between synchronous (request/response) and asynchronous (event/message) communication;
- apply the database-per-service rule and understand why a shared database breaks microservices;
- weigh the honest trade-offs of microservices against a well-built monolith;
- recognise when a monolith is the right answer and microservices are premature.
1. From monolith to services
A monolith is one deployable unit. In the Node world that is a single Express app: routing, business logic, and database access all live in one process and ship together. That is a perfectly good architecture - it is simple to run, easy to debug with one stack trace, and a database transaction can span your whole domain. Most systems should start here.
A monolith becomes painful when a single codebase and single deploy start to hurt the team: one slow module forces you to scale the entire app, one risky change blocks every other release, and a growing team keeps colliding in the same files. Microservices answer these organisational and scaling pressures by splitting the app along business capabilities - orders, payments, inventory, notifications - each running as its own Node process, deployed on its own schedule, scaled on its own metrics.
Analogy. A monolith is a single large restaurant kitchen where every cook shares one set of counters, one fridge, and one order pad. It is efficient while the team is small. Microservices are like a food court: each stall (grill, sushi, bakery) has its own counter, its own fridge, its own staff, and can open, close, or expand without shutting the others. Coordination now happens through tickets passed between stalls rather than a shout across one room - more moving parts, but each stall scales and fails on its own.
The key mental shift: microservices are less a technical pattern and more an organisational one. You adopt them so independent teams can build, deploy, and scale independently. If you do not have that pressure, the extra machinery is pure cost.