Monolith or Microservices? How to Answer Without Sounding Like a Conference Talk

“Would you build this as a monolith or as microservices?” is one of the most common architecture interview questions, and one of the easiest to answer badly. It is easy to answer badly because everyone has an opinion, and an opinion is exactly what the interviewer does not want. They want to see you reason.

By the end of this post you will have a way to structure the answer that demonstrates judgment instead of allegiance, and you will know the follow-ups that are coming.

The Question

The direct forms:

• “Would you build this as a monolith or microservices, and why?”
• “When would you break a monolith into services?”
• “The team wants to move to microservices. What do you say?”

The indirect forms are more common at the senior level. You are given a system design prompt, you sketch a handful of boxes, and the interviewer asks “are these separate services?” That is the same question in disguise.

What They Are Really Asking

The interviewer is probing three things:

1. Do you understand that this is an organizational decision as much as a technical one? Service boundaries are team boundaries. If you never mention the team, you have missed half the problem.
2. Can you name the costs of both options honestly? A candidate who only lists the costs of monoliths is a microservices enthusiast. A candidate who only lists the costs of microservices is reacting to a bad experience. An architect lists both.
3. Do you know what the decision depends on? The strong answer is not “monolith” or “microservices.” It is “here is what I would need to know, and here is how each answer changes my recommendation.”

A weak answer reveals that you have a default architecture you apply regardless of context. That is the single most disqualifying trait in an architecture interview.

The Gotchas

Gotcha 1: Answering in the first ten seconds. The question is a prompt to ask clarifying questions. How big is the team? How many teams? What is the deployment cadence today? Is there a scaling hot spot, or is the whole system scaling uniformly? Answering before asking signals that you would make the same mistake on the job.

Gotcha 2: Treating “microservices” as the grown-up option. Interviewers who have run microservices in production know what they cost: distributed transactions, network partitions, observability across dozens of services, version skew between callers and callees, and the on-call burden. If you present microservices as obviously more mature, an experienced interviewer will start drilling into those costs until you run out of answers.

Gotcha 3: Ignoring the modular monolith. The question is framed as binary, but the most defensible starting point for most new systems is a single deployable with strictly enforced module boundaries. If you do not bring this up, you leave the best answer on the table.

Gotcha 4: Confusing scaling the code with scaling the team. “We need microservices to scale” is ambiguous. Scale what? A monolith can scale horizontally behind a load balancer just fine. The thing microservices actually scale is the number of teams that can deploy independently. Say that explicitly.

Gotcha 5: Forgetting the data. Splitting the code is easy. Splitting the database is where migrations die. A service that shares a database with another service is not really a separate service. If your answer does not mention data ownership, it is incomplete.

Gotcha 6: Not mentioning Conway’s Law. Conway’s Law says that systems mirror the communication structure of the organizations that build them. Every experienced interviewer is thinking about it. Name it, and say what it implies: you cannot draw service boundaries that do not match team boundaries and expect them to hold.

How to Answer

Step 1: Ask the questions that change the answer

Ask these out loud, in roughly this order:

Question	Why it matters
How many engineers, and how many teams?	Under roughly two teams, service boundaries mostly add overhead
How often do you need to deploy, and does one team’s release block another’s?	Independent deployability is the primary benefit of services
Is there a specific component with different scaling, language, or compliance needs?	A real reason to extract one thing is not a reason to extract everything
What is the current operational maturity? CI/CD, observability, on-call?	Microservices multiply operational load. Without the platform, they fail
Is the domain well understood, or still being discovered?	You cannot draw good boundaries around a domain you do not yet understand

The interviewer may say “assume a small startup” or “assume a 200-engineer org.” Either way, you now have the constraints you need.

Step 2: State the framework

Say something like this:

I think of this as a spectrum, not a binary. On one end is a single deployable with no internal structure. On the other is a fleet of independently deployed services with their own data stores. In between is a modular monolith: one deployable, but with enforced boundaries between modules that could become services later. My default for a new system is the modular monolith, and I extract services when a specific module has a specific reason to be separate.

flowchart LR
    A[Big ball of mud] --> B[Modular monolith]
    B --> C[Monolith + a few extracted services]
    C --> D[Microservices]
    style B fill:#2d6a4f,color:#fff

Then name the trade-offs on each end.

	Monolith	Microservices
Deployment	One artifact, one pipeline, coordinated releases	Independent deploys per service
Data	One database, transactions are easy	Data ownership per service, eventual consistency, sagas
Debugging	Stack traces and a debugger	Distributed tracing, correlation IDs, log aggregation
Failure modes	Process crashes, whole app down	Partial failures, cascading timeouts, retries and backpressure
Team scaling	Merge conflicts and release coordination grow with team size	Teams own services end to end
Operational cost	Low. One thing to run	High. Service mesh, discovery, per-service on-call
Refactoring	Cheap. Move code across module boundaries	Expensive. Cross-service changes need API versioning

Step 3: Give a recommendation and defend it

Now answer. Tie the recommendation to the constraints you gathered:

• Small team, new domain: modular monolith. Enforce module boundaries with tooling (package visibility, architecture tests, separate schemas within one database). Extract the first service only when a module has a clear, measurable reason.
• Several teams, mature domain, painful shared releases: extract services along team boundaries, starting with the module that is most independent in data terms. Do it one service at a time using the strangler fig pattern, and keep the monolith as the system of record until each extracted service owns its data.
• One hot component with different scaling or compliance needs: extract that one thing. Do not let one real need justify a fleet.

Say what would change your mind. “If the team told me they already run a strong platform with tracing, service templates, and per-team on-call, I would lean further toward services because the marginal cost of each one is much lower.”

Step 4: Mention the data migration explicitly

Close by acknowledging the hard part. Something like:

The code split is the easy half. The real migration is data ownership. I would start by identifying which tables belong to which module, stop cross-module joins inside the monolith first, and only then extract the service. Until a service owns its data, it is a deployment unit, not a bounded context.

That sentence alone separates you from most candidates.

Follow-Up Questions to Expect

• “How do you handle a transaction that spans two services?” Sagas with compensating actions, or redesign the boundary so the transaction does not span services. Say that the second option is usually better.
• “How do you prevent a modular monolith from turning into a big ball of mud?” Enforced boundaries: architecture tests, package visibility rules, separate schemas, code ownership per module.
• “What is the first service you would extract?” The one with the most independent data and the clearest owner, not the one that is most annoying.
• “How do you know when it is time to split?” Name concrete signals: release coordination consuming real calendar time, teams blocked on each other’s merges, a component with a different scaling profile.
• “What about serverless?” It is a deployment model, not a boundary decision. The boundary question is the same.
• “Have you seen this go wrong?” Have a real story ready, and make sure it includes what you would do differently.

Key Takeaways

• The question is a test of judgment, not allegiance. Never answer in the first ten seconds.
• Ask about team size, deployment cadence, operational maturity, and domain clarity before recommending anything.
• Present it as a spectrum and default to the modular monolith for new systems.
• Microservices scale teams and deployment independence. They do not inherently scale throughput.
• Data ownership is the hard part. A service sharing a database is not a separate service.
• Name Conway’s Law and what it implies for boundaries.
• Say what would change your mind. That is what makes it sound like an architect.

Further Reading

• Sam Newman, Monolith to Microservices
• Martin Fowler, MonolithFirst
• Martin Fowler, Strangler Fig Application
• Melvin Conway, How Do Committees Invent?