Choosing Between Monoliths and Microservices

At Tutor Bright, Devraj Anand, the engineering lead, is evaluating a vendor’s recommendation to move to microservices. You are the junior cloud engineer. In this lesson, you will turn that proposal into evidence: identify what must change or scale independently, name the operational costs, and recommend a reversible next step.

In this lesson, you will learn to:

• Distinguish a modular monolith from a microservices architecture in terms of deployability and service boundaries
• Evaluate whether independent scaling, release cadence, fault isolation, or team ownership justify distributed-systems overhead
• Make a recommendation for Tutor Bright that names the evidence, trade-off, and trigger for revisiting it

Before anyone can debate this, you need a definition short enough that the non-technical people in the room stay with you. Here's the version to use: A modular monolith is a single deployable application whose components are normally developed and released together. A microservices architecture consists of independently deployable services organised around business capabilities.

In a modular monolith, enrolments, payments, scheduling, and reporting can share one codebase and deployment, so even a small reporting change is released with the application. In a microservices architecture, an enrolment service can be deployed independently. Shared contracts and dependencies can still require coordination.

Two consequences matter in the decision. Many monoliths are scaled by running more copies of the whole application, so a hotspot can add capacity to components that are not busy. Separating a consistently hot workload can allow it to scale independently, but only when that benefit offsets the added operational cost. A monolith can still use multiple processes and logs; it is often easier to trace a request because it crosses fewer service and network boundaries. In microservices, a request may cross several services, so correlation IDs (a shared label carried with one request), centralised logs, metrics, and distributed traces (a record of that request’s path across services) become important.

Devraj: The vendor said microservices would let us move faster. That sounds like what I want.

Nina: It might be. When your team ships a change, which part of the application is usually blocked waiting on another part?

Devraj: Honestly, nothing. There are four of us and we release together on Thursdays.

Nina: Then independent deployment is not solving a current release problem. A split would still add operational work immediately.

Devraj: What would make you change your mind?

Nina: I would look for sustained evidence that enrolment needs to scale independently, that it has a clear data and ownership boundary, and that the team can operate it separately. If that evidence appears, we can evaluate extracting it behind a stable interface; otherwise, keep the modular monolith.

Notice the move there. You didn't argue about architecture. You asked which benefit applied to this team, then named the trigger that would change the answer.