An illustrative learning architecture, not an employer production diagram. Build it in the monitoring lab.
Architecture explorer
Inside a serverless application
Explore the request flow and operational tradeoffs of the monitoring lab.
Request flow: API Gateway → Lambda → DynamoDB. Lambda telemetry flows to CloudWatch.
API Gateway
Purpose
Receives GET /visit and forwards the request to Lambda.
Failure modes
A missing route returns 404; burst traffic can be throttled with 429 responses.
Design tradeoff
An HTTP API keeps the demo small. Authentication and custom domains would be separate production decisions.
Lambda
Purpose
Updates the counter and returns a JSON response.
Failure modes
Timeouts, IAM denial, and application exceptions can produce server errors.
Design tradeoff
A short-lived function avoids managing servers, while cold starts and execution limits shape latency.
DynamoDB
Purpose
Stores one counter using an atomic UpdateItem operation.
Failure modes
Denied writes or service errors prevent the response from completing.
Design tradeoff
On-demand capacity simplifies the exercise. A single shared counter is a demo pattern, not a universal data model.
CloudWatch
Purpose
Collects function logs and metrics, displays a dashboard, and evaluates alarms.
Failure modes
Missing permissions can prevent log delivery; metrics and alarms have evaluation delay.
Design tradeoff
Short log retention limits accumulated data. Alarms in this lab demonstrate state changes without paging anyone.