Overview
This topic compares two primary architectural styles for building applications: the Monolith (a single, unified unit) and Microservices (a collection of small, independent services).
Core Concepts
- Monolithic Architecture:
- Unified: All business logic, data access, and UI are in one codebase.
- Pros: Simple to develop, test, and deploy initially. Low latency between components.
- Cons: Becomes “The Big Ball of Mud” as it grows. Scalability is all-or-nothing. Long build/deploy times.
- Microservices Architecture:
- Decoupled: Each service owns its own business capability and its own database.
- Pros: Independent scaling, technology diversity (different languages for different services), independent deployment.
- Cons: Operational complexity (service discovery, load balancing), data consistency challenges (distributed transactions), increased network latency.
- Communication Patterns:
- Synchronous: REST, gRPC (request-response).
- Asynchronous: Message queues (RabbitMQ, Kafka), Event-driven architecture.
- Database per Service: The rule that each microservice must manage its own data to ensure true decoupling.
Code Examples
// Conceptual Monolith: Everything in one project
class UserService { ... }
class OrderService { ... }
class PaymentService { ... }
// Conceptual Microservices: Separate projects/deployments
// User-Service: Port 3001
// Order-Service: Port 3002
// Payment-Service: Port 3003
// Gateway: Port 3000 -> routes to 3001, 3002, or 3003Use Cases
- Monolith: Ideal for small teams, early-stage startups (MVP), and applications with low complexity.
- Microservices: Ideal for large organizations with many teams, highly complex domains, and applications requiring extreme scalability.
Gotchas
- Distributed Monolith: A system that looks like microservices (separate processes) but is so tightly coupled that any change requires deploying all services simultaneously.
- Consistency (CAP Theorem): In a distributed system, you can only have two of Consistency, Availability, and Partition Tolerance.