AWS & CloudServerless architecture tận dụng managed services loại bỏ server management: Lambda (compute), API Gateway (HTTP routing), DynamoDB (database), S3 (storage), SQS/SNS/EventBridge (messaging), Cognito (auth), Step Functions (orchestration).
Pattern 1 — REST API: API Gateway → Lambda → DynamoDB; ưu điểm: không manage server, auto-scale, pay-per-request; nhược: cold start, 29s timeout API Gateway, stateless.
Pattern 2 — Event-driven microservices: services communicate qua EventBridge/SQS/SNS thay vì direct HTTP call; mỗi service là Lambda subscribe event, emit event sau khi xử lý; loosely coupled, independently deployable và scalable; phức tạp debugging (distributed transaction tracking cần X-Ray + correlation IDs).
Pattern 3 — Saga pattern cho distributed transactions: mỗi service local transaction + compensating transaction; Choreography-based saga: mỗi step publish event, next step subscribe và trigger — decentralized nhưng khó monitor; Orchestration-based saga: Step Functions orchestrate toàn bộ flow, mỗi bước có compensating step nếu fail — centralized, dễ debug hơn, preferred trên AWS.
Pattern 4 — BFF (Backend for Frontend): Lambda functions riêng tối ưu cho từng client type (mobile, web, third-party API).
Pattern 5 — CQRS + Event Sourcing: DynamoDB Stream trigger Lambda cập nhật read model.
Anti-patterns serverless: long-running computation (>15 phút), large file processing inline (dùng S3 trigger + async), database connection pooling (dùng RDS Proxy).
Serverless architecture leverages managed services to eliminate server management: Lambda (compute), API Gateway (HTTP routing), DynamoDB (database), S3 (storage), SQS/SNS/EventBridge (messaging), Cognito (auth), and Step Functions (orchestration).
Pattern 1 — REST API: API Gateway → Lambda → DynamoDB; pros: no server management, auto-scaling, pay-per-request; cons: cold starts, 29s API Gateway timeout, stateless.
Pattern 2 — Event-driven microservices: services communicate via EventBridge/SQS/SNS instead of direct HTTP calls; each service is a Lambda function subscribing to events and emitting events after processing; loosely coupled, independently deployable and scalable; debugging is complex (distributed transaction tracking requires X-Ray + correlation IDs).
Pattern 3 — Saga pattern for distributed transactions: each service performs a local transaction with a corresponding compensating transaction; Choreography-based saga: each step publishes an event and the next step subscribes and triggers — decentralized but hard to monitor; Orchestration-based saga: Step Functions orchestrates the entire flow, with a compensating step for each failure — centralized, easier to debug, and preferred on AWS.
Pattern 4 — BFF (Backend for Frontend): separate Lambda functions optimized for each client type (mobile, web, third-party API).
Pattern 5 — CQRS + Event Sourcing: DynamoDB Streams trigger Lambda to update the read model.
Serverless anti-patterns: long-running computations (>15 minutes), large inline file processing (use S3 trigger + async), and database connection pooling (use RDS Proxy).