Monolith vs microservices

Microservices · lesson 1 of 33 · 3 min read

Understand what actually changes when one deployable becomes many, and what it costs you.

Open this lesson in the learning hub

Key points

  • A monolith is one deployable. Microservices are many small deployables, each owning its own data and its own release schedule.
  • The win is independence. Teams ship on their own clock, and one hot service scales without scaling everything else.
  • The bill is the network. In-process calls that never failed become HTTP calls that time out, retry and arrive twice.
  • You also trade a compiler-checked method call for a versioned contract. Renaming a field across services is a migration, not a refactor.
  • Start with a well-structured modular monolith. Split later, when a module clearly wants its own scaling or release cadence.

Microservices buy independence and charge you in distributed-systems complexity.

Finding service boundaries

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Microservices course, and every lesson in it is listed on the Microservices contents page.