Microservices vs Monolithic Architecture

One of the most debated trade-offs in system design — and one where a nuanced answer beats a strong opinion.

The Case for a Monolith

A single deployable codebase is simpler to develop, test, and deploy, especially for small teams or early-stage products. There's no network latency between components, and transactions across the whole system are trivially consistent.

The Case for Microservices

Independently deployable services let large teams work in parallel without stepping on each other, and let you scale only the components that need it. The cost is real: network calls replace function calls, distributed tracing becomes necessary, and cross-service consistency gets hard.

The Interview-Ready Answer

"Start with a monolith, extract services when a specific bottleneck or team-scaling need justifies the operational cost" is a defensible, senior-sounding default — far better than assuming microservices are always the goal.

Service Boundaries Matter More Than Service Count

Poorly drawn service boundaries create a "distributed monolith" — all the network overhead of microservices with none of the independence benefit, because every service still needs to change together. Draw boundaries around business capabilities, not technical layers.

A useful test for a good boundary: could this service's team ship a change on their own, without coordinating a simultaneous deploy with another team? If the answer is consistently no, the boundary is probably drawn along the wrong lines — often around technical layers ("the database service," "the validation service") instead of business capabilities ("payments," "referral matching").

The Hidden Cost: Operations

Every additional service is another thing to deploy, monitor, and debug. Mentioning observability — centralized logging, distributed tracing, service health dashboards — signals you understand microservices as an operational commitment, not just an architecture diagram.

A Middle Ground: The Modular Monolith

Many teams land between the two extremes: a single deployable service internally organized into clearly separated modules with well-defined interfaces, deliberately structured so it could be split into microservices later without a rewrite. Bringing this up shows you're not thinking in binary terms — it's often the pragmatic answer for a team that isn't yet large enough to justify full microservices.