Overview

After stabilising production in Part A, the next challenge was preventing the same problems from reappearing as new Lambdas were created. Every new function shipped with a slightly different timeout, retry setup, logging format, and alarm strategy. Reliability still depended on who copy-pasted which snippet.

The answer was to turn the battle-tested fixes into named patterns: small, documented recipes that include infrastructure, configuration, and conventions. Engineers don’t start from a blank Lambda — they choose a pattern that matches the use case and get sensible defaults out of the box.

Patterns index

Quick jump to the core recipes in this library:

• 01 · Guardrail-First Lambda
• 02 · Timeouts & Retries
• 03 · DLQ & Parking-Lot
• 04 · Observability-First Logging
• 05 · CI/CD Template Guardrails

Pattern 01 — Guardrail-First Lambda

Every Lambda starts from a base module that includes opinionated defaults: runtime, memory, timeout floor, concurrency limit, and security posture (VPC configuration, least-privilege IAM role, and secrets access pattern).

• ✅ Timeouts and memory sized for the workload family
• ✅ Reserved concurrency to protect downstream systems
• ✅ Single place to update defaults when requirements or best practices evolve

When to use: always. This pattern is the starting point for any new Lambda in the platform.

Pattern 02 — Explicit Timeouts & Retries

Instead of relying on default timeouts, each Lambda declares its latency expectations and failure behaviour using a standard template. That template wires in:

• Max execution time and safety margin
• Retry policy tuned to idempotency and downstream SLAs
• Fallback routing for “do not retry” error classes

When to use: any Lambda calling external systems (databases, APIs, message brokers) or doing non-idempotent work.

Pattern 03 — Dead-Letter Queue & Parking-Lot

Failures shouldn’t disappear into logs. This pattern standardises how we capture and replay broken events:

• One DLQ per workflow, not per function, for simpler operations
• Structured payloads including error type, stack, and correlation IDs
• Simple replay tooling (CLI / console) so operators can re-drive fixed events safely

When to use: event-driven Lambdas processing queues, streams, or scheduled jobs.

Pattern 04 — Observability-First Logging

The logging pattern ensures every Lambda emits consistent, machine-parsable telemetry:

• Structured JSON logs with request IDs and user / tenant context
• Standard metric dimensions (service, operation, result)
• Opinionated alarms for error rate, latency, and throttling — created automatically with the function

When to use: all production Lambdas; non-prod can inherit a lighter version of the same pattern.

Pattern 05 — CI/CD Template Guardrails

Finally, the library ships with CI/CD templates that bake these patterns into the delivery pipeline. Engineers don’t wire alarms or DLQs by hand; the template wires them based on the selected pattern.

• Workflow templates for “event processor”, “API handler”, and “cron worker”
• Built-in checks for missing alarms, DLQs, or timeouts
• Automated tagging for cost, ownership, and incident routing

Outcomes

With the patterns library in place, reliability stopped depending on who happened to be on call during the last incident. New Lambdas launched with the same guardrails as the ones we had already hardened, and operational surprises dropped sharply.

Most importantly, the library gave the team a shared language: engineers could say “this workflow is using the DLQ + parking-lot pattern” and everyone knew what that implied for behaviour, alerts, and run-books.