What Is a Microservice?
Understand what a microservice is, how it differs from a monolith, its benefits, trade-offs, and how to explain bounded contexts in a system design interview.
Expected Interview Answer
A microservice is a small, independently deployable service that owns a single business capability, its own data store, and communicates with other services over the network via APIs or events.
Instead of one large monolithic codebase, a microservices architecture splits the system along business boundaries — orders, payments, inventory — where each service can be built, tested, deployed, and scaled independently by its own team. Services talk through well-defined contracts (REST, gRPC, or asynchronous messaging), and each keeps its own database so a schema change in one service never breaks another. This independence brings flexibility and fault isolation but trades away the simplicity of a single process: you now need service discovery, distributed tracing, network retries, and careful handling of eventual consistency across services.
- Independent deployment and scaling per service
- Teams own a bounded context end to end
- Fault isolation limits blast radius of failures
- Technology choices can vary per service
- Enables scaling only the hot parts of the system
AI Mentor Explanation
A microservice is like a specialist bowler brought on for exactly one job — containing the death overs — rather than one player expected to bat, bowl, and field everywhere. The team fields several such specialists, each independently trained and substituted without disrupting the others, and if one bowler has an off day the rest of the attack keeps functioning.
Step-by-Step Explanation
Step 1
Identify a bounded context
Split the system along business capabilities like orders, payments, or inventory rather than technical layers.
Step 2
Give each service its own data store
Avoid a shared database so schema changes in one service never break another.
Step 3
Define a stable API contract
Expose REST, gRPC, or event-based interfaces so services can evolve internally without breaking consumers.
Step 4
Deploy and scale independently
Each service has its own build, deployment pipeline, and can scale its own instances based on its own load.
Step 5
Add cross-cutting infrastructure
Service discovery, distributed tracing, circuit breakers, and centralized logging become necessary once you have many services.
What Interviewer Expects
- Defines a microservice as independently deployable with its own data
- Explains bounded contexts and business-capability alignment
- Names trade-offs: distributed complexity vs. team autonomy
- Mentions the need for service discovery and observability at scale
- Understands eventual consistency across service boundaries
Common Mistakes
- Confusing microservices with simply splitting code into folders
- Sharing one database across multiple 'microservices'
- Ignoring network failure modes like timeouts and retries
- Assuming microservices are always better than a monolith regardless of team size
Best Answer (HR Friendly)
“A microservice is a small piece of an application that handles one specific job, like processing payments or managing user accounts, and can be built, updated, and scaled on its own. This lets different teams work independently and reduces the risk that one bug takes down the entire system.”
Code Example
# orders-service/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-service
spec:
replicas: 3
template:
spec:
containers:
- name: orders
image: registry/orders-service:1.4.0
env:
- name: DB_URL
value: postgres://orders-db:5432/orders
---
# payments-service/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: payments-service
spec:
replicas: 5
template:
spec:
containers:
- name: payments
image: registry/payments-service:2.1.0
env:
- name: DB_URL
value: postgres://payments-db:5432/paymentsFollow-up Questions
- How do microservices communicate synchronously versus asynchronously?
- How do you handle a transaction that spans two microservices?
- What is the role of an API gateway in a microservices architecture?
- How do you debug a request that fails across five chained services?
- When would a monolith be a better choice than microservices?
MCQ Practice
1. What primarily defines a microservice?
The defining trait is independent deployability paired with owning its own data store, not any specific technology.
2. Why do microservices typically avoid a shared database?
A shared schema means a change in one service can silently break another, undermining independent deployability.
3. Which challenge is introduced by splitting a monolith into microservices?
Microservices trade in-process calls for network calls, introducing latency, partial failure, and the need for retries and tracing.
Flash Cards
What is a bounded context? — A clear boundary around a business capability, like orders or payments, that one microservice fully owns.
Why does each microservice keep its own database? — So changes to its schema never break other services, preserving independent deployability.
What is an API gateway used for? — It routes external requests to the right microservice and can handle auth, rate limiting, and aggregation.
What is a key trade-off of microservices vs. a monolith? — Team autonomy and fault isolation, at the cost of distributed system complexity like network calls and eventual consistency.