Grokking Microservices for System Design Interviews

0% completed

​

What Monoliths Do Well

  1. The Definition
  1. What You Get for Free
  1. The Modular Monolith
  1. When the Monolith Is Simply the Right Answer
  1. In the Interview
  1. TL;DR

1. The Definition

When you build and deploy an application as a single unit, you have a monolith: one codebase, one build, one process (or many identical copies of it), and usually one database.

The word "monolith" has turned into an insult. That is a problem for interview candidates, because interviewers know it should not be.

Some of the largest, most reliable systems on the internet are monoliths. Stack Overflow served its entire global question-and-answer traffic for years from a compact monolithic application on a handful of servers. Shopify runs one of the world's largest e-commerce platforms on a Ruby on Rails monolith, on purpose, at a scale most microservices systems never reach. GitHub ran as a Rails monolith through most of its growth.

Treating "monolith" as a synonym for "legacy mess" is a red flag in interviews. The disorganized codebase where everything touches everything has its own name: a big ball of mud. That can happen in any architecture. A monolith is just a deployment decision: everything ships together.

2. What You Get for Free

The monolith's advantages are easy to underrate. They are invisible until you lose them.

  1. In-process calls. An in-process call is a normal function call inside one running program. It takes nanoseconds, cannot time out, and cannot half-succeed. There are no retries, no circuit breakers (safety switches that stop calls to a failing service), and no serialization (turning data into bytes to send over a network). An entire category of failure simply does not exist.
  2. One database, real transactions. Creating an order, charging a payment, and decrementing inventory (reducing the stock count) can be one ACID transaction. ACID means the database runs those steps as one all-or-nothing unit. Either everything happens or nothing does. In a microservices system, that same guarantee takes a saga: a chain of local transactions where every step has a compensating (undo) action. It also needs an outbox table (a database table that stores outgoing messages so none are lost) and careful idempotency work so retried requests do not run twice. In a monolith it takes BEGIN and COMMIT.
  3. One thing to debug. A stack trace shows the whole story. There is one log stream, one place to attach a profiler, and one version of the code running in production at a time.
  4. One thing to operate. One pipeline, one deployment, one set of dashboards, one on-call rotation. Studies of engineering time consistently find debugging and operations overhead materially higher in distributed architectures. One widely cited industry survey put the debugging-time difference around 35%.
  5. Cheap infrastructure. There is no cross-service network traffic. There is no per-service overhead of containers, sidecars (helper processes that run beside each service), gateways, and message brokers. Industry analyses put microservices infrastructure cost at 3 to 6 times a monolith's for equivalent functionality.

The transaction point is the one interviewers probe hardest. Here is the same business action in both worlds.

The same business action twice. The monolith gets all-or-nothing for free; the saga has to rebuild that guarantee by hand.
The same business action twice. The monolith gets all-or-nothing for free; the saga has to rebuild that guarantee by hand.

3. The Modular Monolith

The modern answer to "monolith or microservices?" is often "neither extreme." A modular monolith is a single deployment unit whose internals are organized into modules with enforced boundaries. Each module has a public interface, its own slice of the database schema, and no reach-ins from other modules. A reach-in is when one module's code calls another module's internals or reads its tables directly.

Enforcement can come from the language (visibility rules, separate packages), from tooling that fails the build on cross-module imports, or both.

Here is the point of that discipline. You get most of the code organization benefits of microservices (clear ownership, clean boundaries, testable modules) while keeping one deployment, one database, and in-process calls. Shopify is the famous practitioner. They call their approach "deliberate modularity" and have built tooling to enforce component boundaries inside the Rails codebase.

The three options on one line. The modular monolith keeps the monolith's single deployment and database while adopting the boundaries that make later extraction cheap.
The three options on one line. The modular monolith keeps the monolith's single deployment and database while adopting the boundaries that make later extraction cheap.

The modular monolith has one more property that matters strategically: it is the best launching pad for microservices you may extract later. Well-drawn module boundaries are exactly the service boundaries you would want. A module that already owns its own tables can be moved out with far less surgery.

This matters because boundaries are cheap to redraw inside one codebase and expensive to redraw across networked services. So discovering your boundaries inside a monolith first is the lower-risk order of operations.

💡 In any "monolith vs. microservices" interview exchange, naming the modular monolith as a third option, unprompted, is an immediate credibility gain. It shows you know the current state of the industry conversation, not the one from a decade ago.

4. When the Monolith Is Simply the Right Answer

  • Small team. Below roughly 20 to 50 engineers, coordination inside one codebase is rarely the bottleneck. The operational cost of many services lands on people who have no slack to absorb it.
  • Early product. Before product-market fit, the domain shifts constantly. Service boundaries drawn today will be wrong in six months. Wrong boundaries in a monolith are a refactor. Wrong boundaries in microservices are a distributed migration.
  • No operational maturity yet. Microservices assume automated deployment, centralized logging, distributed tracing (tooling that follows one request across many services), and on-call discipline. Adopting the architecture before that operational floor exists multiplies outages instead of containing them.
  • The load is uniform. If the whole system scales together, running more copies of the monolith behind a load balancer works fine. Independent scaling only pays off when one part's load is wildly different from the rest.

In an interview, you can walk these four checks as one decision flow.

Run the checks in order. Any exit to the monolith means splitting is not justified yet.
Run the checks in order. Any exit to the monolith means splitting is not justified yet.

5. In the Interview

This material usually arrives as "monolith vs. microservices: how do you choose?" or as a reaction to your design: "Why did you NOT split this into more services?"

The 30-second answer: "A monolith gives you things that are expensive to rebuild in a distributed system: real ACID transactions, in-process calls that cannot fail like network calls do, one debugging surface, and low operational cost. For a small team or an early product I would default to a modular monolith: single deployment, but with enforced module boundaries so the code stays organized and the boundaries are ready if we ever need to extract a service. I would move to microservices when there is evidence: teams blocking each other's releases, or one component with a wildly different scaling or reliability profile."

Likely follow-ups:

  1. "How do you keep a monolith from becoming a mess?" Enforced module boundaries: public interfaces between modules, no shared tables across modules, build tooling that fails on boundary violations, and code ownership per module. This is the discipline of microservices without the network.
  2. "Can a monolith really scale?" Horizontally, yes. Run many identical copies behind a load balancer, and scale the database with read replicas (copies of the database that serve reads) and caching. What it cannot do is scale one part independently; the whole unit scales together. That is the specific limitation to name, rather than a vague "monoliths don't scale."

A red flag that fails candidates: using "monolith" and "legacy" as synonyms, or presenting microservices as the mature endpoint every system should reach. Interviewers have watched the industry consolidate services back into monoliths. A survey by the Cloud Native Computing Foundation (CNCF), the group behind Kubernetes, found 42% of microservices adopters doing exactly that.

6. TL;DR

Monolith buys youACID transactions, in-process calls, one debug surface, one pipeline, 3 to 6x lower infra cost.
Modular monolithOne deployment unit, enforced internal boundaries; best of both for most teams; Shopify is the reference case.
Right answer whenSmall team, early product, uniform load, or operational maturity not there yet.
Real limitationEverything scales and ships together; no per-part independence.
Red flagTreating monolith as a synonym for legacy mess.
Flashcards Review

What is a monolith?

1 / 20
General
Test Your Knowledge
Check your understanding and reinforce the key concepts covered in this section with a short, targeted assessment.
10 Questions
~15 mins
Your progress is saved automatically
Mark as Completed

On This Page

  1. The Definition
  1. What You Get for Free
  1. The Modular Monolith
  1. When the Monolith Is Simply the Right Answer
  1. In the Interview
  1. TL;DR