A practical decision guide on when microservices are justified versus when a modular monolith is the better choice, specifically for .NET teams. Microservices primarily solve organizational and scaling problems — not code quality issues — and are only worth the operational cost when multiple teams block each other on deploys, one component has wildly different scaling needs, or strict isolation requirements exist. The hidden costs include distributed data consistency (sagas), harder debugging requiring distributed tracing, complex local dev setups, and per-service CI/CD pipelines. For most teams, a modular monolith delivers clean internal boundaries with none of the network overhead, and keeps the option to extract services later. Real-world examples from Amazon Prime Video (90% cost reduction after consolidating to a monolith) and Segment's 'Goodbye Microservices' retrospective reinforce the case. A decision matrix maps team size and situation to the recommended architecture.
