Microservices vs Monoliths for System Design Interviews

When you sit down for a system design interview and the interviewer asks, "How would you architect this platform?", one of the first decisions you face is the high-level structure: monolith or microservices. The question is not really about dogma, it is about tradeoffs. Both are valid, and your job is to think through them clearly, propose one, and defend your choice when cross-questioned.

This post walks you through the definitions, the real operational differences, the pros and cons of each, when to choose which, and how the migration path usually works in practice. You will also see how system design is tested on Rehurz as a live spoken round.

Quick answer

A monolith is a single deployable unit: one codebase, one database, one process. All features run in the same application. Microservices are independent, loosely coupled services: each with its own codebase, database, deployment, and team. Monoliths are simpler to build, test, and deploy at small scale but become harder to scale and change. Microservices scale and evolve independently but add complexity in coordination, observability, and data consistency. For interviews, the right answer is to define the tradeoff clearly, propose one with honest reasoning, and show you understand the operational cost.

What is a monolithic architecture

A monolith is a single application that handles all the features your system needs. If you are building an e-commerce platform, the monolith contains the product catalog, checkout, order processing, payment integration, notifications, and user accounts all in one codebase and deployed as one unit.

When the user clicks "buy," the request hits a single application. That application queries a single database, runs the business logic, and responds. If you need to scale, you add more instances of the same monolith behind a load balancer, all pointing to the same shared database.

The monolith is often organized into layers: a database layer, a business logic layer, and a presentation layer. You might have packages or modules for each domain (Users, Orders, Products), but they all live in the same process and share the same memory, database connection pool, and deployment cycle.

What is a microservices architecture

Microservices break the system into small, independently deployable services. Each service owns a specific business capability and its own data store. An e-commerce platform might have a User Service, a Product Service, an Order Service, a Payment Service, and a Notification Service. Each runs in its own process (or container), has its own database, and can be deployed, scaled, and modified independently.

Services communicate over the network using APIs (REST, gRPC) or asynchronous messaging (event queues). When a user buys something, the Order Service calls the Payment Service to charge the card, publishes an "OrderCreated" event that the Notification Service subscribes to, and stores the order in its own database.

Each team can use a different technology stack if they want. The User Service could be written in Go, the Order Service in Python, the Product Service in Java. The only contract is the API boundary between them.

Monolith vs microservices architecture at a glance

Here is how each architecture looks in practice:

MONOLITHIC ARCHITECTURE:

[Load Balancer]
       |
   +---+---+---+
   |   |   |   |
 [App][App][App] <- all instances identical
   |   |   |   |
   +---+---+---+
       |
   [Shared Database]

Features (Users, Products, Orders, Payments, Notifications)
all in the same application code and process.


MICROSERVICES ARCHITECTURE:

[API Gateway / Load Balancer]
   |    |    |      |       |
   |    |    |      |       |
[User] [Product] [Order] [Payment] [Notification]
Service  Service   Service Service   Service
   |       |        |       |         |
[DB1]   [DB2]    [DB3]   [DB4]     [DB5]

Services communicate via REST/gRPC/events.
Each service owns its data and deployment.

Key operational differences: deployment, scaling, and complexity

The real difference shows up in how you build, test, deploy, and run these systems. Here is a direct comparison:

Aspect           | Monolith        | Microservices
-----------------+-----------------+-----------------------------
Deployment       | One unit        | Each service independently
Scaling          | Scale the whole | Scale individual services
                 | app, all features
                 |
Database         | Shared, single  | Each service has its own
                 | schema          | schema and database
                 |
Development      | Tight coupling, | Loose coupling, parallel
Velocity         | slower to change| teams, faster locally
                 | a feature       |
                 |
Observability    | Logs in one     | Distributed logs, traces,
                 | place           | harder to debug
                 |
Data Consistency | ACID, single    | Eventual consistency,
                 | transaction     | saga pattern for
                 |                 | cross-service workflows
                 |
Operational      | Fewer moving    | More infrastructure,
Complexity       | parts           | orchestration, service mesh
                 |                 | (optional but common)
                 |
Team Structure   | Works for small | Requires clear ownership
                 | (10-20 person)  | and service boundaries
                 | teams           | (better for 50+ engineers)

Pros and cons of monolithic architecture

A monolith is straightforward to reason about. You write a function in one service that calls another function, and they share the same memory and database. You do not worry about network latency or serialization. Testing is simpler because you can unit test with a single database.

Deployment is also simple. You build one artifact (a JAR file, a binary, a container image) and deploy it to your servers. Rollback is a single operation. If you need to scale for peak traffic, you spin up more instances of the monolith.

The downsides emerge as the codebase grows. When a new engineer joins and needs to add a feature, they have to understand a large codebase. Changes can have unexpected side effects. If you want to use a new technology or framework for one feature, you often have to change the entire monolith. Scaling becomes inefficient: if only the checkout feature needs more CPU, you still have to scale the entire app, which now also includes the product catalog, recommendations, and user profiles using extra resources they do not need.

A deployment failure in one part of the system can take down the entire application. If a memory leak develops in the notifications module, the whole monolith crashes, and every user-facing feature goes down. Scaling to very large request volumes becomes harder because you are constrained by the shared database and the shared memory of a single process.

Pros and cons of microservices architecture

The main advantage of microservices is independence. Each service can be deployed, scaled, and restarted without affecting others. If the Notification Service is slow, you add more notification instances without changing the Order Service. Each team can move at its own pace, using their own tools and deploys.

Failures are also isolated. If the Notification Service crashes, users can still browse products and place orders. The system degrades gracefully instead of failing entirely.

For large engineering organizations with many teams and domains, microservices allow clear ownership boundaries. Team A owns the User Service, Team B owns the Product Service, and there is no ambiguity about who is responsible for what.

The tradeoff is complexity. You now have many moving parts: multiple services, databases, APIs, deployment pipelines, and monitoring. A single user request might involve five network calls across five services. If any of those calls is slow or fails, the whole operation can hang or degrade. Debugging is harder because you have to trace logs across multiple services.

Data consistency becomes complicated. With a shared database and ACID transactions, you know that either the entire order and payment succeed together or both fail. With microservices, each service has its own database. When the Order Service creates an order and then calls the Payment Service, and the payment fails, the order is already in the database. You have to handle this with patterns like the saga pattern (a sequence of compensating transactions) or eventual consistency.

Operational overhead is much higher. You need container orchestration (Kubernetes, Docker Swarm), service discovery, monitoring, distributed tracing, and possibly a service mesh. You need to be very disciplined about testing, deployment, and observability.

When to choose a monolith

Start with a monolith if the system is new or small. A monolith is perfect for a startup with a small team (fewer than 20 engineers) and a single, well-defined product. You will move faster, deploy simpler, and avoid premature complexity.

Choose a monolith if your features are tightly coupled or share a lot of data. For example, if your product is a single-tenant SaaS with most features accessing the same core domain model, a monolith fits well.

Choose a monolith if data consistency and ACID transactions are critical. Financial systems, inventory systems, and order processing are often better served by a monolith because the cost of eventual consistency (refunds, reversals, compensations) is high.

Choose a monolith if your team has limited infrastructure expertise. Running microservices requires experienced DevOps and operations people. If your team is small or junior, the operational overhead of microservices can be a distraction.

When to choose microservices

Choose microservices when you have multiple large teams and clear domain boundaries. If your organization has a backend team, a payments team, a notifications team, and an analytics team, microservices let each team own a service and deploy independently.

Choose microservices when you need to scale different parts of the system at different rates. If your product catalog is read-heavy and needs to scale to millions of requests per second, but your order processing is low-volume, microservices let you scale the catalog independently.

Choose microservices when you want to be able to change one part of the system without re-testing the entire monolith. If you are deploying the Notification Service five times a day and the User Service once a month, microservices give you that flexibility.

Choose microservices when you have a mature engineering organization with strong DevOps and observability practices. If your team is already running Kubernetes, has distributed tracing set up, and can handle the operational complexity, microservices are manageable.

The migration path: start monolith, modularize, then split

In practice, many successful companies start with a monolith and migrate toward microservices only when they outgrow the monolith. This is not a failure of monoliths, it is the right sequence.

The intermediate step is often a modular monolith: a single deployable unit with clear internal boundaries. You organize your code into distinct domains with strict rules about how they communicate. The Order domain can only talk to the User domain through a defined API, not by directly accessing its database. The Payment domain talks to the Order domain the same way.

A modular monolith gives you many of the benefits of microservices (clear ownership, independence of thought) without the operational cost of multiple services, databases, and deployment pipelines. It is a great place to be for many organizations and is often overlooked in the hype around microservices.

When you do eventually split into microservices, the modular boundaries become service boundaries. The Order module becomes the Order Service. The User module becomes the User Service. The separation is less painful because you have already treated them as independent.

The other practical consideration is that you should not split a monolith into microservices until you understand your domain well enough to define clear service boundaries. If you split too early, you end up with services that do not align with your actual business domain, and you spend years refactoring service boundaries.

Frequently asked questions

What if my system has both monolithic and microservice components?

Yes, this is common. You might have a monolithic backend for the core business logic and separate microservices for analytics, notifications, or payment processing. A hybrid approach can be the right answer depending on the risk and scalability profile of each component. In an interview, you can propose this if you have clear reasoning for why each component needs its architecture.

How do you handle database transactions across microservices?

You do not use ACID transactions. Instead, you use eventual consistency and patterns like sagas (a sequence of operations with compensating transactions if one fails) or event sourcing (recording all changes as events and replaying them). This is more complex but necessary when each service owns its data. Mention this if data consistency is important to your design.

Can you start with microservices?

You can, but it is usually wasteful. You add operational complexity before you have the team scale and organizational clarity to justify it. Some teams do it because they believe it will be easier to scale later, but premature microservices often delay time-to-market more than they save.

What is a service mesh, and do you need one?

A service mesh (like Istio or Linkerd) is infrastructure that handles service-to-service communication, retries, circuit breaking, and observability. It is not essential but becomes valuable at scale. For an interview, do not mention it unless you are asked about resilience patterns or the interviewer seems interested in operational detail.

How do you test a microservices system?

Unit testing is the same. Integration testing becomes harder because services depend on each other. You use contract testing (verifying the API contract between services), test doubles, and staging environments. This is an important topic for system design interviews because testing complexity is often overlooked.

What is the right team size for microservices?

A rough rule is two-pizza teams: teams small enough to be fed by two pizzas (about six to eight people). If each team owns a service, microservices work well. If you have fewer teams than services, or unclear ownership, microservices become chaos. Mention this in your interview if team structure is relevant.

Practising system design with Rehurz

System design is tested on Rehurz as a live spoken round where you are cross-questioned like a real interview. You get 15 to 60 minutes to design a system (choosing the duration), and the interviewer challenges your assumptions, probes your tradeoffs, and adapts based on your answers. The system design dimension is part of your technical scorecard.

You might design an e-commerce platform, a messaging system, or a recommendation engine. You explain your architecture out loud, defend your choices under questioning, and show how you would handle scale and failures. Unlike a written system design document, a live interview surfaces gaps in your thinking quickly. If you propose microservices for a startup with five engineers, the interviewer will ask why, and you have to defend it in real time.

Try a live technical interview on Rehurz to practise this. Your first round is free, and you will get feedback on your reasoning, communication, and handling of tradeoffs. You can then refine your approach and interview again.

Final thoughts

Monoliths and microservices are not about ideology. They are tools with different costs and benefits. Monoliths are simpler and move faster at small scale but become hard to change and scale as the system grows. Microservices give you independence and scalability but add complexity in coordination, observability, and consistency. The best choice depends on your team size, domain clarity, and operational maturity. In a system design interview, show that you understand both sides, propose one with clear reasoning, and explain what would make you reconsider that choice as the system evolves. That is the mindset that gets you hired.

Your first interview is free, no card required. Start your first interview.