Serverless Architecture Patterns: When (and When Not) to Go Serverless

Serverless computing promises no infrastructure management, automatic scaling, and pay-per-use pricing. The promise is real — for the right workloads. For the wrong workloads, serverless is more expensive, harder to debug, and introduces latency problems that don't exist with traditional compute.

Here's when serverless works, when it doesn't, and the patterns that deliver the most value.

What Serverless Actually Means

Serverless doesn't mean "no servers." It means you don't manage, provision, or think about servers. The cloud provider handles capacity, scaling, patching, and availability. You write functions, deploy them, and pay per execution.

Key properties:

• Event-driven: Functions execute in response to events (HTTP requests, queue messages, timer triggers, file uploads)
• Auto-scaling: From zero to thousands of concurrent executions, automatically
• Pay-per-use: You pay for execution time and memory, not idle capacity
• Stateless: Each function execution is independent. State must be stored externally.
• Ephemeral: Function instances are created and destroyed by the platform

Serverless Patterns That Work

Pattern 1: API Backend

Serverless functions behind an API Gateway handling REST or GraphQL requests.

When it works: APIs with variable traffic, low to moderate request volume, or traffic patterns with significant peaks and valleys.

Architecture: API Gateway → Function (business logic) → Database/external service

Azure: Azure Functions + API Management AWS: Lambda + API Gateway

Watch out for: Cold starts affecting API response time. Use provisioned concurrency or premium plans to eliminate cold starts for latency-sensitive APIs.

Pattern 2: Event Processing

Functions triggered by events from queues, streams, or pub-sub systems. Process each event independently.

When it works: Asynchronous workloads — order processing, notification delivery, data transformation, webhook handling.

Architecture: Event source (queue/stream) → Function → Target (database/API/storage)

Best practice: Design for idempotency. Events may be delivered more than once. Your function must handle duplicate processing safely.

Pattern 3: Scheduled Jobs

Functions triggered by a timer (cron schedule). Replace traditional scheduled tasks and batch jobs.

When it works: Report generation, data cleanup, health checks, integration syncs — any recurring task that runs for seconds to minutes.

Advantage over traditional cron: No server to maintain, automatic retry, integrated monitoring, and you don't pay for the 23 hours and 59 minutes when the job isn't running.

Pattern 4: File Processing Pipeline

Functions triggered by file uploads to blob storage. Process, transform, validate, or analyse the file.

When it works: Image resizing, document parsing, video transcoding, CSV import, PDF generation.

Architecture: Blob storage trigger → Processing function → Output storage + database update

Pattern 5: Real-Time Data Streaming

Functions processing events from Event Hubs, Kafka, or Kinesis streams.

When it works: IoT data ingestion, log processing, real-time analytics preprocessing, change data capture.

Watch out for: Throughput limits. Serverless functions have concurrency limits that may not match high-volume stream processing. For sustained high throughput, consider dedicated consumers (Kubernetes, container apps).

The Cold Start Reality

Cold starts — the latency penalty when a new function instance is created — are serverless's biggest practical limitation.

Mitigation strategies:

• Premium/provisioned plans: Keep instances warm (eliminates cold starts but adds baseline cost)
• Small deployment packages: Fewer dependencies = faster cold starts
• Language choice: Node.js and Python have the fastest cold starts
• HTTP keep-alive: Reuse connections to external services

Cost Modelling

When Serverless Is Cheaper

• Sporadic traffic (functions sitting idle most of the time)
• Variable workloads with unpredictable peaks
• Development and staging environments
• Low-volume APIs (under 1M requests/month)

When Serverless Is More Expensive

• Sustained, high-volume workloads (always running = always paying per-request pricing)
• Long-running processes (billed by execution time)
• High-memory workloads (memory pricing scales linearly)
• Workloads above ~3M requests/month (container-based alternatives become cheaper)

The Break-Even Calculation

Compare monthly cost:

• Serverless: (executions × execution time × memory) + (requests × request price)
• Container: (instance hours × instance price) + (load balancer)

At approximately 2-5 million requests per month with moderate execution time, containers (Azure Container Apps, ECS Fargate) become cheaper than serverless.

Vendor Lock-In

Serverless functions are inherently tied to the cloud provider's runtime, triggers, and ecosystem. Mitigation:

• Keep business logic separate from function handlers. The handler is a thin adapter; the logic is portable.
• Use standard interfaces where possible (HTTP triggers are portable; provider-specific triggers are not)
• Accept it for non-core workloads. The productivity benefits of serverless outweigh the lock-in risk for most event-processing and automation workloads.

Testing Serverless Applications

When to Migrate Away from Serverless

If your serverless workload grows to sustained high traffic, the migration path is well-established:

1. Extract business logic into standalone modules (should already be separate from handlers)
2. Containerise the application with the same logic
3. Deploy to container platform (Azure Container Apps, EKS, AKS)
4. Migrate triggers to container-native equivalents (queue consumers, HTTP endpoints)

This migration is straightforward if you followed the separation-of-concerns principle from the start.

---

Serverless architecture delivers enormous value for the right workloads. The key is matching the pattern to the problem. If you're evaluating serverless for your architecture, let's talk.