Monolithic Architecture

Microservices get all the press. Every conference talk, every engineering blog post, every architecture diagram from Netflix or Uber shows dozens of interconnected services. It's easy to walk away thinking monoliths are legacy mistakes that serious engineers have moved past.

That's wrong. A monolith is a legitimate architectural choice, and for many teams and many products, it's the correct one. Knowing when to use a monolith, and when to break it apart, is one of the most practical skills in system design.

What Is a Monolith?

A monolith is an application where all components are deployed as a single unit. Your user authentication, your product catalog, your payment processing, your email notifications — they all live in the same codebase and get deployed together.

When you deploy, you deploy the whole thing. When you scale, you scale the whole thing. When you restart, everything restarts.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

A monolith deploys all features as one unit. Every component, auth, catalog, payments, and notifications, lives in the same process and shares one database. Deploying means deploying the whole thing.

1 / 10.5×1×2×3×Playground

A monolith deploys as a single unit. All features share one process and one database.

This sounds limiting. But consider what it gives you:

• One deployment — push the artifact to a server and you're done
• In-process communication — functions calling functions, not HTTP calls across a network
• Simple transactions — one database, ACID guarantees, no distributed transaction complexity
• Easy debugging — one log stream, one stack trace, all the context in one place
• Simple testing — spin up the whole app, test the whole flow end-to-end

The Advantages Are Real

Simple to Develop at Small Scale

When your team is 3-10 engineers, a monolith means everyone works in the same codebase. No service ownership debates. No API contracts to maintain between teams. No latency introduced by network calls between services. You just write code and it works together.

Shopify ran as a monolith for years while it scaled to billions in GMV. Stack Overflow is famously a monolith handling millions of requests per day from a small team. Basecamp, GitHub (until very recently), and many other successful products ran monoliths at significant scale.

Straightforward Testing

Integration testing a monolith means spinning up one process. Testing a microservices system means spinning up a dozen services (or mocking them, which introduces its own bugs). The test suite is simpler, faster to run, and easier to reason about.

Operational Simplicity

Monitoring a monolith is simple: one service, one set of metrics, one log file. Correlating a request through five microservices requires distributed tracing infrastructure. For a small team, the operational overhead of microservices is a significant tax.

The Disadvantages Surface with Scale

Scaling Bottlenecks

A monolith scales as a unit. If your image processing component uses 10× more CPU than everything else, you still have to scale the entire application to get more image processing capacity. You can't scale just the hot component.

In practice, this often means over-provisioning — running a lot of expensive instances so the whole app has enough capacity for the most demanding component.

Deployment Risk

Every deploy touches the whole application. A bug in the new payments code can take down the entire site — including the unrelated search feature. As the codebase grows, the risk of any given deploy affecting something unexpected grows with it.

At large teams, this creates deployment congestion: multiple teams trying to ship features but having to coordinate because they all share one deploy pipeline. Waiting for another team's risky migration before you can ship your safe bug fix is a real productivity killer.

Team Coupling

As the monolith grows, teams start stepping on each other's code. A "shared utilities" module becomes a minefield of undocumented dependencies. Changing a data model requires coordinating with every team that touches that table. Merge conflicts multiply. Development slows down even if the product isn't doing that much more work.

This is sometimes called the "Big Ball of Mud" — technically a monolith, but so entangled that no one can confidently change anything without fear of breaking something else.

The Modular Monolith: The Sweet Spot

Here's what many teams miss: the alternative to a tangled monolith isn't microservices — it's a modular monolith.

A modular monolith organizes the codebase into well-defined modules with explicit interfaces between them. The payments module exposes a chargeCard() function. The notifications module exposes a sendEmail() function. Each module owns its data — other modules don't query the payments tables directly.

The modules are enforced by code conventions, package boundaries, or tooling (like Nx workspaces or Java modules). The key is that the interfaces between modules are explicit and stable, even though the deployment is still a single artifact.

This gives you most of the organizational benefits of microservices (team ownership, clear boundaries, decoupled data models) without the operational complexity (network calls, distributed tracing, service discovery, independent deployments).

A modular monolith is not a compromise. For many organizations, it's the right target architecture. You get the development velocity of a monolith with the internal structure that prevents it from becoming a Big Ball of Mud.

When to Stay Monolithic

Stay with a monolith (or modular monolith) when:

• Your team is small — fewer than ~50 engineers. The overhead of microservices coordination exceeds the benefits.
• Your product is evolving fast — breaking a monolith into services requires stable domain boundaries. If you're still figuring out what your product is, premature service extraction will hurt you.
• You don't have clear scaling bottlenecks — if the whole app fits on a few servers comfortably, there's no scaling problem to solve.
• Your team lacks distributed systems expertise — microservices introduce distributed transactions, network failures, service discovery, and distributed tracing. These are hard problems that require experienced engineers to handle well.

When to Break It Up

Start extracting services when:

• A specific component has wildly different scaling requirements — your video transcoding service needs 100× more compute than your user profile service.
• Different components need different technology stacks — ML model serving in Python, real-time features in Go, core business logic in Java.
• Team topology demands it — you have 10+ teams shipping features, and the monolith is causing deployment bottlenecks and merge conflicts that slow everyone down.
• Reliability isolation matters — a bug in your recommendation engine shouldn't take down your payment processing.

Even then: extract one service at a time, not all of them at once. Start with the highest-value extraction (the component with the most different characteristics), prove out the operational model, then continue.

Summary

A monolith isn't a failure mode. It's a default architecture that works extremely well at small to medium scale. The real choice is between a well-structured modular monolith and a distributed microservices system. The modular monolith is the right default for most teams: it has clear internal boundaries, is operationally simple, and can be decomposed later when you actually have the scaling and team-topology problems that microservices solve. Don't break it up before you need to. When you do need to, break it up incrementally, one service at a time, starting with the component that has the strongest case for independence.