Why architecture matters here
Serverless architecture matters because it changes the economics of many workloads. Bursty APIs, event-driven pipelines, and low-QPS admin services pay only for actual execution. A service that gets 100 requests per day costs pennies; the same service on EC2 would cost hundreds of dollars per month idle.
Cost has trade-offs. High-QPS steady workloads become expensive on Lambda; a busy service that would fit in one $200/month EC2 might cost $2000/month on Lambda. Right sizing means knowing which workloads fit each model.
Reliability is where AWS serverless shines. Lambda's built-in retries, DynamoDB's regional replication, and API Gateway's throttling all remove failure classes that self-managed teams handle manually.
The architecture: every service explained
Walk the diagram top to bottom.
Client / Event. Triggers for Lambda: HTTP requests via API Gateway, S3 events, scheduled CloudWatch events, DynamoDB streams, SQS messages, EventBridge events. The event model is central.
API Gateway. HTTP → Lambda mapping. Handles auth (IAM, Cognito, custom authorizer), throttling, request transformation, and caching. REST APIs, HTTP APIs (cheaper), and WebSocket APIs are supported.
EventBridge / SQS. Asynchronous event bus. EventBridge routes events between services with rule-based filtering. SQS decouples producers from consumers with durable queuing.
Lambda Functions. The compute unit. Language runtimes for Python, Node, Java, Go, Rust, custom. Cold starts (100ms-2s for JVM; 10-100ms for Python/Node) matter for user-facing APIs.
Step Functions. Workflow orchestration. Coordinates multiple Lambdas with retries, error handling, parallel branches, waits. Alternative to embedding orchestration in Lambda code.
DynamoDB. The serverless database. Single-digit millisecond latency at any scale. Pay-per-request billing suits variable load. Global tables for multi-region.
S3. Durable object storage. Serverless in the sense that you never manage anything; scale is transparent. Event triggers on writes drive downstream Lambdas.
Aurora Serverless. PostgreSQL/MySQL compatible with autoscaling. Higher latency than DynamoDB but SQL semantics. V2 scales down to zero.
IAM per function. Least privilege at Lambda granularity. Each function has an IAM role scoped to only what it needs.
Observability. CloudWatch logs and metrics per function. X-Ray traces requests across Lambdas. Third-party (Datadog, Lumigo) for richer views.
IaC + CI/CD. AWS SAM, CDK, or Terraform to define the whole stack. Deploy via CodePipeline or GitHub Actions.
End-to-end request + async flow
Trace a request. A user hits GET /orders/123 on the API. API Gateway receives the request, authenticates via Cognito JWT, throttles per user, and invokes the getOrder Lambda.
Lambda starts. If this is a fresh function (cold start), it loads the runtime and code — say, 200ms. If warm, invocation begins immediately.
The function reads from DynamoDB: GetItem on orders table, key=123. DynamoDB returns in 5ms. Function formats the response and returns.
API Gateway sends the response back. Total latency: 250ms cold, 25ms warm.
Meanwhile, a second workflow. When a new order is placed, POST /orders inserts to DynamoDB. A DynamoDB stream fires; another Lambda consumes stream events; it publishes to EventBridge. EventBridge rules fan out to multiple consumers: send confirmation email, update analytics, notify fulfillment.
Fulfillment is complex — check inventory, reserve stock, create shipping label. It runs as a Step Functions state machine invoked by EventBridge. The state machine coordinates multiple Lambdas with retries and rollback. Failed steps notify support.
Everything scales automatically. During peak, hundreds of Lambda instances run in parallel. During off-peak, they scale to zero. Bills scale with usage.