Monolith vs Microservices

Imagine you’re building an online store. Here’s the situation:

• At first it’s small, so all the code lives in one place: the part that shows pages, the part that takes orders, the part that handles payments, and the part that manages users.
• That works great for a while. But as the app grows, that one big bundle starts getting hard to handle.
• Someone tells you, “you should split this into microservices.” And you’re left wondering, what does that even mean, and should I?

This is one of the biggest decisions in how you build software. So let’s go through both choices, slowly and plainly, until you can pick the right one with confidence.

🎯 Why This Matters

Here’s the thing about this topic:

• “Monolith or microservices?” is a classic system design interview question, and it comes up in real engineering teams all the time.
• Interviewers aren’t testing whether you can recite definitions. They want to see if you understand the trade-offs, that’s the give-and-take where every choice has a cost.
• The wrong answer in real life can hurt. Picking microservices too early can sink a small team in extra work. Staying a monolith too long can slow down a huge company.

So the goal isn’t to memorize which one is “better.” There is no better. The goal is to know when each one fits. We’ll keep it beginner-correct: not dumbed down so it’s wrong, but not buried in jargon either.

🏬 Real-World Analogy

Think about two ways to run a business.

First, the all-in-one shop:

• It’s one big store where one team sells groceries, clothes, electronics, and food, all under one roof.
• It’s simple to run when you’re starting out. One building, one staff, one cash counter.
• But if the food section catches fire, the whole shop might have to shut for the day. And if you want more checkout counters just for groceries, you can’t add them without rebuilding part of the store.

Now picture a street of specialist shops:

• Instead of one giant store, you have a row of small shops. One sells only bread, one sells only shoes, one only phones.
• Each shop runs itself. It has its own staff, its own stock room, its own door.
• If the shoe shop closes for repairs, the bread shop keeps selling. And if the phone shop gets busy, it can hire more staff without bothering anyone else.

Keep these two pictures in your head. The all-in-one shop is a monolith. The street of specialist shops is microservices. Everything below maps back to this.

🧱 What is a Monolith

Let’s define it first. A monolith is when your whole application is built as one single unit, all the code together, deployed as one piece.

Here’s what that really means:

• All the features live in one codebase. The orders code, the payments code, the users code, the page-showing code, they all sit in the same project.
• It gets built and shipped as one thing. When you deploy, you deploy the whole app at once, not one feature at a time. (Deploying just means putting your code live so users can use it.)
• It usually talks to one shared database. A database is just an organized store of your data, like users and orders, and in a monolith one database holds it all.

So when a user places an order, the order code calls the payment code, which checks the user code, all inside the same running program. No network in between, just one function calling another. That’s fast and simple.

Here’s a monolith drawn out. Notice everything sits inside one box.

🧩 What are Microservices

Now the other side. Microservices means you split your app into small, independent services, where each service owns one job and runs on its own.

Let’s unpack that:

• Each service handles one area. So you’d have an orders service, a payments service, a users service, each as its own little app.
• Each one runs and ships on its own. You can update the payments service without touching the orders service at all. They deploy separately.
• Each service usually owns its own database. The orders service has its own data store, the users service has another. They don’t reach into each other’s data directly.
• They talk to each other over the network, using an API. An API is just an agreed way for one service to ask another for something, like the orders service calling the payments service over the network to charge a card.

So that same “place an order” action now crosses a network. The orders service sends a request to the payments service, waits for a reply, then talks to the users service. More moving parts, but each part is small and independent.

Here’s microservices drawn out. Notice the separate boxes, each with its own database, talking over a network.

⚖️ Monolith vs Microservices

Let’s put them side by side. This table is the quick mental cheat sheet, and it’s exactly the kind of comparison an interviewer loves.

Read that “scaling” row carefully, because it’s the one people quote most. Scaling means adding more power or copies to handle more users. In a monolith, if only payments is busy, you still have to copy the whole app to handle it. In microservices, you just add more copies of the payments service alone. That’s the headline win, and also the headline cost, because all that flexibility brings extra complexity.

✅ When a Monolith is the Right Call

For most projects, especially early on, a monolith is the smart choice. Here’s when it really shines:

• You have a small team. When a handful of people build everything, one shared codebase is easy to manage. Nobody’s coordinating across ten services.
• Your product is new. Early on you’re still figuring out what to build. A monolith lets you change things fast, because everything’s in one place.
• You want simplicity. No network calls between your own features, no juggling many databases, no complex setup. You ship and move on.
• Your scale is modest. If you’re not yet handling millions of users, you simply don’t need the heavy machinery of microservices.

A real example: a small startup building its first app. Maybe it’s a food-delivery MVP with a few thousand users. (MVP means Minimum Viable Product, the simplest version that does the job.) A clean monolith lets that team move quickly and not drown in setup. Most successful companies started as a monolith.

✅ When Microservices Make Sense

Microservices earn their cost once you hit a certain size. Here’s when they pay off:

• You’re a large organization with many teams. When dozens of teams work on the same product, splitting into services lets each team own its piece and ship without stepping on others.
• You need independent scaling. When one part of your app gets way more traffic than the rest, scaling just that part saves a lot of money and machines.
• You want failure isolation. When you can’t afford the whole app going down, separating services means one crashing part doesn’t sink everything.
• Different parts need different tools. One service might use one language or database that fits its job, while another uses something totally different.

A real example: think of Amazon or Netflix. Netflix runs hundreds of services, the part that handles login, the part that picks recommendations, the part that streams video, all separate. With millions of users worldwide and thousands of engineers, one giant monolith would be impossible to manage or scale. So microservices fit them perfectly. But remember, they moved there because they outgrew the monolith, not because they started that way.

⚠️ Common Mistakes and Misconceptions

A few ideas trip up almost everyone learning this. Let’s clear them out:

• “Microservices are always better.” No. They solve problems that big systems have. For a small app, they add cost and complexity you don’t need. The right choice depends on your situation.
• “You should start with microservices.” This bites a lot of small teams. Building ten services before you even know what your product is just slows you down. Start simple, split when the pain is real.
• “Microservices are basically free once you set them up.” Far from it. Now your own features talk over a network, which can be slow or fail. You have to keep data consistent across many databases, and you need extra tools to watch and run all those services. This whole world of network calls, ops, and data spread across services is called distributed-system complexity, and it’s the real price you pay.
• “More services means faster software.” Not automatically. Network calls between services are slower than a function call inside one program. Split badly and you can end up slower, not faster.

🛠️ Design Challenge

Try this one yourself to test your thinking.

Picture an app called QuickEats, a food-delivery service. It has four parts: a UI, an orders feature, a payments feature, and a restaurant-listings feature. Now answer these:

• If QuickEats is a 3-person startup with a thousand users, which architecture would you pick, and why?
• Now say QuickEats explodes to millions of users, and the payments part gets overloaded far more than the rest. What would you split out first, and why?
• Name one new problem you’d have to deal with the moment payments becomes its own service.

Walk through your reasoning out loud, the way you would in an interview. There’s no single right answer, but your reasoning about the trade-offs is exactly what gets you the job.

🧩 What You’ve Learned

You can now reason about one of the biggest architecture decisions in software. Here’s what you’ve picked up:

• ✅ A monolith is the whole app as one codebase, deployed as a single unit, simple to start and run.
• ✅ Microservices split the app into small independent services, each owning one job, often with its own database, talking over a network.
• ✅ The trade-off is simplicity versus flexibility: monoliths are easy but scale together, microservices scale independently but add complexity.
• ✅ Monoliths fit small teams and new products. Microservices fit large organizations with many teams and uneven scaling needs.
• ✅ The common advice is to start with a monolith and split into services only when you feel real pain.
• ✅ Microservices aren’t “better.” They bring distributed-system complexity, so you choose them when their benefits outweigh that cost.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   What best describes a monolith?

   Many small services that deploy on their own One codebase built and deployed as a single unit A system with no database A network of separate databases only
   Check

   Why: A monolith keeps all features in one codebase that is built and shipped together, usually with one shared database.

2. 2

   Why does each microservice usually own its own database?

   To save disk space Because databases cannot be shared technically So services stay truly independent and one team can change its store without breaking another To make data consistency easier
   Check

   Why: A database per service keeps services independent, though it makes keeping data consistent across them harder.

3. 3

   Which architecture is usually the right call for a small startup?

   Microservices, for the independent scaling A monolith, because it is simpler and faster to build Always whichever is newest It never matters
   Check

   Why: A monolith is simpler for a small team and product, and you can split into services later when you feel real pain.

4. 4

   What is the biggest downside of microservices?

   They can only use one language They cannot be scaled Distributed-system complexity from network calls, spread-out data, and extra tooling They always cost nothing to run
   Check

   Why: Services talk over a network that can fail, data spreads across many databases, and you need more tooling to run it all.

Score: 0 / 4 Reset

🚀 What’s Next?

Now that you know how an app can be structured, the next step is learning how to handle the traffic and data that flow through it.

• What is Load Balancing? shows how a system spreads traffic across many servers so no single one gets overwhelmed, which is key once you start scaling services.
• SQL vs NoSQL breaks down the two big families of databases, so you can pick the right store for each service.

Get these two down and you’ll have a solid grip on the building blocks every system design interview leans on.