1. Monolith vs Microservices

Core Principle Microservices decompose a monolith into small, loosely coupled services that communicate via APIs or messaging. Each service is independently deployable, scalable, and replaceable. AWS provides native services for every microservices pattern: compute (Lambda, ECS, EKS), communication (API GW, SQS, SNS, EventBridge), data (DynamoDB, Aurora), and observability (X-Ray, CloudWatch).
2. Microservices on AWS
AWS Microservices Architecture:
Client (Web/Mobile)
|
Amazon CloudFront (CDN)
|
API Gateway (REST/HTTP/WebSocket)
|
┌───────┼───────┼───────┐
| | | |
Order User Payment Notify
Service Service Service Service
(ECS) (Lambda) (ECS) (Lambda)
| | | |
DynamoDB Aurora DynamoDB SNS/SES
Communication: SQS (async), EventBridge (events)
Tracing: X-Ray (end-to-end)
Service Mesh: App Mesh (optional)Compute Options for Microservices

Communication Patterns

Database Per Service
- Each microservice owns its data store (no shared database)
- Service A uses DynamoDB, Service B uses Aurora, Service C uses ElastiCache
- Services access each other’s data only through APIs (never direct DB access)
- Benefits: independent scaling, independent schema evolution, technology freedom
- Challenge: distributed transactions (solve with Saga pattern via Step Functions)
AWS App Mesh
- Managed service mesh for microservices communication
- Traffic management: routing, retries, timeouts, circuit breakers between services
- Observability: metrics, traces, logs for all service-to-service traffic
- Uses Envoy proxy sidecars alongside each service container
- Use for: complex microservices needing fine-grained traffic control and observability
Exam Tip Microservices: "Independent services" = microservices. "Serverless micro" = Lambda. "Container micro" = ECS/Fargate or EKS. "Decouple" = SQS (async), SNS (fan-out), EventBridge (events). "Orchestrate" = Step Functions. "Service mesh" = App Mesh. "DB per service" = each service owns its data. "Tracing" = X-Ray. "API front door" = API Gateway.