# Monolith vs Microservices, Straight

There's a meeting you've probably sat in. Someone says "we should move to microservices," and the room nods, because microservices are what real companies do - and nobody wants to be the person defending the boring old monolith. A few quarters later, the same team is drowning in network timeouts, half-finished services, and a deploy process that needs a spreadsheet to coordinate.

This is the most over-argued choice in software architecture, and most of the arguing skips the part that matters: *what each one actually is*, and *what it actually costs you*. This guide walks both sides fairly - no slurs, no hype. By the end you'll be able to reason about the decision for your own team instead of copying someone else's blog post.

## How to read this
- **Already leaning one way and want the clear-eyed counter-case?** Skim [Phase 1](01-the-monolith.md) and [Phase 2](02-microservices.md) for the side you're *not* championing - that's where the surprises are.
- **Want it to finally make sense?** Read in order. Phase 1 builds the mental model of a monolith, Phase 2 builds microservices as a response to its limits, and Phase 3 gives you a way to actually choose.

## The phases
1. **[The Monolith](01-the-monolith.md)** - one deployable application: what it actually is, where it genuinely shines, and where it starts to strain.
2. **[Microservices](02-microservices.md)** - many small independently-deployed services: the strengths, and the costs people consistently underplay.
3. **[How to Actually Choose](03-how-to-actually-choose.md)** - judgment, flagged as judgment: how to read your team's real pain and decide, plus the two traps that catch everyone.

> This guide is about the *shape* of your system, not how to operate one once you've chosen. The deep mechanics of scaling a single service, and the messaging glue that holds services together, live in their own guides - linked at the end of each phase.