To properly understand what microservices bring, you have to understand equally well what they are being compared with: the monolithic architecture. It is the most common way of building software, the one TechCorp uses today and, most likely, the one you have used in most of your projects. Far from being a relic, the monolith has important virtues and, when well built (the so-called modular monolith), it is an excellent choice for a great many systems.

In this lesson we will define what a monolith is and its variants, compare both architectures dimension by dimension with a table and diagrams, and follow step by step the lifecycle of the same functional change ("adding discount coupons to TechCorp's store") in each of them to see where the real differences lie. We will finish by dismantling the myth that the monolith is always the bad option. We will not yet decide here when one or the other is appropriate (that comes in lesson 01-04), nor look at the technique of splitting a monolith (lesson 02-02).

1. What a monolith is
2. The modular monolith: a middle ground
3. Dimension-by-dimension comparison
4. The two systems in diagrams
5. One change, two lifecycles: discount coupons at TechCorp
6. Other alternatives: SOA and the modular monolith as a destination
7. The myth that the monolith is always bad
8. Common mistakes and tips
9. Exercises
10. Conclusion

A monolith is an application built and deployed as a single unit: one process (or one artifact running as several identical processes), usually one code repository, and almost always one database. All the functionality (interface, business logic, data access) lives in the same deployment.

Typical characteristics:

• One deployment unit: everything is compiled or packaged together and shipped together. At TechCorp, techcorp-shop is a single Node.js project started with node server.js that serves the whole store.
• In-memory internal calls: when the orders module needs to check stock, it calls a function of the inventory module in the same process. Nothing travels over the network.
• One shared database: all the tables (customers, products, stock, orders, payments, notifications) live in the same PostgreSQL and any module can query any table. Transactions span whatever they need to.
• Horizontal scaling by full replica: if more capacity is needed, several identical copies of the monolith run behind a load balancer.

It is important to stress that "monolith" does not mean "messy code". A monolith can be perfectly organized into layers and modules. When a monolith's code is tangled, with no clear internal boundaries, people talk about a big ball of mud, which is a code quality problem, not a deployment architecture one.

A modular monolith is a monolith whose code is divided into modules with explicit boundaries, each with its internal API and, in the most disciplined version, with its own schema or set of tables that the other modules do not access directly. It is still deployed as one unit, but on the inside it looks a lot like a set of microservices living in the same process.

The modular monolith has a double value: it is an excellent architecture in its own right, and it is also the best starting point if you ever want to migrate to microservices, because the boundaries are already drawn. A well-isolated module can be "extracted" into a service with relative ease; a ball of mud cannot. We will come back to this idea in module 2.

This is the central table of the lesson. It compares both architectures along the dimensions that matter most in practice. Read it calmly; almost every row corresponds to a later lesson in the course.

A useful way to read the table: the monolith is simple at first and gets complicated as it grows; microservices are complicated at first and keep complexity bounded as they grow. The question of where the crossover point lies is exactly what we will tackle in the next lesson.

Everything lives inside the same rectangle. The arrows between modules are function calls. All modules point to the same database.

Each service has its own rectangle and its own database. Relationships between services go over the network (HTTP or RabbitMQ). The gateway is the only point of contact with the outside world.

Nothing illustrates the differences better than following a real change. Marta asks for a new feature: discount coupons. A customer enters a code when placing the order, the system validates the coupon, applies the discount to the total and records that the coupon has been used. In addition, the catalog must be able to show which products accept coupons, and a different email must be sent when the order carries a discount.

Bottom line: fast, simple development (one transaction, one repository, one deployment), but tied to the global deployment calendar, at risk of stepping on other changes, and with a deployment that drags everything along.

Bottom line: more up-front work (defining the service, API, contracts, failure handling), but independent deployments, teams that do not step on each other, and a business capability (promotions) that is born already isolated and will be able to evolve on its own.

• The monolith optimizes developing the change; microservices optimize delivery and independent evolution.
• In the monolith the difficulty shows up at the end (coordinating the deployment, rolling everything back). In microservices it shows up at the beginning (deciding boundaries and contracts).
• Failure handling, which the transaction solves in the monolith, is an explicit design decision in microservices.

The choice is not binary. Between "one monolith" and "dozens of microservices" there are valid intermediate stops:

• Modular monolith (seen in section 2): same deployment, rigorous internal boundaries. Many organizations should aim for this and stay here. It is also the ideal foundation for extracting services in the future.
• "Classic" SOA: coarser-grained services than microservices, often with an integration bus. Still common in large corporations. It shares with microservices the idea of services, but with more centralization (see lesson 01-01).
• A few large services ("macroservices"): splitting the system into two or three pieces for very specific reasons (for example, separating the read-heavy catalog from the rest) without going any further. This is a pragmatic strategy that captures part of the advantages at a fraction of the cost.

None of these options is "cheating". They are different points on the same spectrum, and the sensible thing is to pick the one that addresses the real problems you have.

This is worth saying plainly, because the industry sometimes forgets it: the monolith is not an architectural mistake. It is the correct default for most new projects and for many mature systems. Its advantages are real:

• You start delivering value in days, not after months of infrastructure.
• A developer can understand and run the whole system on their laptop.
• Transactions and JOINs solve for free problems that in microservices cost complex patterns.
• Refactoring is easy because the compiler or the tests see all the code at once; moving a responsibility from one module to another means changing an import, not renegotiating a contract between teams.
• Operating it is cheap: one process, one database, one log.

Large, highly respected companies operate huge monoliths successfully, and others that migrated to microservices have partially gone back to consolidating services because the operational cost did not pay off. Microservices do not make a system good; they solve a specific set of problems (uneven scaling, teams getting in each other's way, slow deployment cycles) in exchange for another set of problems. If you do not have the former, do not buy the latter.

The TechCorp case we follow in the course was chosen precisely because it does have those problems: campaigns that saturate only the catalog, weekly deployments made in fear, teams stepping on each other in the same code. That is why its story is a migration story. But a four-person TechCorp with a thousand orders a month should stay on its monolith, ideally a modular one, and be happy.

• Confusing monolith with bad code. A monolith can be impeccably organized. If the problem is that the code is chaos, the solution is to refactor toward a modular monolith, not to spread the chaos across the network.
• Comparing a real monolith with idealized microservices. It is easy to win the debate if you compare the legacy monolith full of technical debt with a clean services diagram. Compare with the same honesty: microservices accumulate debt too, just distributed.
• Forgetting the initial cost. The comparison table shows that microservices pay up front. If the project needs to deliver value in weeks, that cost can be prohibitive.
• Thinking that transactions are simply "replaced". Moving from "one transaction that does everything" to "several services with no common transaction" is the hardest part of the comparison and deserves the most attention in the design.
• Tip: when evaluating a functional change, do the exercise from section 5 in your head: walk through the steps in your current architecture and in the alternative. It is the fastest way to spot where the real costs are.

For each description, state whether it is a classic monolith, a modular monolith or microservices, and justify your answer using the table in section 2.

1. A Node.js application in a single repository, divided into customers/, catalog/ and orders/ folders, each with its own set of tables that the other folders access only through the module's public functions; it is deployed as a single process.
2. Six independent Node.js processes, each with its own database, that communicate over HTTP and RabbitMQ and are deployed separately.
3. A Java application deployed as a single .war file in which any class can run SQL queries against any table.

Marta asks for another feature: a wishlist (a customer can save products for later and receive an email if their price drops). Describe, as a list of steps like in section 5, how it would be implemented in TechCorp's current monolith and in the microservices version. Point out the most expensive step in each.

A colleague claims: "Monoliths are a thing of the past; any serious project today should start with microservices". Write three arguments, backed by the table in section 3, to rebut them.

Exercise 1

1. Modular monolith. One deployment unit, but with explicit boundaries between modules and "private" data per module. It is exactly the middle ground described.
2. Microservices. Several deployment units, one database per service, network communication.
3. Classic monolith (and probably drifting toward a ball of mud). One deployment unit and indiscriminate data access.

Exercise 2 (one possible solution)

Monolith:

1. Migration: wishlist (customer_id, product_id, price_at_time) table.
2. Endpoints in the customers routes to add and list wishes, with a JOIN to products to show the name and current price.
3. When a product's price is updated (catalog module), query wishlist and call the notifications function to send the email, all in the same process.
4. Tests for the complete application; weekly deployment. Most expensive step: the joint deployment and the slow tests; the development itself is simple.

Microservices:

1. Decide where the wishlist lives: probably in customers-service (it is a customer preference).
2. customers-service adds its table and endpoints; to show the name and current price it must call catalog-service or keep a local copy updated through events.
3. catalog-service publishes a product.price-changed event; customers-service consumes it, looks up who had that product on their list and publishes something like wish.price-drop; notifications-service consumes that and sends the email.
4. Contracts: define the two new events and their fields.
5. Independent deployments of catalog, customers and notifications, in that order. Most expensive step: deciding how customers obtains the product data (synchronous call versus event-driven copy) and designing the event chain; failures and duplicates have to be thought through.

Exercise 3 (possible arguments)

• Initial cost: a monolith delivers value in days with one server and one database; microservices demand containers, orchestration, messaging and observability before the first feature. For a new project, whose biggest risk is not finding a market, that cost is hard to justify.
• Data and performance: in a monolith, a transaction and a JOIN solve problems that in microservices require sagas, data duplication and network calls with latency. While the domain is not yet clear, that simplicity is worth its weight in gold.
• Teams: the autonomy advantages of microservices only appear when there are several teams getting in each other's way. With a single small team there is nobody to stop getting in the way of, and there are many more services to operate. Besides, a modular monolith offers clear boundaries at no network cost and leaves the door open to extracting services later.

In this lesson we defined the monolith as a single deployment unit with a shared database and in-memory internal calls, and we presented the modular monolith as a disciplined variant that combines the monolith's operational simplicity with clear internal boundaries. The dimension-by-dimension comparison showed a consistent pattern: the monolith is cheap and simple at first and gets complicated as it grows, whereas microservices pay a high initial cost in exchange for keeping the complexity of each piece bounded and enabling independent deployments, scaling and teams. Walking through the "discount coupons" change made tangible where the difficulties appear in each case: at the end of the cycle in the monolith, at the beginning in microservices. And we made it clear that the monolith is not a second-class architecture: it is the right choice for many systems.

With this comparison in hand, we can now tackle the question that really matters in practice: when should you adopt microservices and when should you not? The next lesson gives concrete criteria, warning signs, prerequisites and a checklist for making that decision on solid ground.