A serverless API, request by request

Read an item

Beginner

1. You open your profile. The app asks the API for your details.
2. The front desk asks the guard: is this person allowed in?
3. The guard checks your badge and says yes.
4. The front desk wakes up your code to handle the request.
5. Your code looks up your profile.
6. The database sends your profile back.
7. Your code packages up the answer.
8. Your profile appears. No server was sitting around waiting for you.

Practitioner

1. The client calls GET /profile with a token.
2. The gateway sends the token to the authorizer.
3. The token is valid; the request is allowed.
4. The gateway invokes the Lambda function.
5. The function reads the item from DynamoDB.
6. DynamoDB returns the item.
7. The function returns a JSON response.
8. The client receives the response.

Architect

1. HTTPS request with an Authorization bearer token.
2. Authorizer invoked (or the cached decision reused).
3. Allow decision with the caller’s identity in the request context.
4. Synchronous invoke; a warm environment is reused if one is free.
5. GetItem by partition key: single-digit milliseconds.
6. Item returned; consumed capacity is billed per request.
7. Function returns; the environment stays warm for the next call.
8. End to end, you paid only for this request’s compute and reads.

Cold start

Beginner

1. The first request in a while arrives.
2. Your code was asleep, so the cloud has to set it up first. That takes a moment.
3. Now your code can look up the data.
4. The data comes back.
5. Your code answers. It stays awake for a while in case more requests arrive.
6. You get your answer, just a little slower than usual.

Practitioner

1. A request arrives after a quiet period.
2. Lambda creates a new environment and loads your code: a cold start.
3. The function reads from the table.
4. The item is returned.
5. The function responds; the environment stays warm for reuse.
6. The response is a bit slower than a warm request.

Architect

1. Request arrives with no warm environments available.
2. Cold start: environment init plus your code’s init. Provisioned concurrency or SnapStart reduce it.
3. Init done; the handler runs and calls DynamoDB.
4. Item returned.
5. Warm environment kept for subsequent invokes.
6. Added latency is the init duration; it only affects a small share of requests.

Too many requests

Beginner

1. An app goes wild and sends far too many requests.
2. The front desk politely says “slow down” and doesn’t pass them on, which protects your code and your bill.

Practitioner

1. A client exceeds the API’s rate limit.
2. The gateway responds 429 Too Many Requests without invoking the function.

Architect

1. Requests exceed the stage’s rate and burst limits.
2. 429 returned at the edge; the backend and your bill are protected. Clients should retry with back-off.