What are microservices and what problems do they solve compared to a monolith?
Learn what microservices are, how they differ from a monolith, and the scaling, deployment, and fault-isolation problems they solve — with examples.
Expected Interview Answer
Microservices are an architectural style where an application is built as a suite of small, independently deployable services, each owning a single business capability and communicating over the network. They solve the scaling, deployment, and team-autonomy problems a large monolith runs into as it grows.
In a monolith, all features live in one codebase and one deployable unit, so a change anywhere forces a redeploy of everything and one bug can take down the whole app. Microservices split those features into separately owned services that can be built, deployed, scaled, and even written in different languages independently. The trade-off is added operational complexity: network calls, distributed data, and observability all become harder, so microservices pay off mainly when the organization and system are large enough to need that independence.
- Independent deployment of each service
- Independent scaling of hot paths only
- Fault isolation so one service failing does not crash the whole app
- Team autonomy and parallel development
- Freedom to choose the best technology per service
AI Mentor Explanation
A monolith is like one all-rounder expected to open the batting, keep wickets, and bowl every over — if that single player is injured the whole side collapses. Microservices are a full squad of specialists: a fast bowler, a spinner, a wicketkeeper, each trained and replaced independently, so one player's off day never sinks the entire team.
Step-by-Step Explanation
Step 1
Identify business capabilities
Break the system down by what it does for the business — orders, payments, inventory — not by technical layer.
Step 2
Carve out a service per capability
Give each capability its own codebase, data store, and deployment pipeline so it can evolve alone.
Step 3
Define contracts between services
Expose each service through a stable API (REST, gRPC, or events) and hide its internal implementation.
Step 4
Deploy and scale independently
Run each service in its own container or process so you can release and scale it without touching the others.
Step 5
Add cross-cutting infrastructure
Introduce API gateways, service discovery, centralized logging, and monitoring to manage the distributed system.
What Interviewer Expects
- A clear definition of microservices as independently deployable services
- Concrete contrast with the monolith's single deployable unit
- Awareness that microservices add operational complexity, not just benefits
- Understanding of independent scaling and fault isolation
- Recognition that team size and organization drive the decision
Common Mistakes
- Claiming microservices are always better than a monolith
- Confusing microservices with simply splitting code into modules in one deployable
- Ignoring the distributed-systems complexity they introduce
- Assuming every service needs its own team from day one
- Overlooking data ownership and separate databases per service
Best Answer (HR Friendly)
“Microservices split a big application into many small, independent programs that each handle one job and can be updated on their own. Compared to a single large program, this makes it easier for different teams to work in parallel and keeps one broken feature from taking down everything else.”
Code Example
services:
orders:
build: ./orders
ports:
- "8081:8080"
environment:
- DB_URL=postgres://orders-db/orders
payments:
build: ./payments
ports:
- "8082:8080"
environment:
- DB_URL=postgres://payments-db/payments
# Each service builds, deploys and scales on its own.Follow-up Questions
- When would you choose a monolith over microservices?
- How do microservices communicate with each other?
- How do you handle data consistency across services?
- What is a service mesh and why might you need one?
- How do you decide how small a microservice should be?
MCQ Practice
1. What is the primary deployment characteristic of a microservice?
A defining trait of a microservice is that it can be built, deployed and scaled independently of the rest of the system.
2. Which problem do microservices most directly address compared to a monolith?
Microservices decouple features so a change to one service does not require redeploying the entire application.
3. What is a common downside of microservices?
Splitting into networked services adds complexity around communication, distributed data, and observability.
Flash Cards
What is a microservice? — A small, independently deployable service that owns one business capability and communicates over the network.
Key monolith weakness microservices fix? — Tight coupling — one change forces redeploying the whole app and one bug can crash everything.
Main trade-off of microservices? — Added operational and distributed-systems complexity: network calls, distributed data, and observability.
When do microservices pay off? — When the system and organization are large enough to need independent deployment, scaling, and team autonomy.