Monolith vs Microservices

Microservices add network, deployment, and operational complexity. Monoliths have fewer moving parts. Pick based on team coordination pain, not headcount.

How It Works

Monoliths are single deployable units — all code, one binary, one deploy pipeline, one place to debug. Microservices are many smaller services communicating over the network — each team owns one service, independent deploys, different scaling profiles. Microservices look "more scalable" but the scaling is organizational (more teams shipping independently), not technical (a monolith can scale just fine). The hidden costs: service mesh, distributed tracing, network-level debugging, data consistency across service boundaries, deployment coordination for dependent services. Rule of thumb: monolith until you have 4–5 engineering teams that block each other on shared deploys. Microservices before that is architecture astronautics.

Real-World Example

Shopify famously ran a single Ruby on Rails monolith through 10+ billion dollars in GMV. They invested in modular boundaries within the monolith (clear API surfaces, internal "components") rather than splitting into microservices — which meant one deploy, one database, one place to debug. Etsy was similar. Compare to Amazon, which went from monolith to microservices precisely when their org structure outgrew shared-deploy coordination. The switch wasn't technical; it was "we have 1000 teams and need them to ship independently." The right time is determined by your org chart, not your performance graph.