Microservices vs Monolith: Why You Should Probably Start With One Big App

The microservices vs monolith debate isn't binary. There are four real options: the classic monolith, the modular monolith (enforced boundaries, single deploy), true microservices (independent deployment and data ownership), and the distributed monolith antipattern where you get network complexity with none of the independence.

Splitting gives you deployment independence, fault isolation, and granular scaling. But the hidden costs are steep: network latency replacing function calls, no cross-service transactions, CI/CD pipeline explosion, distributed tracing overhead, and multiplied on-call surface. Conway's Law means your architecture will mirror your org structure whether you like it or not.

The practical answer: start with a modular monolith, watch for real signals (deployment bottlenecks, scaling mismatches, compliance needs), and extract one bounded context at a time using the strangler fig pattern. Shopify, Segment, and Fowler's MonolithFirst all back this approach.