Monolith and Microservices

One Product Can Be Split in Different Ways

Application architecture is not a choice between an “old monolith” and “modern microservices.” The main question is different: where responsibility boundaries should be and how independently different parts of the system need to change, be deployed, and scale.

A monolith can be simple and convenient, while microservices can add more problems than they solve. So in this section we will first understand the purpose of each approach and only then see when splitting the system is actually justified.

What We Will Cover

• Monolith. We will see how an application works when it is built and deployed as one unit and why this is often a good starting point.
• Modular Monolith. We will learn how to keep a single deployment while introducing explicit internal boundaries between parts of the system.
• Microservices Basics. We will understand what makes a service independent and what new properties appear after an application is split into processes.
• Service Decomposition. We will learn to find sensible parts of the system to extract instead of splitting the application by tables or technical layers.
• Service Boundaries. We will examine which data and rules should belong to one service and why a poor boundary creates permanent dependencies.
• Database per Service. We will see why microservices should own their data and why a shared database brings strong coupling back.
• Migration to Microservices. We will examine gradual migration instead of a risky rewrite of the entire system at once.
• Microservices Trade-Offs. We will bring together the cost of distributed architecture and the criteria under which its benefits really pay off.

We will move from the simplest application form toward greater independence of system parts. This will make it clear not only what microservices provide, but also what price must be paid for that independence.