What You're Actually Choosing Between

A monolith is a single deployable unit. All your application code — user management, business logic, data access, API endpoints — lives in one codebase and deploys together. When you push a change, everything redeploys.

Microservices split the application into independently deployable services that communicate over a network (usually HTTP/REST or message queues). Each service has its own database, its own deployment pipeline, and its own team (in mature organizations).

There's also a useful middle ground: the modular monolith, where your code is organized into distinct modules with clear boundaries, but still deploys as a single unit. This gives you the internal structure of microservices without the operational overhead.

The Case for Starting With a Monolith

The canonical argument, from engineers who've built at scale at both startups and large companies: don't start with microservices.

Here's why:

You don't know your domain boundaries yet. Microservices require you to define the right boundaries between services. At the start of a product, you don't know what those boundaries are. You'll draw them wrong, and refactoring across service boundaries is far more expensive than refactoring within a monolith.

Distributed systems are hard. The moment services communicate over a network, you've introduced a new failure mode: network failures. Partial failures, timeouts, consistency issues across services, distributed tracing — these are real engineering challenges that consume significant time.

You're not Google. Microservices provide benefits at scale: independent scaling, independent deployment, team autonomy. A team of 4 engineers doesn't need team autonomy. You don't have independent scaling needs. The benefits don't apply.

Operational complexity is multiplied. Each service needs its own CI/CD pipeline, its own monitoring, its own logs, its own deployment configuration. For a startup trying to ship, this is engineering time that isn't building features.

When Microservices Start to Make Sense

Not "from the beginning" — but there are legitimate reasons to extract services over time:

A clear scaling boundary. If one specific piece of your system — say, your video processing pipeline, your AI inference endpoint, or your background job worker — needs to scale independently from the rest, extracting it as a service is justified.

Separate deployment cadences. If part of your system needs to deploy at a different frequency than the rest (a real-time notification service vs. a batch reporting system), service separation makes that clean.

Team size requires parallel workflows. When you have 4+ teams working on different domains, microservices allow each team to ship independently. A team of 3 engineers doesn't have this problem.

A third-party integration boundary. If you're exposing an API to external partners, a service that owns that API surface is a reasonable abstraction.

The Modular Monolith: Best of Both

The modular monolith is underappreciated. The idea: structure your codebase with clear module boundaries (separate directories, explicit interfaces, no cross-module direct database access) but keep it deployable as a single unit.

This gives you:

• Fast local development (one process to run)
• Simple deployment (one thing to deploy)
• Clean internal architecture (good boundaries prevent the "big ball of mud" that gives monoliths a bad reputation)
• Easy extraction to microservices later (the boundaries are already defined)

For most startups, this is the ideal architecture to aim for. It's the discipline of modular design without the operational overhead of distributed systems.

Practical Advice

If you're currently debating "monolith vs microservices" for your MVP: use a monolith. Organized as modules. Deploy it on a single server or serverless platform.

When you hit a legitimate scale or team problem that microservices solve — you'll know. It'll be a concrete problem ("our video processing is blocking API responses" or "Team A and Team B keep breaking each other's deployments") rather than a theoretical concern.

The companies that started with microservices and regret it are building products at scale. The companies that started with monoliths and extracted services as needed generally have cleaner systems with less technical debt.

Stack Overflow, GitHub, Shopify, and Basecamp are all running successful products on monolithic architectures at massive scale. The technology is not the bottleneck.