Microservices vs Monolith: When to Choose Which Architecture in Interviews

“Design a system for…” is on the whiteboard. You have 45 minutes. And the first decision you need to make is also the most important one: monolith or microservices?

Most candidates reach for microservices reflexively. They draw six services, a message queue, an API gateway, and spend half their time explaining the communication between components that would be better off in a single service. The interviewer makes a note: “Over-engineering. No justification for architecture choice.”

The problem is not a lack of knowledge about microservices. The problem is that most candidates never learned when which architecture is the right answer. In this guide, you will learn the decision criteria interviewers want to see, how to articulate trade-offs convincingly, and which mistakes cost you the round.

Why This Question Comes Up So Often in Interviews🔗

What Interviewers Actually Test🔗

The question “monolith or microservices?” is not a quiz. It is a proxy for three skills that matter in daily work: context awareness, trade-off thinking, and the ability to make decisions under uncertainty.

Interviewers want to see that you are not copying an architecture from a YouTube tutorial. They want to understand how you analyze the context (team size, scaling requirements, domain complexity) and derive a justified decision from it. This is the same skill you need when making architecture decisions for real projects in practice.

At German tech companies, there is an additional expectation: pragmatism. If you design a system for 1,000 users with an architecture built for 100 million users, you are not showing technical depth. You are showing poor judgment. German interviewers value candidates who choose the simplest design that meets the requirements and only scale up when the context demands it.

The Microservices Reflex🔗

Microservices have experienced enormous hype in recent years. Every conference talk, every blog post, every architecture documentation from large companies seems to present microservices as the default. This has created a reflex: many candidates choose microservices by default without thinking about whether they make sense in the given context.

This reflex is one of the most common reasons for negative evaluations in system design interviews. Not because microservices are bad, but because an unjustified decision shows the interviewer that the candidate cannot distinguish hype from reality. The ability to consciously say “No, a monolith is sufficient here” and justify it is a stronger signal than any microservice architecture.

Monolith: Strengths, Weaknesses, and When It Is the Right Answer🔗

What a Monolith Does Well🔗

A monolith is a single, cohesive application deployed as one artifact. All components share the same process, the same database, and the same deployment cycle.

That sounds old-fashioned but brings concrete advantages. Debugging is simpler because you can follow a stack trace from the UI to the database without correlating logs across service boundaries. Data consistency is trivial because all operations run in the same database and you can use real transactions. Deployment is a single step, not an orchestration of twenty services with different version states. And for small teams (under ten developers), a monolith eliminates the coordination overhead that microservices create.

Shopify processes billions of dollars in transactions on a monolith. Stack Overflow serves millions of requests per day with a monolithic application. These examples show that the architecture decision does not depend on how large the system is, but on whether the system’s complexity justifies the costs of a distributed architecture.

When to Choose the Monolith in an Interview🔗

Three criteria point toward a monolith in the interview:

Small team: If the interviewer describes a scenario where a team of five to ten developers builds and operates the system, a monolith is almost always the better choice. The coordination costs of microservices outweigh the benefits at this team size.

Early product phase: If the system is new and domain boundaries are not yet clear, a monolith is the safer start. You can explore the domain, identify modules, and later extract specific services when boundaries stabilize. Cutting microservices from the start before you understand the domain leads to wrong service boundaries that are expensive to correct later.

Low scaling differences: If all parts of the system have similar load patterns and no single component needs to scale independently, there is no technical reason for microservices.

Frame it in the interview like this: “Given the team size and early product phase described, I would start with a well-structured monolith. This gives us faster iteration cycles, and we avoid the operational complexity of distributed systems as long as it brings no clear benefit.”

Microservices: Strengths, Weaknesses, and When They Are the Right Answer🔗

What Microservices Enable🔗

Microservices are independently deployable services, each covering a bounded business domain. Each service has its own database, its own deployment cycle, and can be developed by a separate team.

Their strengths lie where monoliths hit limits. Independent deployment means one team can update their service without waiting for other teams. Independent scaling lets you run the search service on 50 instances while the user management service runs on three. Technology freedom allows teams to choose the best language or database for their use case. And fault isolation prevents a bug in one service from taking down the entire system.

The Costs That Candidates Underestimate🔗

This is where the interviewer sees whether a candidate has theoretical knowledge or practical experience. The costs of microservices are real and significant:

Network communication: Every call between services goes over the network. That means latency, possible timeouts, and the need to handle network failures. A function call within a monolith takes nanoseconds. An HTTP call between services takes milliseconds, and that adds up.

Distributed transactions: When a business operation spans multiple services (create order + reduce inventory + trigger payment), you need Saga patterns or two-phase commits. Both are complex and error-prone. In a monolith, that is one database transaction.

Observability: When a request flows through five services and fails, you need distributed tracing, centralized logging, and service meshes to find the problem. That is its own infrastructure discipline.

Operational complexity: Twenty services mean twenty CI/CD pipelines, twenty monitoring dashboards, twenty sets of health checks. That requires a platform team or at least a very mature DevOps setup.

When you name these costs in the interview, you show the interviewer that you do not just know the architecture slides but understand what it means to run a distributed system in production.

When to Choose Microservices in an Interview🔗

Microservices are the right choice when the context justifies their costs:

Multiple independent teams: If the interviewer describes a scenario with 50+ developers working in multiple teams, microservices enable autonomous work without deployment conflicts.

Different scaling requirements: If the video transcoding service needs 100x more compute than the user profile service, independent scaling is a strong argument.

Clear domain boundaries: If the system has a well-understood domain where the boundaries between business capabilities are obvious (orders, payments, shipping, user management), services can be cut along those boundaries.

Decision Framework for the Interview🔗

The Four Questions That Guide Your Decision🔗

Instead of reciting abstract pros and cons, ask yourself four concrete questions in the interview:

1. How large is the team? Under 10 developers → monolith. Over 30 → seriously consider microservices. In between → context-dependent.
2. Are there different scaling requirements? If yes → microservices for the components that need to scale independently.
3. How clear are the domain boundaries? New domain with uncertain boundaries → monolith-first. Established domain with clear bounded contexts → microservices possible.
4. How mature is the operational infrastructure? No Kubernetes, no observability stack → microservices become an operational burden.

You can ask these four questions out loud to the interviewer. That demonstrates structured thinking and simultaneously gives you the information you need for a justified decision.

[1] When processing personal data, GDPR compliance is simpler to implement with centralized data storage than across distributed services, where the right to deletion must be coordinated.

How to Articulate Trade-offs in the Interview🔗

The phrasing makes the difference. Compare these two answers:

Weak: “I choose microservices because they scale better.”

Strong: “For this scenario, I would start with a modular monolith. The team has seven developers and the product is in an early phase where domain boundaries may still shift. I would structure the modules along business domains so we can later extract individual modules as services when the team grows or specific components need to scale independently. The trade-off is that we don’t have independent deployments in the short term, but operational simplicity outweighs that in this phase.”

The strong answer names the context, the decision, the justification, and the trade-off. That is the structure interviewers want to see. For more on how to approach system design interviews in Germany generally, see the System Design Interview Guide.

Mistakes You Should Avoid🔗

Choosing Microservices Without Justification🔗

The most common mistake. Candidates draw microservices because “that’s the modern approach.” Without context, that is not an architecture decision, it is a reflex. If the interviewer asks “Why not a monolith?” and you have no convincing answer, you have just shown that you did not make the decision consciously.

Dismissing the Monolith as “Outdated”🔗

Monoliths are not outdated. They are a deliberate architecture choice. Many successful systems run as monoliths, and companies like Shopify and Basecamp have publicly argued why they deliberately stay with monoliths. Anyone who presents the monolith as inferior signals a one-dimensional perspective to the interviewer.

Ignoring Hybrid Approaches🔗

Monolith and microservices are not the only options. The modular monolith is an architecture pattern that combines the benefits of both worlds: internal modularity with clear interfaces but without the operational complexity of distributed systems. A “monolith + one extracted service” for a specific scaling requirement is also a valid answer.

The technical interview playbook covers how to handle open-ended technical questions generally and how to guide the interviewer through your thought process.

Forgetting GDPR and Data Storage🔗

At German companies, GDPR is not a footnote. If you choose microservices and distribute personal data across multiple services, you need to explain how you implement the right to deletion. Which service holds the data? How do you ensure a deletion request reaches all affected services? Where is the data physically stored?

Candidates who raise these questions proactively stand out positively. Most international preparation resources do not cover GDPR at all, which leaves a gap in interviews at German companies.

German Tech Companies: What They Actually Use🔗

Corporations and the Mittelstand🔗

Many German corporations have their roots in monolithic architectures. SAP is the most well-known example: built for decades on a monolithic core architecture that has been progressively modularized. Similar patterns exist at companies like Siemens and Bosch in the IoT space.

The German Mittelstand, which represents a significant share of tech employers, also predominantly uses monolithic or modular-monolithic architectures. This is not due to technical backwardness but to a pragmatic assessment: the teams are small enough that a monolith is more efficient, and the scaling requirements do not justify a distributed architecture.

If you are interviewing at such a company and reflexively propose microservices, it can come across as implicitly criticizing their existing architecture. That does not go over well.

Startups and Scale-ups🔗

Berlin and Munich startups typically start with a monolith and migrate to microservices when the team grows beyond 30-40 developers. Zalando documented this path publicly: from a monolith through a “strangler fig” approach to microservices.

Delivery Hero, N26, and Trade Republic use microservice architectures, but that did not happen from day one. The transition took years, accompanied by platform teams that built the operational infrastructure.

In an interview at a startup, the strongest answer is often: “For the current state of the product, I would start with a monolith and cut modules so that later extraction is possible.” This shows experience with the evolutionary approach that most successful startups actually go through.

How to Prepare Effectively🔗

Practice Problems with Architecture Decisions🔗

Take three system design problems and solve each one twice: once as a monolith, once as microservices. Compare the results. Where was the monolith stronger? Where microservices? This trains your judgment better than any theoretical treatise.

Good practice scenarios:

• E-commerce platform for 1,000 orders per day, team of 8: A monolith is almost certainly the right choice here. Justify why.
• Video streaming service with 1 million users, team of 40: There are good arguments for microservices here. The transcoding service has completely different scaling requirements than the user profile service.
• Internal tool for 500 employees at a Mittelstand company: Monolith. Scaling requirements are low, the team is small, and operational simplicity is a clear advantage.

Talk out loud during each practice session as if an interviewer were listening. Explain your decision, name the trade-offs, and describe when you would have chosen the other architecture.

Mock Interviews with Real Feedback🔗

Practicing alone is the first step. But the monolith vs. microservices decision lives and dies by how convincingly you communicate it. You need someone who tells you whether your justification sounds compelling, whether you hit the right level of detail, and whether you are missing trade-offs an interviewer would have expected.

CodingCareer’s mock system design interviews simulate the format used at German tech companies. An experienced developer plays the interviewer, asks follow-up questions about your architecture decisions, and gives you concrete feedback on structure, communication, and technical depth. Unlike generic interview platforms that train for FAANG-scale problems, CodingCareer focuses on the pragmatic architecture decisions that German companies actually ask about.

The result is not just a better interview but a better understanding of how you make and communicate architecture decisions in your daily work.

Book your free 15-minute diagnostic session and find out where you stand in your system design preparation.