Tech Terms Explained Open in the app →

Monolith

Architecture · Beginner · 4 min read

What is it?

A monolith is an application built and deployed as a single unified unit, where all the features live in one codebase.

Explain like I'm 5

A monolith is like one big house where the kitchen, bedrooms, and garage are all under a single roof — simple to build, but you renovate the whole house at once.

Why was it created?

It's the natural, simplest way to build software: put everything in one place. Monoliths predate microservices and remain a sensible default.

Where is it used?

  • Early-stage products
  • Small to mid-size teams
  • Apps that don't need independent scaling
  • Most startups initially

Why should developers care?

Most applications start as monoliths, and many stay that way successfully, so understanding the trade-offs guides real architecture decisions.

How does it work?

All modules — UI, business logic, data access — are part of one program, compiled or deployed together. Internal calls are simple function calls rather than network requests.

Real-world example

A startup ships its whole web app as one deployable service; adding a feature means editing one codebase and deploying it together.

Common use cases

  • Getting a product to market fast
  • Small teams
  • Simpler operations
  • Apps with uniform scaling needs

Advantages

  • Simple to build and deploy
  • Easy local development and testing
  • Fast internal calls
  • Less operational overhead

Disadvantages

  • Harder to scale parts independently
  • One bug can affect everything
  • Large codebases slow teams over time
  • Whole app redeploys for any change

When should you use it?

For most new or small-to-mid projects where simplicity beats independent scaling.

When should you avoid it?

When the app and teams grow large enough that independent deployment and scaling become essential.

Alternatives

MicroservicesModular monolithService-oriented architecture

Related terms

MicroservicesHorizontal ScalingService Mesh

Interview questions

Beginner

  • What is a monolith?
  • How does it differ from microservices?

Intermediate

  • What are the trade-offs of a monolith?
  • What is a modular monolith?

Senior

  • When would you split a monolith into services?
  • How do you keep a growing monolith maintainable?

Common misconceptions

  • "Monoliths are always bad" — they're often the right, simpler choice, especially early on.
  • "You must start with microservices to scale" — many successful systems start monolithic and split only when needed.

Fun facts

  • A 'modular monolith' keeps clean internal boundaries while staying a single deployable.
  • Many companies that famously use microservices started as monoliths.

Timeline

  • 2010s — Term gains contrast as microservices rise

Learning resources

Quick summary

A monolith is an app built and deployed as one unit — simple and fast to start, but harder to scale and change in parts as it grows.

Cheat sheet

  • Single deployable unit
  • One codebase, simple to start
  • Fast internal calls
  • Harder to scale parts independently

If you remember only one thing

A monolith keeps everything in one deployable unit — simpler to start, and often the right first choice.