Topics
- 1. What are Microservices?
- 2. Microservices vs Monolithic Architecture
- 3. Advantages of Microservices
- 4. Disadvantages of Microservices
- 5. When NOT to Use Microservices
- 6. What is Service Decomposition?
- 7. How Do Microservices Communicate?
- 8. What is Bounded Context?
- 9. What is Domain-Driven Design (DDD)?
- 10. Stateless vs Stateful Services
- 11. How Do You Design Microservices?
- 12. How Do You Decide Service Boundaries?
- 13. What is an API Gateway?
- 14. Benefits of API Gateway
- 15. API Gateway vs Load Balancer
-
Microservices are an architectural style where software is built as a collection of small, independent services, each focused on a single function.
-
Key points:
-
Each service runs independently.
-
Developed and deployed separately.
-
Communicate through APIs (Application Programming Interfaces).
-
Example (Online Shopping App):
-
User Service: Manages user accounts.
-
Product Service: Handles product catalog.
-
Payment Service: Processes payments.
-
Each service can be updated or scaled without affecting the others.
| Feature | Monolithic | Microservices |
|---|---|---|
| Structure | Single large application | Many small independent services |
| Deployment | Entire app deployed at once | Each service deployed independently |
| Scalability | Scale whole app | Scale individual services |
| Failure impact | One bug can crash everything | Bug usually affects only one service |
| Development | Harder for multiple teams | Easier for multiple teams |
| Technology | Usually one tech stack | Each service can use different tech |
In short:
-
Monolithic: One big block of code.
-
Microservices: Many small blocks working together.
-
-
Scalability: Only the services that need more resources are scaled, saving cost and improving performance.
-
Independent Deployment: Services can be updated or deployed without affecting the entire application.
-
Flexibility in Technology: Each service can use the best-suited programming language, framework, or database.
-
Fault Isolation: Failures in one service usually don’t crash the whole system.
-
Better Team Organization: Teams can own specific services, reducing conflicts and improving efficiency.
-
-
Complexity: Managing multiple services is more complicated than a single application.
-
Network Latency: Communication between services over APIs can be slower than internal calls in a monolith.
-
Data Management Challenges: Maintaining consistency across distributed services is harder.
-
Monitoring & Debugging Difficulty: Tracing issues across multiple services can be challenging.
-
DevOps Overhead: Requires robust CI/CD pipelines, deployment automation, and monitoring tools.
Microservices may not be suitable if:
-
The application is small or simple — a monolithic approach is faster and easier.
-
The team is small or lacks DevOps expertise.
-
There’s little need for independent scaling or deployment.
-
You want simpler data management — microservices often need distributed databases.