Module
Module 3 of 6Lesson 1 of 2~17 min

Monolith, modular monolith or microservices

When the team proposes moving to microservices, a PM should be able to ask what the split really brings to the product. The lesson compares monolith, modular monolith and microservices in terms of deployment, operations and team structure, so you can judge a proposal against the problem it claims to solve.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to tell a monolith, a modular monolith and microservices apart, explain what each style costs and brings (deployment, coupling, operations, team organization), and judge whether a split addresses the problem at hand.

Topics covered

  • monolith vs microservices
  • modular monolith
  • Conway's law
  • service decomposition

Where it fits

Structuring the system

Should the system be split up, and when should you wait for a response rather than process later?

Lessons in this module

  1. Monolith, modular monolith or microservices (this lesson)
  2. Wait or process later, synchronous and asynchronous

What you will learn in the course

This lesson is part of the course Read and challenge a technical architecture

  • Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
  • Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
  • Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
  • Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
  • Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
  • Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
  • Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.

Related courses