Serverless Architecture Patterns#

Serverless means you don't manage servers. You write functions, deploy them, and the platform handles scaling, availability, and infrastructure. Pay per invocation, not per hour.

But serverless isn't free — there are trade-offs. This guide covers when it works, when it doesn't, and the architecture patterns that matter.

What Serverless Actually Means#

Not "no servers" — the servers exist, you just don't manage them.

Serverless Platforms#

Architecture Patterns#

1. Serverless API#

Replace a traditional API server with functions:

Client → API Gateway → Lambda /users → DynamoDB
                     → Lambda /orders → DynamoDB + SQS
                     → Lambda /payments → Stripe API

Pros: Auto-scales to zero, no idle cost, per-request billing Cons: Cold starts affect latency, 15-minute max execution (Lambda) Best for: APIs with variable traffic, webhook handlers, MVPs

2. Event Processing Pipeline#

React to events from queues, databases, or file uploads:

S3 upload → Lambda (resize image) → S3 (thumbnails)
SQS message → Lambda (process order) → DynamoDB
DynamoDB Stream → Lambda (sync to Elasticsearch)
CloudWatch Event → Lambda (daily cleanup job)

This is where serverless shines. No idle servers waiting for events.

3. Edge Functions (Global Low-Latency)#

Run code at the CDN edge, closest to the user:

User (Tokyo) → Edge PoP (Tokyo) → Worker executes in < 5ms
User (NYC)   → Edge PoP (NYC)   → Worker executes in < 5ms

Use cases:

• A/B testing (decide variant at the edge)
• Authentication (validate JWT before hitting origin)
• Geolocation-based content
• Request rewriting / routing
• Personalization without origin round-trip

Tools: Cloudflare Workers, Vercel Edge Functions, Deno Deploy

4. Backend for Frontend (BFF)#

One serverless function per client type:

Mobile App → Lambda (mobile BFF) → aggregates 3 services → response
Web App    → Lambda (web BFF)    → aggregates 5 services → response
Internal   → Lambda (admin BFF)  → aggregates all services → response

Each BFF tailors the response shape for its client.

5. Fan-Out / Fan-In#

Process work in parallel, then aggregate:

Request → Orchestrator Lambda
              → Worker Lambda 1 (process chunk 1) → results
              → Worker Lambda 2 (process chunk 2) → results
              → Worker Lambda 3 (process chunk 3) → results
          ← Aggregator Lambda ← combines results → response

Use cases: Map-reduce, batch processing, parallel API calls

6. Scheduled Tasks (Cron)#

CloudWatch Events (every 5 min) → Lambda (health check)
EventBridge (daily at midnight) → Lambda (generate reports)
Vercel Cron → Edge Function (revalidate cache)

Replace cron servers with event-triggered functions.

The Cold Start Problem#

When a function hasn't been called recently, the platform must:

1. Provision a container/isolate
2. Load your code
3. Initialize dependencies
4. Execute your function

Mitigation strategies:

• Provisioned concurrency (Lambda) — keep N instances warm ($$$)
• Edge functions — V8 isolates start in < 5ms (no container)
• Smaller bundles — less code = faster cold start
• Avoid Java/.NET for latency-sensitive paths

When NOT to Use Serverless#

Cost Comparison#

Low traffic (10K requests/day)#

High traffic (10M requests/day)#

Rule of thumb: Serverless wins at low/variable traffic. Containers win at consistent high traffic.

Serverless + Traditional Hybrid#

Most production systems use both:

Client → CloudFront (CDN + Edge Functions for auth/routing)
       → API Gateway → Lambda (API handlers)
       → ECS Fargate (long-running workers, WebSocket)
       → Lambda (event processing from SQS/S3/DynamoDB)

Use serverless for event-driven and variable-traffic workloads. Use containers for predictable, long-running services.

Generate a serverless architecture →

Summary#

1. Serverless = no server management, auto-scale, pay per use
2. Edge functions for global low-latency (< 5ms cold start)
3. Lambda for event processing and variable-traffic APIs
4. Cold starts are the main trade-off — use edge or provisioned concurrency
5. Don't go 100% serverless — hybrid is usually the right call
6. Cost — cheaper at low traffic, more expensive at sustained high traffic

---

Design serverless architectures at codelit.io — generate interactive diagrams with cost estimates and infrastructure exports (Terraform, Pulumi, Railway).