Monolith vs Microservices

Monolith means one deployable. Microservices means many small deployables. Both are valid choices. The right answer depends on team size, scaling needs, and operational maturity, not on what is fashionable.

The two extremes

A monolith is one application. One codebase, one process, one deploy. Everything talks to everything via function calls. The classic Rails app, the classic Django app, most early-stage products.

Microservices is the opposite: many small services, each with its own codebase, database, and deploy. They talk over the network. Each service owns one business capability.

The world fell in love with microservices around 2014 because Netflix and Amazon evangelized them. Then half the teams that adopted them quietly went back to monoliths. The truth is in the middle.

What monoliths give you

• Simple deploys. One artifact. One pipeline. One thing to monitor.
• Easy refactoring. The compiler or IDE can rename across the whole codebase.
• Strong consistency. One database, one transaction.
• Fast local development. Run it once, see everything.

What monoliths cost you (eventually)

• One slow team blocks all teams. Every change goes through the same deploy.
• Scaling is all-or-nothing. Need more capacity for one feature? You scale the whole thing.
• One bug can take down everything. A memory leak in some forgotten cron job kills the API.
• Tech stack lock-in. Whatever you started with, you live with for a long time.

What microservices give you

• Independent deploys. Teams ship on their own cadence.
• Targeted scaling. The video service can run on 100 boxes; the auth service on 5.
• Tech freedom. Each service picks its language and database.
• Failure isolation. One service down doesn't take everything else.

What microservices cost you

• Massive operational burden. 50 services means 50 deploys, 50 dashboards, 50 on-call rotations.
• Distributed systems problems everywhere. Network failures, eventual consistency, partial deploys.
• Cross-service refactoring is hard. Renaming a field touches multiple repos and APIs.
• Debugging requires tracing. A single user request goes through 8 services.

The senior decision framework

Choose monolith if:

• The team is under 20 engineers.
• The product is not yet scaled (sub-million users).
• You don't yet have CI/CD, observability, container orchestration nailed.
• The domain is not well understood. Microservices boundaries are very expensive to redraw.

Choose microservices if:

• You have multiple teams that want independent deploy cycles.
• Different parts of the system have wildly different scaling needs.
• The domain is mature with clear, stable boundaries.
• You have the operational maturity (Kubernetes, observability, on-call).

Migration paths

The path most companies actually take: start with a monolith. Once one part of it has different scaling, ownership, or release cadence needs, extract just that part as a service. Repeat as needed. Don't try to "go microservices" in one big rewrite. That's the move that ends careers.