Medium · 8 steps · ~40 min

Design a serverless API on AWS

Build an API with no servers, and learn which quotas decide how far it goes.

A mobile app needs a backend for profiles, orders and settings. You will build it with no servers to patch: API Gateway receives requests, Lambda runs the code and DynamoDB stores the data. Each service scales by itself, but each also has a quota, and past a quota requests are throttled rather than queued.

Same problem as Mobile app backendsInternal toolsWebhook receivers

This lab uses real AWS services. Limits are AWS's documented default quotas; figures AWS does not publish are marked as assumptions on each component. See every source and assumption.

How it works

• API Gateway throttles at 10,000 requests/s per account and Region by default, with a burst bucket of 5,000. Beyond that clients receive HTTP 429.
• Lambda's default is 1,000 concurrent executions per Region. Lambda also caps requests per second at 10 times your account concurrency, so 10,000 requests/s by default, and concurrency itself equals requests per second times average duration.
• DynamoDB allows 40,000 request units/s per table by default, but only 1,000 writes and 3,000 reads a second for any single partition.
• Limits come from AWS documentation (default quotas in us-east-1). Where AWS publishes no figure, such as how many requests a container or database handles, the lab states its assumption on the component.

What you'll build

1. An API with no servers at 500 requests a second
2. The same design near its quotas at 9,000
3. A plan for a launch that exceeds the quotas
4. CloudFront in front while quota increases are processed
5. A DynamoDB key that does not create a hot partition

Steps

1. 1Serve 500 requests/s
2. 2Run at 9,000 requests/s
3. 3Plan for 14,000 requests/s
4. 4Shield the API with CloudFront
5. 5A write-heavy launch
6. 6A hot partition
7. 7When the function gets slower
8. 8Synchronous or asynchronous