Microservices Architecture

# Monolith Architecture
[User Service] [Order Service] [Payment Service] [Email Service]
 ? ? ? ?
 [Single Database] [Single Deployment]

# Microservices Architecture
[User Service] ? [User DB]
[Order Service] ? [Order DB]
[Payment Service] ? [Payment DB]
[Email Service] ? [Email DB]
(Independently deploy, scale, update)

# Comparison:
| Feature | Monolith | Microservices |
|---------------|-----------------------|-------------------------|
| Deployment | Single unit | Independent per service |
| Scaling | Vertical | Horizontal per service |
| Tech Stack | Single | Polyglot (different per)|
| Database | Shared | Database per service |
| Complexity | Low initially | High (distributed) |
| Team | Single team | Multiple teams |
| Debugging | Easy (single codebase)| Hard (distributed logs) |

# When to use Monolith:
- Small team (< 10 developers)
- MVP / early stage product
- Simple domain

# When to use Microservices:
- Large team (50+ developers)
- Complex domain
- Multiple deployment needs

# 1. API Gateway
✓ Single entry point for all clients
✓ Request routing, authentication, rate limiting
✓ Example: AWS API Gateway, Kong, Zuul

# 2. Service Discovery
✓ Services ek doosre ko dhundhte hain
✓ Dynamic registration/deregistration
✓ Example: Eureka, Consul, etcd

# 3. Load Balancer
✓ Traffic distribute karna service instances mein
✓ Client-side ya server-side
✓ Example: Ribbon, Envoy

# 4. Circuit Breaker
✓ Agar service down hai toh fail fast karo
✓ Cascading failures se bachao
✓ Example: Hystrix, Resilience4j

# 5. Service Mesh
✓ Services ke beech communication manage karo
✓ Observability, security, traffic management
✓ Example: Istio, Linkerd

# 6. Distributed Tracing
✓ Request ka path track karo multiple services mein
✓ Debugging ke liye essential
✓ Example: Jaeger, Zipkin, AWS X-Ray

# 1. Synchronous (REST/gRPC)
✓ Request-Reply pattern
✓ Client wait karta hai response ka
✓ Use: Real-time queries, user-facing APIs

# REST: HTTP + JSON
GET /api/users/123 ✓ User Service ? {"name": "Vaibhav"}

# gRPC: HTTP/2 + Protocol Buffers (faster)
service UserService {
 rpc GetUser(GetUserRequest) returns (User);
}

# 2. Asynchronous (Message Queue)
✓ Fire and forget pattern
✓ Client wait nahi karta
✓ Use: Event-driven, background tasks

# Example: Order Service publishes "OrderPlaced" event
✓ Payment Service listens, processes payment
✓ Email Service listens, sends confirmation

# Best Practice: Mix both
✓ Queries: REST/gRPC (synchronous)
✓ Commands: Message Queue (asynchronous)

# 1. By Business Capability
✓ User Management, Order Management, Payment Management
✓ Har business function = ek service

# 2. By Subdomain (DDD)
✓ Core Domain: Order Service
✓ Supporting Domain: Notification Service
✓ Generic Domain: Authentication Service

# 3. By Data Ownership
✓ Har service ka apna database
✓ No shared databases!
✓ Cross-service queries via APIs

# Anti-patterns:
✓ Shared Database (tight coupling)
✓ Nano Services (too many tiny services)
✓ Distributed Monolith (services tightly coupled)

# The "Two Pizza Rule" (Amazon):
✓ Ek service itni chhoti ho ki 2 pizzas se team khaye
? ~5-8 developers per service