Microservices
What is it?
Microservices is an architecture that splits an application into many small, independent services that each own one piece of the business and talk over the network.
Explain like I'm 5
Why was it created?
Large single applications became hard to change and deploy safely. Microservices let teams build, deploy, and scale parts independently.
Where is it used?
- Large-scale web platforms
- Systems with many independent teams
- Apps needing per-feature scaling
- Cloud-native architectures
Why should developers care?
Many large organizations run microservices, so understanding their trade-offs matters for backend and platform roles.
How does it work?
Each service has its own codebase and often its own database, exposing an API. Services communicate over the network (e.g. REST, gRPC, or messaging), and each can be deployed and scaled on its own.
Real-world example
An e-commerce app separates checkout, search, and recommendations into distinct services so the search team can deploy changes without touching checkout.
Common use cases
- Independent team ownership
- Scaling hot features separately
- Mixing technologies per service
- Frequent independent deployments
Advantages
- Independent deployment and scaling
- Team autonomy
- Fault isolation
- Technology flexibility per service
Disadvantages
- Distributed systems are complex
- Network calls can fail and add latency
- Harder to test and debug end to end
- Operational overhead
When should you use it?
When an app and its teams are large enough that independent deployment and scaling outweigh the added complexity.
When should you avoid it?
For small teams or early products — a monolith is usually simpler and faster.
Alternatives
Related terms
Interview questions
Beginner
- What is a microservice?
- How does it differ from a monolith?
Intermediate
- How do services communicate?
- Why might each service have its own database?
Senior
- How do you handle data consistency across services?
- How do you trace a request across many services?
Common misconceptions
- "Microservices are always better than a monolith" — they add complexity that small projects don't need.
- "More services means more scalable" — poorly designed boundaries can make things slower and harder.
Fun facts
- A well-designed microservice is usually owned end-to-end by a single small team.
- The opposite approach, a monolith, is often the right starting point.
Timeline
- 2014 — The term gains wide popularity in industry
Learning resources
Quick summary
Microservices split an app into small, independently deployable services, trading simplicity for team autonomy and flexible scaling.
Cheat sheet
- Many small, independent services
- Each owns one business capability
- Communicate over the network
- Powerful but operationally complex