Serverless Playbook

Serverless platforms are useful for event-driven, bursty, and integration-heavy workloads. They are not an excuse to skip architecture, observability, or ownership.

Good fit

Serverless is a good fit for:

• Event handlers and integration glue.
• Async processing triggered by queues, storage, or streams.
• Scheduled jobs with simple runtime needs.
• Burst workloads with low idle usage.
• Thin APIs where managed scaling is valuable.

Baseline architecture

Required defaults

Every serverless workload should define:

• Trigger source and event contract.
• Timeout, memory, and concurrency limits.
• Retry policy and dead-letter behavior.
• Idempotency strategy for repeated events.
• IAM permissions scoped to the function.
• Logs, metrics, traces, and correlation IDs.
• Deployment package size and runtime version.

Design practices

• Keep handlers thin and domain logic testable.
• Use queues to decouple slow or unreliable dependencies.
• Avoid synchronous chains of many functions.
• Store state in managed services, not in runtime assumptions.
• Use feature flags or routing controls for risky changes.

Watchouts

• Unbounded retries amplify incidents.
• Cold starts can become user-facing latency.
• Provider limits matter during bursts.
• Local mocks rarely capture IAM, retries, and event behavior fully.
• Per-function ownership gets messy without service-level grouping.