Building the API Layer: API Gateway and Lambda

Most of what this application's API needs to do is straightforwardly synchronous: a learner's browser asks for a lesson's content, or reports that a lesson was completed, and expects a response before moving on. This is exactly what Module 7's API Gateway plus Lambda pattern is for: API Gateway receives the HTTP request and invokes a Lambda function, which does the actual work — reading or writing DynamoDB — and returns a response.

Requirement: handle learner-facing API requests (view a lesson, record progress) without operating always-on servers sized for peak load. Decision: API Gateway routes requests to Lambda functions that read and write DynamoDB. Reason: this combination scales automatically with request volume and has no idle server cost between requests. Alternative: a container-based API (Module 9's ECS/Fargate pattern) running continuously behind a load balancer. Trade-off: Lambda functions have per-invocation constraints (timeout, cold starts) that a long-running container doesn't — reasonable here because these requests are short, but worth stating rather than ignoring.

This is the module's worked capstone example of asynchronous processing, first introduced in Lesson 1's Project Decision Record: when a learner completes a course, a certificate should be generated (and possibly emailed), but that work — rendering a document, calling an email provider — is slower and not something the learner's "course complete" response should wait on.

Requirement: certificate generation must not block or slow down the learner's course-completion request. Decision: the completion Lambda sends a message to an SQS queue; a separate worker consumes it and generates the certificate. Reason: this decouples a slow, non-critical background task from the fast request/response path the learner is actually waiting on (Module 8's decoupling pattern). Alternative: generate the certificate synchronously inside the same Lambda invocation before responding. Trade-off: the async path is eventually consistent (the certificate isn't ready the instant the response returns) and introduces new failure modes — a message could be processed twice, or a worker could fail — that the synchronous alternative doesn't have.

Moving work onto a queue doesn't remove the responsibility to handle failure — it changes where that responsibility lives. Two concerns matter specifically for this worker:

Idempotency: SQS can, under some conditions, deliver a message more than once. If the worker isn't written to handle that safely — for example, by checking whether a certificate for this learner and course has already been issued before generating another — a retried message could produce a duplicate certificate. An idempotent worker produces the same end result whether it processes a given message once or more than once.

Dead-letter queues: if a message repeatedly fails processing (a malformed record, a downstream error that never clears), it shouldn't retry forever or simply vanish. A dead-letter queue captures messages that failed past a configured retry limit, so they can be investigated instead of silently lost — and a growing dead-letter queue is exactly the kind of thing Lesson 6's monitoring should alert on.