Skip to content

Primary SAA curriculum

Serverless API With Lambda And DynamoDB

A low-operations API with managed HTTP entry, request-time Lambda compute, DynamoDB key access, safe retries, and deliberate capacity controls.

5 min read

After this, you will understand

Learn why serverless removes server management but not API design, data modeling, safe retries, capacity limits, or monitoring.

Article guideprerequisites, mental models, and concepts

Article overview

intermediateCloudCertificationSecurity

Three useful mental models

In plain terms

API Gateway receives the HTTP request, Lambda runs the request logic, and DynamoDB stores data that can be found through known keys.

Decision pressure

A team chooses serverless by fashion, designs DynamoDB after the code, retries writes without preventing duplicate effects, or assumes managed scaling has no limits.

Exam-ready model

Define the API routes and required data access first, then add request-time compute, narrow permissions, retry-safe writes, capacity limits, recovery, and monitoring.

Think before reading

What should you know before choosing a DynamoDB partition key?

Know the access patterns: which values each request has and which items it must retrieve or update. The partition key is the field DynamoDB uses to group and distribute those items.

Connected learning

These lessons add useful context to the current core lesson.
  1. 1Event-Driven Order ProcessingAWS Scenario

Serverless API With Lambda And DynamoDB — Quick Learn

A mobile shopping-cart API receives uneven traffic. Each request must authenticate a user, run a small amount of logic, and read or update that user's cart. The team wants automatic scaling without operating a server fleet.

The synchronous request path is:

Client → API Gateway → Lambda → DynamoDB → response

“Serverless” means AWS operates the underlying servers. It does not mean the system has no capacity limits, failure modes, permissions, or data-model decisions.

The synchronous request path is API Gateway to Lambda to DynamoDB; identity, recovery, capacity, and observability are attached controls rather than extra request hops.

Each Component Has One Main Job

  • API Gateway is the managed HTTP front door. It matches routes, checks client authorization, throttles requests, and invokes the integration.
  • Lambda runs short-lived application logic for the request. Its execution role grants only the AWS permissions that code needs.
  • DynamoDB stores cart state and supports direct key-based reads and writes at variable scale.
  • CloudWatch receives logs, metrics, and alarms so failures and throttling are visible.

The API's authorizer and Lambda's execution role answer different questions:

Authorizer:          May this client call this API?
Lambda execution role: May this function call this AWS resource?

An API key can identify or meter a client for usage plans, but it is not a substitute for user authentication and authorization.

Design DynamoDB From The Requests

Start with the operations the application must perform, not with a generic entity diagram. If every cart request knows the authenticated user ID, a partition key such as USER#42 can group that user's cart items, while a sort key identifies each item.

That supports direct operations such as “get this user's cart” and “update this item.” Generating unrelated IDs and scanning the table later is slower, more expensive, and harder to scale. A Global Secondary Index supports a genuinely different access pattern, but should not be added without one.

Evenly distributed partition keys matter. DynamoDB on-demand capacity can absorb changing traffic, but it cannot make one extremely hot key distribute itself.

Read deeper about access-pattern-first DynamoDB design

Retries Must Not Repeat The Business Action

Clients retry when a response is lost or times out. The first request may already have updated the cart even though the client never saw the response.

For operations that must happen once, the client sends an idempotency key—a stable operation ID reused on retry. Lambda records that ID and the result with a DynamoDB conditional write. The first request applies the change; a duplicate returns the known result instead of applying it again.

The atomic condition matters. A separate “check, then write” can race when two copies run at once.

Read deeper about idempotent writes

Separate The Capacity Boundaries

Incoming request rate, parallel function execution, and DynamoDB capacity are separate controls; capacity mode does not fix a hot key.
  • API Gateway throttling limits incoming request rate and bursts.
  • Lambda reserved concurrency controls how many function invocations can run simultaneously and can protect downstream systems.
  • DynamoDB capacity mode and key distribution control how storage traffic is served.

Automatic scaling at one layer can overwhelm the next. A Lambda function that scales rapidly can still exhaust a downstream database connection pool or third-party API.

For the API style, choose an HTTP API when its simpler, lower-cost feature set is enough. Choose a REST API when requirements need features such as API keys and usage plans, request validation, caching, transformations, private APIs, or direct AWS WAF association.

Keep Long Work Off The Synchronous Path

API Gateway's synchronous Lambda invocation returns success or failure to the caller; it is not an automatic durable job queue. If work may outlive a reasonable API response, durably hand it off:

Client request → validate and record → SQS / EventBridge / Step Functions → 202 Accepted

Use SQS for buffered work, EventBridge for event routing, or Step Functions for an ordered workflow. Return success only after the handoff is durable.

For recovery, DynamoDB point-in-time recovery preserves historical states. A restore creates a new table, so recovery still requires validation and a deliberate switch to the restored resource.

SAA Recognition And Traps

  • Spiky HTTP API with minimal server operations → API Gateway + Lambda is a natural request layer because both scale as managed services.
  • Known key-value access patterns at scale → DynamoDB, provided the partition key distributes traffic and directly supports the requests.
  • The same write may be retried → idempotency key + atomic conditional write, because retries can arrive after the first operation succeeded.
  • Long-running work behind an API → persist a message or workflow and return 202 Accepted; do not keep the synchronous request open indefinitely.
  • Recover an earlier DynamoDB state → PITR, followed by validation and adoption of the newly restored table.

Do not assume on-demand capacity fixes hot partitions, an API key authenticates a user, or serverless removes the need to design limits and retries.

One-Minute Review

API Gateway controls the HTTP entrance
↓
Lambda performs short request logic with an execution role
↓
DynamoDB serves key-based state designed from access patterns
↓
Idempotency makes retries safe
↓
Throttling, concurrency, and database capacity protect different boundaries
↓
Durable asynchronous services take over work that should not block the response

If you remember only one thing: managed scaling removes server-fleet work, not architecture work.

Finished reading?

Your reading history is saved in this browser so you can continue later.

Recommended Next

Event-Driven Order ProcessingAWS Architecture Scenarios22 min read

This applies the foundation mental models to a real architecture decision instead of a service inventory.

Optional exploration

These links add context, but they do not replace the recommended next lesson.

Arcflow Plus is coming — review drills, research breakdowns, more AI. Get one email at launch.

One email at launch. That's it.