Serverless Architecture Patterns: Beyond Hello World

Beyond the Hello World

Serverless tutorials make it look easy: write a function, deploy, done. Production serverless is harder. Cold starts impact user experience. Costs can spiral without controls. Debugging distributed functions is challenging. State management requires rethinking.

This guide covers patterns that separate production serverless from demo serverless.

Cold Start Reality

Cold starts happen when a new function instance must be created. The delay varies: milliseconds for lightweight runtimes (Node, Python), seconds for heavier ones (Java, .NET).

Mitigation strategies:

Provisioned concurrency: Pre-warm instances that are always ready. You pay for idle time, but latency is consistent. Essential for latency-sensitive APIs.

Keep warm with scheduling: Ping functions periodically to prevent shutdown. Cheaper than provisioned concurrency but less reliable under load.

Optimize initialization: Move heavy operations outside the handler. Database connections, SDK clients, and configuration loading should happen once per instance, not per invocation.

Choose runtime wisely: Node.js and Python cold-start faster than Java or .NET. Consider GraalVM native images for Java if cold starts matter.

Event Processing Patterns

Serverless excels at event-driven workloads. Design for these patterns:

Batch processing: SQS, Kinesis, and DynamoDB Streams deliver batches. Process in parallel, return failures for retry. Partial batch responses let you succeed on some items while retrying others.

Fan-out: One event triggers multiple functions. Use SNS for fire-and-forget, Step Functions for orchestrated workflows.

Event filtering: Filter at the source. EventBridge rules, SQS message filtering, and Lambda event filtering reduce unnecessary invocations.

Idempotency: Events can be delivered multiple times. Design handlers to produce the same result regardless of how many times they run.

State Management

Functions are stateless by default. State options:

DynamoDB: Fast, scalable, pay-per-request pricing aligns with serverless model

S3: Large objects, files, data lakes

ElastiCache: Sub-millisecond access for session data

Step Functions: Workflow state for multi-step processes

Avoid /tmp for persistent state - it does not survive instance recycling.

Cost Optimization Strategies

Serverless can be cheap or expensive depending on usage patterns:

Right-size memory: More memory means more CPU. Sometimes 256MB at 100ms costs less than 128MB at 250ms. Profile and optimize.

ARM architecture: Graviton processors are 20% cheaper with comparable performance. Most Node.js and Python code works without changes.

Batch requests: One invocation processing 100 items is cheaper than 100 invocations processing 1 item each.

Reserved concurrency: Caps maximum instances. Prevents runaway costs from traffic spikes or infinite loops.

Monitor and alert: Set billing alarms. Unexpected costs often indicate bugs or attacks.

Best Practices

Single responsibility: One function, one purpose

Externalize state: Databases, not local storage

Set timeouts: Prevent runaway executions

Structured logging: JSON for analysis and correlation

Use layers: Share code without duplication

Test locally: SAM, LocalStack for faster iteration