Before comparing anything, each term needs its own clean definition. Mixing them up is the single most common mistake people make when this topic comes up in a design discussion or an interview.

What is a Monolith?

A monolith is a way of building the runtime architecture of an application. It means the entire application — the user interface logic, the business rules, the database access, the payment processing, the notification sending — is built, packaged, and deployed as a single unit. When you start the application, one process starts, and that one process does everything. There is no “billing service” running separately from the “user service.” It is all one program, compiled or bundled together, running on one set of servers (though those servers can be scaled to many copies of the same single program).

Think of a monolith like a Swiss Army knife. It is one physical object. The scissors, the knife blade, the bottle opener, and the toothpick are all folded into a single handle. You cannot use just the scissors without carrying the whole tool. If the hinge breaks, every single tool on it becomes harder to use, because they are all physically connected.

What is a Monorepo?

A monorepo is a way of organizing source code storage, not a way of running an application. It means multiple projects — which could be a website, a mobile app, a backend service, and a shared design-system library — all live inside a single version control repository (like one giant Git repository), instead of each project having its own separate repository. Crucially, the projects inside a monorepo do not have to be a single running program. They can be five completely independent applications that are deployed separately, tested separately, and owned by five different teams. The only thing that is “mono” (meaning “one”) is the folder that holds all the source code.

A good analogy is a shared filing cabinet in an office. One filing cabinet (the monorepo) can hold folders for Marketing, Legal, Engineering, and Finance. Each folder is a completely separate department with separate work, separate people, and separate purposes. They just happen to be stored in the same piece of furniture so that anyone can quickly walk over and grab a document from any department without requesting a new cabinet.

What is a Micro-Frontend?

A micro-frontend is a way of building the user interface of a web application by splitting it into smaller, independently built and independently deployed pieces, which are then stitched together in the browser (or on a server) to look like one seamless website to the end user. For example, the header/navigation bar might be built and deployed by Team A, the product search page by Team B, the checkout flow by Team C, and the “My Account” section by Team D — each with its own codebase, its own release schedule, and sometimes even its own frontend framework — yet the customer sees a single, unified website.

Picture a shopping mall. Each store (Nike, Starbucks, the movie theater) is built, staffed, stocked, and renovated completely independently by different companies. Starbucks does not need permission from Nike to change its menu. Yet when a shopper walks through the mall, it feels like one connected experience, with shared hallways, shared parking, and shared signage tying it together.

Because these three ideas sit on completely different axes, they can be combined freely. A company can run a monolith whose entire source code lives in a monorepo. A company can run twelve microservices whose code is split across twelve separate repositories (a “polyrepo”), or all twelve stored in a single monorepo. A company can build a micro-frontend UI that talks to a backend monolith, or a micro-frontend UI that talks to dozens of microservices. There is no rule that forces these choices to travel together, even though people often assume “modern” architecture means picking the split option for all three at once.

Definitions are only useful once you can picture what actually happens when the system runs, builds, and deploys. This chapter opens the hood on all three.

How a Monolith Works Internally

Inside a monolith, all the different pieces of business logic — say, “user accounts,” “shopping cart,” and “order processing” — exist as different modules, classes, or folders inside the same codebase. But because they are compiled or bundled into a single artifact (a single executable file, a single container image, or a single deployable package), they share the same memory space at runtime. When the “shopping cart” module needs to check if a user is logged in, it does not send a network request across the internet to a separate “user service” — it simply calls a function directly, in-process, which is extremely fast because there is no network hop involved.

This single artifact is typically deployed to a fleet of identical servers behind a load balancer. Every server runs the exact same copy of the entire application. If the “shopping cart” logic gets slow under heavy traffic, the only way to give it more resources is to add more copies of the entire monolith, even though the “user accounts” logic that is bundled with it did not need any extra capacity at all. This is one of the defining internal characteristics of a monolith: scaling is done for the whole application, not for one piece of it.

How a Monorepo Works Internally

Internally, a monorepo relies heavily on tooling that most single-project repositories do not need. Because dozens or hundreds of projects share one repository, specialized build systems (such as Bazel, Nx, or Turborepo) are used to figure out exactly which projects were affected by a given code change, so that the system does not waste time rebuilding and retesting every single project every time anyone changes one line of code. This is called “affected graph” analysis — the tool builds a dependency graph of which project depends on which other project, and when a file changes, it walks that graph to find every project that needs to be rebuilt.

A monorepo also typically uses build caching, where the output of a build step is saved and reused if the same inputs are seen again, sometimes even shared across different developers’ machines through a remote cache. Access control inside a monorepo is usually handled with “code ownership” files that specify which team must approve changes to which folder, since without this, anyone could accidentally (or carelessly) edit code belonging to a completely different team.

How a Micro-Frontend Works Internally

A micro-frontend system needs a “shell” or “container” application — a lightweight piece of code whose only job is to decide which micro-frontend to load for a given URL or page section, fetch it, and mount it into the page. There are a few common internal techniques for this: build-time integration (each micro-frontend is published as a package and combined into one build before deployment), run-time integration via JavaScript (the shell dynamically downloads separate JavaScript bundles in the browser and renders them, often using a technique called Module Federation), run-time integration via iframes (each micro-frontend runs inside its own isolated iframe), and server-side composition (a server assembles HTML fragments from different backend services before sending the final page to the browser, sometimes called “edge-side includes”).

Whichever technique is used, the shell also needs a strategy for shared concerns: how do micro-frontends avoid loading five separate copies of the same UI framework, how do they navigate between each other without a full page reload, and how do they communicate (for example, telling the “cart icon” micro-frontend in the header to update its count after the “checkout” micro-frontend completes a purchase)? These problems are usually solved with a shared event bus, shared browser storage, or a common design-system library that every micro-frontend imports.

graph TB
    subgraph Monolith["Monolith Runtime"]
        LB1[Load Balancer] --> A1[App Instance 1]
        LB1 --> A2[App Instance 2]
        A1 --> M1[User Module]
        A1 --> M2[Cart Module]
        A1 --> M3[Order Module]
        M1  M2
        M2  M3
        A1 --> DB1[(Single Database)]
    end
        

graph LR
    subgraph Repo["Monorepo (Single Git Repository)"]
        direction TB
        P1[Project: Web App]
        P2[Project: Mobile App]
        P3[Project: Backend API]
        P4[Project: Shared UI Library]
        P4 --> P1
        P4 --> P2
        P3 -.independent deploy.-> Prod1[Production]
        P1 -.independent deploy.-> Prod2[Production]
    end
        

graph TB
    User[Browser] --> Shell[Shell / Container App]
    Shell --> MF1[Micro-Frontend: Header]
    Shell --> MF2[Micro-Frontend: Product Search]
    Shell --> MF3[Micro-Frontend: Checkout]
    MF1 -.deployed by Team A.-> D1[Independent Pipeline]
    MF2 -.deployed by Team B.-> D2[Independent Pipeline]
    MF3 -.deployed by Team C.-> D3[Independent Pipeline]
        

Understanding what happens step by step — from a developer writing code to a user seeing a screen — makes the differences concrete.

Request Lifecycle in a Monolith

A user clicks “Buy Now.” The browser sends one HTTP request to the monolith’s server. The single application process receives it, routes it internally to the correct piece of code (no network call needed), that code checks the user’s identity, checks inventory, processes payment, updates the order table, and returns a response — all within one process, often within a single database transaction that can guarantee everything succeeds or fails together. This is a major internal advantage: a monolith can often wrap an entire business operation in one atomic transaction, because everything touches the same database connection.

Build and Deploy Lifecycle in a Monorepo

A developer changes a shared button component. They commit the change to the monorepo. The build system’s dependency graph identifies every project that imports that button — say, three different apps. The continuous integration pipeline automatically rebuilds and retests only those three apps (thanks to affected-graph analysis), skips the other ninety-seven untouched projects to save time, and if tests pass, each affected app can be deployed on its own independent schedule. Nothing here requires the three apps to be part of the same running program — the monorepo lifecycle is entirely about code storage, builds, and testing, not runtime behavior.

Page Load Lifecycle in a Micro-Frontend System

A user navigates to a webpage. The browser loads the lightweight shell application first. The shell looks at the URL, decides which micro-frontends are needed for this page, and fetches each one — possibly from completely different servers, built by completely different teams, on completely different release schedules. Each micro-frontend renders into its assigned slot on the page. If the user then clicks into the checkout section, the shell may fetch and mount an entirely different micro-frontend on the fly, without reloading the whole page. Throughout this, shared state (like “is the user logged in”) typically flows through a shared mechanism the shell provides, so the independently built pieces stay in sync.

Every one of these choices trades something away to gain something else. None of them is universally “better” — they are better for different situations.

Monolith Trade-offs

Monorepo Trade-offs

Micro-Frontend Trade-offs

Each architecture has well-known patterns that make it succeed, and well-known anti-patterns that quietly turn it into a maintenance nightmare.

Monolith Patterns

The modular monolith pattern keeps a single deployable unit but enforces strict internal boundaries between modules — for example, the “billing” module is not allowed to directly touch the “inventory” module’s database tables, and can only talk to it through a defined internal interface. This gives many of the organizational benefits of separated services while keeping the operational simplicity of one deployment. This pattern is often used as a deliberate stepping stone toward microservices later, if and when it becomes necessary.

Monorepo Patterns

The trunk-based development pattern is common in monorepos — everyone commits frequently to one main branch instead of maintaining many long-lived feature branches, which avoids painful merge conflicts across hundreds of projects. Pairing this with codeowners-based review routing (where the tool automatically assigns the right reviewers based on which folder changed) keeps a huge shared repository manageable.

Micro-Frontend Patterns

The vertical slice pattern assigns each team a complete business capability (for example, one team fully owns “search,” including its UI, its backend service, and its data) rather than splitting purely by UI component, which reduces the amount of cross-team coordination needed for any single feature. A shared design-system package is almost always used to keep buttons, colors, and typography consistent across independently built fragments.

Knowing the theory is one thing. Avoiding the mistakes real teams make in production is another.

A Practical Decision Checklist

These are not just textbook ideas — major companies have made deliberate, well-documented choices among them.