Designing a Scalable Serverless API on AWS Lambda

Serverless gets you a long way before you ever think about servers — but only if you structure it deliberately. Here is the pattern I reach for on most AWS projects.

One handler, one responsibility

Each Lambda should do exactly one thing. I keep business logic in plain, testable modules and let the handler be a thin adapter that parses the event and calls into them.

import type { APIGatewayProxyHandlerV2 } from 'aws-lambda'
import { createOrder } from '../services/orders'

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  const body = JSON.parse(event.body ?? '{}')
  const order = await createOrder(body)
  return {
    statusCode: 201,
    body: JSON.stringify(order),
  }
}

Model access patterns, not entities

DynamoDB rewards you for designing around how you read data. List your access patterns first, then design the partition and sort keys to serve them with single-digit-millisecond queries.

• Start from the queries, not the schema.
• Use a single-table design where it genuinely simplifies access.
• Add GSIs only for patterns you actually have.

Infrastructure as code from day one

CloudFormation (or the CDK) means every environment is reproducible and every change is reviewable. It is the single biggest lever for keeping a serverless codebase sane over time.