Monolith Architecture

9 min read

Monolith Architecture

A single application where all components — frontend, backend, data access — live in one codebase and deploy as one unit.

What is it?

A monolith is the simplest way to structure a software application: everything in one place. One codebase contains all the code. One build process compiles it. One deployment puts it on a server. One database stores all the data. When a user’s request arrives, it’s handled entirely within this single application.

This is how most software starts, and for good reason. When a project is small — one developer or a small team, one product, straightforward requirements — a monolith is the fastest, simplest, and most productive architecture. There’s no network communication between services, no distributed systems complexity, no need to coordinate deployments across multiple applications.

The alternative — microservices — splits the application into many small, independent services that communicate over the network. Microservices solve real problems (independent scaling, independent deployment, technology diversity), but they introduce significant complexity. For most projects, especially early-stage ones, this complexity costs more than it’s worth.

The industry consensus in 2025-2026 is clear: start with a monolith. Split into services only when you have a concrete, measurable reason to do so. Many successful applications run as monoliths at scale — including large parts of Shopify, Stack Overflow, and Basecamp.

In plain terms

A monolith is like a single restaurant with one kitchen, one dining room, and one menu. Everything happens under one roof. The chef, the waiter, and the dishwasher are all in the same building. This is simple and efficient — the chef doesn’t need to phone another building to get ingredients. A franchise with separate kitchens in different cities (microservices) makes sense when you’re huge. For one location, one kitchen is all you need.

At a glance

How does it work?

A monolith has a straightforward internal structure. All the pieces live together, but they’re still organised logically.

1. One codebase

All the source code — frontend pages, backend logic, database access, configuration — lives in a single repository. When you open the project, you see everything. When you search for a function, you find it. When you trace a request from button click to database query, the entire path is in front of you.

Think of it like...

A single book with chapters. You can flip between chapters easily. The table of contents shows you where everything is. Compare this to a series of separate pamphlets stored in different drawers — you spend more time finding things than reading them.

2. One build, one deploy

You run one command to build the application. You run one command to deploy it. There’s no need to coordinate deployment order between services, no need to check that Service A deployed before Service B starts.

3. Internal communication

Components within a monolith communicate through function calls — the fastest, most reliable form of communication in software. When the frontend needs data, it calls a backend function directly. No network request, no serialisation, no latency, no failure modes beyond the code itself.

Communication typeSpeedReliabilityComplexity
Function call (monolith)NanosecondsExtremely highTrivial
HTTP request (microservices)MillisecondsNetwork-dependentSignificant

4. Logical separation within the monolith

A monolith doesn’t mean a tangled mess. Good monoliths are organised into modules or layers that have clear boundaries. The frontend code doesn’t directly access the database — it goes through the backend layer. The backend doesn’t render HTML — it returns data to the frontend layer.

The separation is logical (organised in code) rather than physical (running in different processes). This gives you the benefits of separation-of-concerns without the overhead of distributed systems.

Concept to explore

See modular-monolith for how to structure a monolith with clean module boundaries that could become services later if needed.

When to move beyond a monolith

A monolith is not forever — it’s a starting point. Move beyond it when you have concrete, measurable reasons:

TriggerWhat it meansSolution
Independent deploymentTwo teams need to ship at different speedsExtract the slower-changing part into a service
Independent scalingOne part of the app handles 100x more loadScale that part separately
Technology diversityA component needs a different programming languageIsolate it as a service
Team autonomyTeams of 8+ people stepping on each other’s codeDraw service boundaries along team boundaries

Don't split prematurely

“We might need to scale later” is not a reason to use microservices now. Premature splitting adds complexity, slows development, and often creates worse problems than it solves. Split when you have evidence, not speculation.

Why do we use it?

Key reasons

1. Simplicity. One codebase, one build, one deployment, one database. There’s nothing to coordinate, no network calls to fail, no distributed transactions to manage. This simplicity translates directly into faster development.

2. Easy debugging. When something breaks, the entire stack trace is in one application. You can step through the code from the user’s click to the database query without crossing process or network boundaries.

3. Fast local development. Run one command and the entire application starts on your machine. No need to spin up 5 services, 3 databases, and a message queue just to test a button.

4. Fast iteration. Change any code, see the result immediately. No waiting for service-to-service communication, no redeploying multiple services for one feature change. This speed compounds — faster iteration means faster learning means a better product.

When do we use it?

  • When starting a new project — almost always the right default
  • When working as a solo developer or small team (fewer than ~8 people)
  • When the application has straightforward scaling needs (one server can handle the load)
  • When you want the fastest possible development speed and simplest debugging
  • When building a walking-skeleton — the skeleton is naturally monolithic

Rule of thumb

Start with a monolith. Move away from it only when you feel specific, measurable pain that a monolith can’t solve. “Monolith first” is the near-universal expert recommendation.

How can I think about it?

The all-in-one workshop

A woodworker has a single workshop with all their tools: saws, drills, sandpaper, paint, workbenches. Everything is under one roof. They can walk from the saw to the drill in three steps. They can see all their projects at once. If they need a tool, it’s right there.

As the business grows and they hire people, they might split into a cutting shop and a finishing shop. But only when the single workshop gets genuinely crowded — not because they imagine they might be crowded someday.

  • One workshop = monolith (all code in one place)
  • Walking to the drill = function calls (fast, direct)
  • Separate shops = microservices (independent but harder to coordinate)
  • Sending materials between buildings = network requests (slower, can fail)
  • Splitting when crowded = extracting services when team or scale demands it

The Swiss Army knife

A Swiss Army knife puts multiple tools in one compact unit: blade, scissors, screwdriver, bottle opener. You carry one thing that does many things. It’s convenient, portable, and you always have what you need.

A toolbox with separate, specialised tools (a full-size knife, full-size scissors, a real screwdriver) is more powerful for each individual task. But you need a whole toolbox, and you need to find the right tool each time.

  • Swiss Army knife = monolith (all tools in one unit, good enough for most tasks)
  • Full toolbox = microservices (specialised tools, more overhead to manage)
  • Pocket-sized = easy to deploy and manage
  • Finding the right tool = service discovery and routing in microservices
  • Upgrade to the toolbox when the Swiss Army knife isn’t enough = split when you have a reason

Concepts to explore next

ConceptWhat it coversStatus
walking-skeletonThe first thin slice through a monolith’s architecturecomplete
vertical-slicesBuilding features end-to-end within the monolithcomplete
separation-of-concernsKeeping components logically separated even in one codebasestub
microservicesThe distributed alternative — and when it’s actually worth itstub
modular-monolithStructuring a monolith with clean boundaries for future splittingstub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    SA[Software Architecture] --> MA[Monolith Architecture]
    SA --> MS[Microservices]
    SA --> SC[Separation of Concerns]
    MA -.->|can evolve into| MM[Modular Monolith]
    MM -.->|can split into| MS
    style MA fill:#4a9ede,color:#fff

Related concepts:

  • walking-skeleton — the skeleton is naturally monolithic; all layers in one codebase
  • vertical-slices — features are built as vertical slices within the monolith
  • microservices — the alternative architecture; recommended only when monolith pain is concrete

Further reading

Resources

Graph View

Backlinks