EN_CS_MSA - somaz94/DevOps-Engineer GitHub Wiki

Q2: Microservice Architecture (MSA)

Question: Explain MSA and compare it with monolithic architecture. Focus on loose coupling, inter-service communication, and data management strategies.


Key Terms

Term Description
MSA Architecture style organizing apps as independently deployable small services
Loosely Coupled Services with minimal dependencies on each other
API Gateway Single entry point routing client requests to each service
Service Discovery Mechanism to dynamically locate service instances
Circuit Breaker Pattern to block requests to a failing service and prevent cascade failures
Saga Pattern Handles distributed transactions via event-driven compensation
Polyglot Persistence Using different DB technologies per service based on needs

Monolithic vs Microservices

Monolithic:                          Microservices:
┌──────────────────────────┐         ┌──────────┐ ┌──────────┐ ┌──────────┐
│    Single Application    │         │  User    │ │  Order   │ │ Payment  │
│  - User Service          │   →     │  Service │ │  Service │ │  Service │
│  - Order Service         │         │ (Node.js)│ │  (Java)  │ │ (Python) │
│  - Payment Service       │         │  UserDB  │ │  OrderDB │ │  PayDB   │
│  - Single Database       │         └──────────┘ └──────────┘ └──────────┘
└──────────────────────────┘                    ↑ API Gateway ↑

Monolithic vs MSA Comparison

Aspect Monolithic Microservices
Deployment Full redeploy required Independent per service
Scaling Vertical (Scale-Up) Horizontal (Scale-Out)
Tech Stack Single Best-fit per service
Failure Impact Entire system down Only affected service
Early Development Fast (simple) Slow (infra setup needed)
Ops Complexity Low High (monitoring, tracing, logging)
Data Consistency Strong (ACID) Eventual (BASE)

Inter-Service Communication

Synchronous

  • REST API: Simple and intuitive. Risk of timeout and cascade failures.
  • gRPC: Fast with Protocol Buffers, Type-Safe. Harder to debug.

Asynchronous

  • Message Queue (Kafka, RabbitMQ): Full decoupling and fault isolation.
  • Trade-off: Message ordering/deduplication complexity, Eventual Consistency.

Data Management Strategy

Database per Service

Each service owns its own DB (Polyglot Persistence).

  • Pros: Independent schema changes, fault isolation, optimal DB choice
  • Cons: No JOIN → API composition needed, distributed transaction challenges

Saga Pattern

Each service runs a local transaction and triggers the next via event. On failure, compensating transactions roll back in reverse.

Create Order → Reserve Inventory → Process Payment
On failure: Payment Failed → Restore Inventory → Cancel Order

Essential MSA Patterns

Pattern Role
API Gateway Routing, auth, rate limiting, logging in one place
Service Discovery Dynamic instance location (Eureka, Consul)
Circuit Breaker Block failing service, return fallback (Resilience4j)
Distributed Tracing Track request flow across services (Jaeger, Zipkin)

When to Use MSA

Suitable Not Suitable
Specific features with traffic spikes Early-stage startup (need fast prototyping)
Team of 10+ people Small team of 5 or fewer
Independent deploy cycles needed (daily+) No DevOps infrastructure

Reference

⚠️ **GitHub.com Fallback** ⚠️