Microservices Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand microservices as a trade-off that buys independent deploy/scale/team-autonomy at the cost of distributed-system complexity, and can name when those costs are worth it.
Adopting microservices because 'Netflix/Amazon did' without naming the forces (team size, deploy cadence, independent scaling needs) that justify the operational and consistency costs.
Frame microservices as a trade-off: they buy independent deployment, independent scaling, and team autonomy at the cost of distributed-system complexity (network failures, eventual consistency, observability, distributed transactions) — and name the forces (team size, deploy cadence) that decide when the trade is worth it.
Interview-ready guide
Interview answer
Microservices are an architectural style that splits a system into small, independently deployable services, each organized around a business capability and owned by one team.
They exist because a monolith, while simple, couples deployment, scaling, and ownership — one team's change forces a full redeploy, the whole app scales as one, and many teams edit the same codebase. Microservices decouple those concerns, but the trade-off is distributed-system complexity: network failures, eventual consistency, distributed transactions, and much harder observability.
The split is by business capability, not technical layer, and the boundaries should match team boundaries — that's Conway's Law. The part that actually decouples services is decentralized data, a database per service, but that forces eventual consistency and sagas instead of local ACID transactions. The decision rule I use is to adopt microservices only when the forces justify the cost — multiple teams, independent deploy cadence, independent scaling needs.
A small team with one deployable is often better served by a modular monolith, because microservices give you all the costs and none of the autonomy if the boundaries are wrong.
Microservices Fundamentals
Direct Answer
Microservices is an architectural style that structures a system as a set of small, independently deployable services, each organized around a business capability and owned by one team, communicating over a network (usually HTTP or async messaging). They exist because a monolith, while simple to build and operate, couples deployment, scaling, and ownership: one team's change can break another's, the whole app scales as one, and a single bug can take down everything. Microservices decouple those concerns — but at the cost of distributed-system complexity (network, consistency, observability).
Common Mistakes & Pitfalls
Adopting microservices because 'Netflix/Amazon did' without naming the forces (team size, deploy cadence, independent scaling needs) that justify the operational and consistency costs.
Check your understanding
Answer these without looking back at the article.
- What forces justify adopting microservices over a modular monolith, and when is the monolith the right choice?
- Why is decentralized data (a DB per service) the true decoupler, and what does it cost?
- How does a saga replace a distributed ACID transaction across microservices?
- What is the difference between synchronous and asynchronous communication between services, and what does each couple?
- How does Conway's Law affect microservice boundaries, and what goes wrong if you ignore it?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.