Microservices became the dominant architectural pattern in software discussions around 2015, carried largely by the public case studies from Netflix, Amazon, and Uber. What those case studies rarely communicated clearly is that each of those companies adopted microservices as a solution to specific scaling problems that they encountered after years of operating at enormous scale - not as a starting point.

The result was a generation of engineering teams building microservices architectures before they had the operational maturity, team size, or actual scaling requirements to justify them. The costs were real: distributed system complexity, network latency between services, versioning problems, and infrastructure overhead that dwarfs what a small team can manage responsibly.

This article is not anti-microservices. At the right scale and with the right team, they solve genuine problems. It is an argument for honestly assessing whether those problems are yours.

What a monolith actually is (and is not)

A monolith is a software architecture where all components - the UI, application logic, and data access layer - are part of a single deployable unit. The word has acquired a pejorative connotation in engineering culture that it does not deserve. A well-structured monolith can be clean, testable, and scalable well beyond what most businesses will ever require.

The monolith's advantages are substantial: simpler deployment (one artifact to build and ship), easier debugging (the call stack is local), straightforward transactions (no distributed transaction coordination), and no network latency between internal function calls. For a team of under fifty engineers, a modular monolith is almost always the correct architecture.

When microservices actually earn their complexity

Microservices are the right architectural choice when specific services within your system have genuinely different scaling requirements, when independent deployment of individual components is a competitive requirement, or when your organisation has grown to the point where multiple teams can own services without coordination overhead destroying velocity.

The classic case is a system where the video processing component must scale independently of the authentication component, which must scale independently of the billing component. At sufficient scale, coupling those services in a monolith creates deployment risk and resource inefficiency. At that scale, microservices solve a real problem. The question is whether you are at that scale or whether you are anticipating it too early.

The operational cost of microservices is not theoretical. Service discovery, distributed tracing, inter-service authentication, container orchestration (typically Kubernetes), and the engineering culture required to own independent services - these require meaningful infrastructure investment and operational maturity. For a custom software project at early stage, that investment is almost never justified.

The middle path: the modular monolith

The architecture that most teams should start with is the modular monolith: a single deployable unit internally organised into clearly bounded modules with defined interfaces between them. This gives you the operational simplicity of a monolith while preserving the option to extract individual modules into services later, when the actual scaling problem presents itself.

Companies like Shopify and Stack Overflow operated on modular monoliths at enormous scale and found them entirely sufficient. The decision to extract services came from specific, identified bottlenecks - not from a desire to adopt the pattern.

The honest verdict

Start with a modular monolith. Extract services when you have a specific, identified reason to - not because the architecture is fashionable or because a VC asked about it in a pitch meeting.

Choose a monolith if: your team is under 20 engineers, you are pre-Series B, you have not yet identified components with genuinely divergent scaling requirements, or your deployment complexity budget is limited. This applies to nearly every startup and many growth-stage companies.

Choose microservices if: you have specific services with genuinely divergent traffic patterns, your organisation has enough engineers to own individual services end-to-end, and your infrastructure team has the maturity to manage Kubernetes or equivalent at scale. TTGC architects software for the stage your business is actually at - start the conversation here.