System Design (HLD)When to Use Serverless

When to Use Serverless

LevelAdvanced

Duration90 mins

TopicWhen to Use Serverless

4 / 5

Hybrid Architectures: Combining Serverless with Traditional Infrastructure

The Best of Both Worlds

The serverless vs. traditional infrastructure debate often presents a false dichotomy. In reality, most sophisticated production systems use hybrid architectures—strategically combining serverless functions with containers, persistent servers, and managed services to optimize each component for its specific workload characteristics.

Hybrid architectures acknowledge a practical truth: no single compute model is optimal for all workloads. Serverless excels at event-driven, variable-traffic, short-duration tasks. Containers excel at long-running services, connection-heavy workloads, and latency-sensitive operations. The art lies in drawing the boundaries correctly and integrating the components seamlessly.

This page provides a comprehensive framework for designing, implementing, and operating hybrid architectures that leverage the strengths of each compute model while mitigating their weaknesses.

What You Will Master

By the end of this page, you will understand hybrid architecture patterns and when to apply them, how to draw boundaries between serverless and traditional components, integration strategies for seamless communication between compute models, operational considerations for managing heterogeneous systems, and real-world hybrid architecture examples with implementation details.

Why Hybrid Architectures

Before diving into patterns, let's establish why hybrid architectures are not just common but often optimal.

The Workload Diversity Reality:

Real applications contain multiple workload types with different characteristics:

User-facing APIs need low latency and high availability
Background processing jobs need throughput and cost efficiency
Real-time features need persistent connections and state
Batch processing needs long execution and parallelism
Machine learning needs specialized hardware and memory

No single compute model optimizes for all these simultaneously.

Workload Characteristics and Optimal Compute
Workload Type	Key Requirement	Optimal Compute	Why
Event-driven webhooks	Variable traffic	Serverless	Pay-per-use, auto-scaling
User-facing API (P99 < 50ms)	Consistent latency	Containers/ECS	Warm instances, no cold starts
WebSocket server	Persistent connections	Containers/EC2	Long-lived connections needed
Image/video processing	CPU-intensive, bursty	Serverless	Parallel scaling, no idle cost
ML inference (latency-critical)	Low latency, GPU	EC2/EKS	GPU instances, warm models
Scheduled batch jobs	Cost efficiency	Serverless or Fargate Spot	No idle between runs
Real-time analytics	High throughput state	Flink/Kinesis	Managed stream processing

Strategic Advantages of Hybrid:

Hybrid Architecture Benefits

•Cost optimization — Use the most economical compute for each workload type. Don't overpay for serverless on steady-state or for servers on sporadic traffic.
•Performance optimization — Choose compute based on latency and throughput requirements. Don't force-fit latency-sensitive paths into serverless.
•Risk mitigation — Diversify compute models to avoid single points of failure or vendor dependencies.
•Incremental adoption — Migrate to serverless progressively, proving value before full commitment.
•Team flexibility — Allow teams to choose appropriate tools for their specific problems.

The Pragmatic Approach

Purist architectures (100% serverless or 100% containers) optimize for simplicity but sacrifice optimization. Pragmatic architectures accept the complexity of heterogeneous systems to achieve better outcomes. The key is managing that complexity effectively.

Hybrid Architecture Patterns

Several recurring patterns emerge in successful hybrid architectures. Understanding these patterns helps you recognize opportunities in your own systems.

Pattern 1: Serverless Frontend + Container Backend

Use serverless for the public-facing API layer (handling variable traffic, authentication, request routing) while maintaining container-based services for complex business logic or stateful operations.

Converting Mermaid diagram...

When to Use This Pattern:

API traffic is variable but backend services have steady internal load
Backend services require persistent connections (database pools, caches)
Latency-sensitive operations that can't tolerate cold starts
Complex services with large memory requirements or long startup times

Pattern 2: Core Containers + Serverless Extensions

Maintain core services as containers while implementing extensibility, integrations, and event handlers as serverless functions. Functions respond to events from the core system without affecting its reliability or performance.

hybrid-architecture-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
// Pattern 2: Core Container Service + Serverless Extensions
 
// Core Order Service (runs on ECS Fargate)
// - Handles order creation, updates, queries
// - Maintains database connections
// - Low latency for customer interactions
class OrderService {
    private db: Pool;
    private eventBridge: EventBridge;
    
    async createOrder(order: Order): Promise<OrderResult> {
        // Core transaction with database
        const result = await this.db.transaction(async (tx) => {
            const created = await tx.insert(orders).values(order);
            await tx.update(inventory).where(/*...*/);
            return created;
        });
        
        // Emit event for serverless extensions
        // Non-blocking - doesn't affect order creation latency
        await this.eventBridge.putEvents({
            Entries: [{
                Source: 'order-service',
                DetailType: 'OrderCreated',
                Detail: JSON.stringify({
                    orderId: result.id,
                    customerId: order.customerId,
                    items: order.items,
                    totalAmount: order.totalAmount,
                }),
            }],
        });
        
        return result;
    }
}
 
// Serverless Extension: Email Notification (Lambda)
// - Triggered by OrderCreated event
// - Scales independently
// - Failure doesn't affect order creation
export const sendOrderConfirmation: EventBridgeHandler<'OrderCreated', OrderEvent> = 
    async (event) => {
        const { orderId, customerId } = event.detail;
        
        const [order, customer] = await Promise.all([
            getOrder(orderId),
            getCustomer(customerId),
        ]);
        
        await ses.sendEmail({
            to: customer.email,
            template: 'order-confirmation',
            data: { order, customer },
        });
    };
 
// Serverless Extension: Analytics Update (Lambda)
// - Updates analytics data warehouse
// - Batched for efficiency
export const updateAnalytics: SQSHandler = async (event) => {
    const orders = event.Records.map(r => JSON.parse(r.body));
    
    await firehose.putRecordBatch({
        DeliveryStreamName: 'order-analytics',
        Records: orders.map(o => ({ Data: JSON.stringify(o) })),
    });
};
 
// Serverless Extension: Fraud Detection (Lambda)
// - Async fraud analysis
// - Can flag orders for review without blocking checkout
export const detectFraud: SNSHandler = async (event) => {
    const order = JSON.parse(event.Records[0].Sns.Message);
    
    const riskScore = await fraudModel.analyze(order);
    
    if (riskScore > FRAUD_THRESHOLD) {
        await flagOrderForReview(order.id, riskScore);
    }
};

Pattern 3: Serverless Processing + Container Serving

Use serverless for data processing, transformation, and preparation while using containers to serve the processed data with low latency.

Example: ML Pipeline

•Data Ingestion (Lambda) — Receives raw data events, validates, and queues for processing
•Feature Engineering (Lambda/Step Functions) — Transforms raw data into ML features, batched for efficiency
•Model Training (SageMaker/EC2) — Long-running training jobs on specialized instances
•Model Serving (ECS/EKS) — Low-latency inference API with warm model in memory
•Result Storage (Lambda) — Stores predictions, triggers downstream workflows

Drawing Boundaries Between Compute Models

The most critical decision in hybrid architecture is where to draw boundaries between serverless and traditional components. Poor boundaries create integration nightmares; good boundaries create clean, maintainable systems.

Boundary Decision Framework:

Boundary Decision Criteria
Criterion	Favor Serverless	Favor Containers	Boundary Indicator
Traffic Pattern	Variable, event-driven	Steady, predictable	Traffic variability changes
Latency Sensitivity	Tolerate 100ms+ variance	Require consistent <50ms	SLA requirements differ
State Requirements	Stateless or external state	In-memory state needed	State management complexity
Execution Duration	Seconds to minutes	Hours or persistent	Processing time boundaries
Connection Patterns	Short-lived, pooled	Persistent, bi-directional	Connection lifetime differs
Coupling Level	Loosely coupled, event-based	Tightly coupled, synchronous	Coupling requirements change

Good Boundary Examples:

Clean Boundaries

•Public API → Internal services (traffic variability changes)
•Request handler → Background workers (sync/async boundary)
•Core domain → Integrations (coupling differs)
•Data ingestion → Data serving (latency requirements differ)
•Write path → Read path (consistency requirements differ)

Poor Boundaries

•Splitting single transaction across compute models
•Synchronous chains of serverless → container → serverless
•Moving state across boundaries repeatedly
•Different compute for same traffic pattern
•Boundary based on team preference, not workload

The Event Bus Pattern:

Event buses (like Amazon EventBridge, Azure Event Grid, or Kafka) are often the ideal integration pattern at hybrid boundaries. They provide:

Decoupling — Producers and consumers don't know about each other's implementation
Schema evolution — Events can version independently of consumers
Replay capability — New consumers can process historical events
Observability — Central point for monitoring cross-boundary communication

Align Boundaries with Team Ownership

Where possible, align compute boundaries with team boundaries. A team that owns a serverless function shouldn't need to debug issues in a container service owned by another team. This reduces coordination overhead and improves accountability.

Integration Strategies

Seamless integration between serverless and traditional components requires careful attention to communication patterns, data consistency, and failure handling.

Synchronous Integration Patterns:

integration-patterns.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
// Pattern 1: Lambda → Container via Internal ALB
// Lambda invokes container service through private Application Load Balancer
 
// Lambda function
export const handler: APIGatewayProxyHandler = async (event) => {
    // Call container service via internal ALB
    const response = await fetch(
        process.env.ORDER_SERVICE_URL + '/orders',
        {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'X-Request-ID': event.requestContext.requestId,
            },
            body: event.body,
            // Set timeout less than Lambda timeout
            signal: AbortSignal.timeout(25000),
        }
    );
    
    if (!response.ok) {
        throw new Error(`Order service error: ${response.status}`);
    }
    
    return {
        statusCode: response.status,
        body: await response.text(),
    };
};
 
// Pattern 2: Lambda → Container via Service Discovery
// Using Cloud Map or Kubernetes service discovery
 
import { ServiceDiscovery } from '@aws-sdk/client-servicediscovery';
 
const sd = new ServiceDiscovery({});
 
async function discoverService(serviceName: string): Promise<string> {
    // Cache discovery results to avoid repeated lookups
    if (serviceCache.has(serviceName)) {
        return serviceCache.get(serviceName)!;
    }
    
    const instances = await sd.discoverInstances({
        NamespaceName: 'internal.mycompany.com',
        ServiceName: serviceName,
        HealthStatus: 'HEALTHY',
    });
    
    const instance = instances.Instances?.[0];
    if (!instance) throw new Error(`No healthy instances for ${serviceName}`);
    
    const url = `http://${instance.Attributes?.AWS_INSTANCE_IPV4}:${instance.Attributes?.port}`;
    serviceCache.set(serviceName, url);
    
    return url;
}
 
// Pattern 3: Container → Lambda via SDK invoke
// Container directly invokes Lambda function
 
import { LambdaClient, InvokeCommand } from '@aws-sdk/client-lambda';
 
class ContainerService {
    private lambda = new LambdaClient({});
    
    async processWithLambda(data: ProcessingRequest): Promise<ProcessingResult> {
        const response = await this.lambda.send(new InvokeCommand({
            FunctionName: 'data-processor',
            InvocationType: 'RequestResponse', // Sync invoke
            Payload: JSON.stringify(data),
        }));
        
        if (response.FunctionError) {
            throw new Error(`Lambda error: ${response.FunctionError}`);
        }
        
        return JSON.parse(
            new TextDecoder().decode(response.Payload)
        );
    }
    
    async triggerAsync(data: AsyncRequest): Promise<void> {
        await this.lambda.send(new InvokeCommand({
            FunctionName: 'async-handler',
            InvocationType: 'Event', // Async invoke
            Payload: JSON.stringify(data),
        }));
    }
}

Asynchronous Integration Patterns:

Async integration is often preferable in hybrid architectures—it decouples components and handles failure more gracefully.

Async Integration Options

•EventBridge — Schema-based event routing. Best for domain events across microservices. Supports filtering, transformation, and multiple targets.
•SQS — Point-to-point messaging. Best for work queues and task distribution. Supports DLQ, visibility timeout, and FIFO ordering.
•SNS — Pub/sub messaging. Best for fan-out to multiple consumers. Supports filtering and various subscription types.
•Kinesis — Stream processing. Best for ordered event streams requiring replay. Supports parallel consumers with sharding.
•Step Functions — Workflow orchestration. Best for complex multi-step processes spanning both compute models.

Watch for Synchronous Chains

Avoid long synchronous chains across hybrid boundaries (Lambda → Container → Lambda → Container). Each hop adds latency and failure risk. If you find yourself building such chains, reconsider your boundary placement or convert to async communication.

Data Consistency Across Boundaries

Maintaining data consistency across hybrid boundaries presents unique challenges. Transactions that span serverless and container components require careful design.

The Distributed Transaction Problem:

In hybrid architectures, a single logical operation might involve:

A Lambda function receiving a request
A container service updating a database
Another Lambda processing the result

Traditional database transactions don't span these boundaries. You need explicit patterns to maintain consistency.

Pattern 1: Saga with Compensation

Break operations into steps, each with a compensating action for rollback:

saga-pattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// Saga Pattern for Cross-Boundary Consistency
// Using Step Functions to orchestrate
 
// Step Functions state machine definition
const orderSaga = {
    Comment: "Order Processing Saga",
    StartAt: "ReserveInventory",
    States: {
        ReserveInventory: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:reserve-inventory",
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "ReservationFailed",
            }],
            Next: "ProcessPayment",
        },
        ProcessPayment: {
            Type: "Task",
            Resource: "arn:aws:states:::ecs:runTask.sync",
            Parameters: {
                Cluster: "payment-cluster",
                TaskDefinition: "payment-processor",
                LaunchType: "FARGATE",
            },
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "ReleaseInventory", // Compensate
            }],
            Next: "FulfillOrder",
        },
        FulfillOrder: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:fulfill-order",
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "RefundPayment", // Compensate
            }],
            End: true,
        },
        // Compensation handlers
        RefundPayment: {
            Type: "Task",
            Resource: "arn:aws:states:::ecs:runTask.sync",
            Parameters: {
                TaskDefinition: "payment-refund",
            },
            Next: "ReleaseInventory",
        },
        ReleaseInventory: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:release-inventory",
            Next: "SagaFailed",
        },
        ReservationFailed: { Type: "Fail", Cause: "Inventory reservation failed" },
        SagaFailed: { Type: "Fail", Cause: "Order saga failed after compensation" },
    },
};
 
// Each step must be idempotent for saga reliability
async function reserveInventory(event: InventoryRequest): Promise<ReservationResult> {
    // Check if already reserved (idempotency)
    const existing = await getReservation(event.orderId);
    if (existing) {
        return existing; // Already done, return existing result
    }
    
    // Create reservation with unique constraint
    return await createReservation(event);
}

Pattern 2: Outbox for Reliable Publishing

When a container service needs to reliably publish events for Lambda consumption:

Transactional Outbox Steps

•Container service performs database update and writes event to 'outbox' table in same transaction
•Separate process (or DynamoDB Streams/Change Data Capture) reads outbox table
•Events are published to EventBridge/SQS
•After successful publish, outbox record is marked as published (or deleted)
•Lambdas consume events with at-least-once guarantee
•Consumer idempotency handles duplicate deliveries

Embrace Eventual Consistency

Hybrid architectures often require eventual consistency. Design for it explicitly—implement idempotent consumers, handle out-of-order events, and build reconciliation processes. Fighting for strong consistency across hybrid boundaries creates brittleness and complexity.

Operating Hybrid Architectures

Hybrid architectures introduce operational complexity that must be explicitly managed. You're now operating two different compute paradigms with different tooling, monitoring approaches, and failure modes.

Unified Observability:

The biggest operational challenge is maintaining visibility across the hybrid boundary. A single request might traverse Lambda → Container → Lambda, and you need end-to-end traceability.

Unified Observability Requirements
Aspect	Serverless Approach	Container Approach	Unified Requirement
Tracing	X-Ray SDK	X-Ray daemon/agent	Same trace ID across boundaries
Logging	CloudWatch Logs	CloudWatch/Fluent Bit	Consistent log format, correlation IDs
Metrics	Lambda metrics + custom	Container/application metrics	Unified dashboard with both
Alerting	CloudWatch alarms	CloudWatch/PagerDuty	Joined alerts for request flows
Dashboards	Function-level views	Service-level views	Request flow visualization

unified-tracing.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// Unified Tracing Across Hybrid Boundaries
 
// In Lambda: Extract/propagate trace context
import { Tracer } from '@aws-lambda-powertools/tracer';
 
export const lambdaHandler = async (event: APIGatewayEvent) => {
    const tracer = new Tracer();
    
    // Add correlation to subsegment
    const subsegment = tracer.getSegment()?.addNewSubsegment('call-container-service');
    
    try {
        // Propagate trace header to container service
        const response = await fetch(process.env.CONTAINER_SERVICE_URL, {
            headers: {
                // X-Ray trace header propagation
                'X-Amzn-Trace-Id': process.env._X_AMZN_TRACE_ID!,
                // Custom correlation ID for logs
                'X-Correlation-ID': event.requestContext.requestId,
            },
        });
        
        return await response.json();
    } finally {
        subsegment?.close();
    }
};
 
// In Container: Continue the trace
import * as AWSXRay from 'aws-xray-sdk-core';
 
app.use((req, res, next) => {
    // Extract incoming trace context
    const traceHeader = req.headers['x-amzn-trace-id'];
    
    if (traceHeader) {
        // Continue the trace from Lambda
        const segment = AWSXRay.getSegment();
        if (segment) {
            segment.addAnnotation('correlationId', req.headers['x-correlation-id']);
        }
    }
    
    // Add correlation ID to all logs
    req.correlationId = req.headers['x-correlation-id'] || uuid();
    next();
});
 
// All subsequent calls automatically continue the trace
const http = AWSXRay.captureHTTPs(require('http'));

Deployment Coordination:

Hybrid architectures may require coordinated deployments when interfaces change:

Deployment Coordination Strategies

•Version APIs explicitly — Use versioned endpoints (v1, v2) to enable independent deployments
•Maintain backward compatibility — New versions must work with old consumers during rollout
•Deploy consumers before producers — New event consumers should deploy before producers emit new event types
•Use feature flags — Toggle new cross-boundary features independently of deployment
•Implement canary deployments — Gradually shift traffic to validate hybrid integrations

Blast Radius Awareness

In hybrid architectures, failures can cascade across boundaries. A container service overload can flood Lambda concurrency limits; a Lambda timeout can exhaust container connection pools. Design circuit breakers and bulkheads at every boundary.

Real-World Hybrid Architecture Examples

Let's examine complete hybrid architectures from real-world scenarios to understand how the patterns combine in practice.

Example 1: E-Commerce Platform

E-Commerce Hybrid Architecture
Component	Compute Model	Rationale
Product Catalog API	ECS Fargate	High traffic, needs consistent latency, complex queries
Search	ECS Fargate + OpenSearch	Heavy indexing, persistent connections to search cluster
Shopping Cart	Lambda + DynamoDB	Variable traffic, stateless with external state
Checkout API	ECS Fargate	Transaction-heavy, payment integrations need reliability
Order Processing	Step Functions + Lambda	Complex workflow, compensation logic required
Notification Service	Lambda + SES/SNS	Event-driven, highly variable volume
Analytics Pipeline	Lambda + Kinesis + Redshift	Event ingestion, batch processing to warehouse
Recommendation Engine	ECS + SageMaker	ML inference requires warm models, GPU
Image Processing	Lambda	Sporadic uploads, embarrassingly parallel
Admin Dashboard API	Lambda	Low traffic, cost-sensitive, acceptable latency

Example 2: Real-Time Analytics Platform

Converting Mermaid diagram...

Why This Architecture Works:

Ingestion is serverless — Variable event volumes, short processing per event, scales automatically
Stream processing is containerized — Flink requires persistent state, complex windowing, long-running processes
Storage writing is serverless — Event-driven, stateless writes, scales with throughput
Query serving is containerized — Consistent latency requirements, connection pooling to databases
Alerting is serverless — Event-driven, sporadic execution, independent scaling

Key Insight

Notice how boundaries align with workload characteristics, not arbitrary technical divisions. The hybrid architecture naturally emerges from analyzing each component's requirements rather than forcing a uniform compute model.

Migrating to Hybrid Architecture

Whether you're adding serverless to an existing system or introducing containers to a serverless-first architecture, migration requires careful planning.

Migration from Monolith to Hybrid:

Strangler Fig with Hybrid Target

•Analyze workload characteristics — Map each major function to optimal compute model based on traffic, latency, state requirements
•Identify initial candidates — Start with clearly suitable workloads: event handlers for serverless, core APIs for containers
•Build integration layer — Establish event bus and API routing infrastructure that supports both models
•Extract incrementally — Move one component at a time, validating integration at each step
•Establish operational parity — Ensure observability, deployment, and incident response work across both models
•Iterate based on learning — Initial compute assignments may prove wrong; be willing to refactor

Migration from Pure Serverless to Hybrid:

Sometimes organizations start serverless-first and discover certain workloads need traditional infrastructure:

Signs You Need to Add Containers

•Cold start SLAs violated — P99 latency requirements can't be met even with provisioned concurrency
•Cost curve inverted — Serverless costs exceed container alternatives at current volume
•Connection limits hit — Database or external service connections exhaust limits under load
•Execution duration exceeded — Processes consistently approach or hit time limits
•State management complexity — Externalizing state creates more complexity than it solves
•Debugging needs — Distributed serverless debugging is impeding velocity on critical components

Preserve Event-Driven Boundaries

When migrating from serverless to containers, preserve event-driven integration patterns even if the implementation changes. A Lambda converted to ECS can still consume SQS messages and emit EventBridge events. This maintains loose coupling and enables future flexibility.

Summary: Mastering Hybrid Architectures

We've comprehensively explored hybrid architectures—how to design them, where to draw boundaries, how to integrate components, and how to operate them effectively. Let's consolidate the key insights:

Key Takeaways

•Hybrid is often optimal — Real applications have diverse workloads; single compute models rarely optimize all of them
•Boundaries matter more than components — Well-placed boundaries create clean systems; poor boundaries create integration nightmares
•Align boundaries with workload characteristics — Traffic patterns, latency requirements, and state needs should drive boundary decisions
•Prefer async integration — Event-driven communication across boundaries provides resilience and decoupling
•Embrace eventual consistency — Cross-boundary strong consistency is often impossible; design for eventual consistency with idempotency
•Unify observability — Distributed tracing and correlation IDs are essential for debugging across boundaries
•Coordinate deployments carefully — Interface changes require coordinated rollouts with backward compatibility
•Migrate incrementally — Prove hybrid patterns on suitable workloads before broad adoption

What's Next:

With hybrid architectures understood, the final piece is migration strategies—how to move existing systems toward serverless (or hybrid) architecture in a controlled, low-risk manner. The next page provides a comprehensive framework for planning and executing serverless migrations.

Page Complete

You now possess a comprehensive understanding of hybrid architectures. You can identify opportunities for hybrid approaches, design appropriate boundaries, implement integration patterns, and operate heterogeneous systems. This pragmatic approach enables you to leverage the best of both serverless and traditional infrastructure.

4 / 5

Loading learning content...

System Design (HLD)When to Use Serverless

When to Use Serverless

LevelAdvanced

Duration90 mins

TopicWhen to Use Serverless

4 / 5

Hybrid Architectures: Combining Serverless with Traditional Infrastructure

The Best of Both Worlds

This page provides a comprehensive framework for designing, implementing, and operating hybrid architectures that leverage the strengths of each compute model while mitigating their weaknesses.

What You Will Master

Why Hybrid Architectures

Before diving into patterns, let's establish why hybrid architectures are not just common but often optimal.

The Workload Diversity Reality:

Real applications contain multiple workload types with different characteristics:

User-facing APIs need low latency and high availability
Background processing jobs need throughput and cost efficiency
Real-time features need persistent connections and state
Batch processing needs long execution and parallelism
Machine learning needs specialized hardware and memory

No single compute model optimizes for all these simultaneously.

Workload Characteristics and Optimal Compute
Workload Type	Key Requirement	Optimal Compute	Why
Event-driven webhooks	Variable traffic	Serverless	Pay-per-use, auto-scaling
User-facing API (P99 < 50ms)	Consistent latency	Containers/ECS	Warm instances, no cold starts
WebSocket server	Persistent connections	Containers/EC2	Long-lived connections needed
Image/video processing	CPU-intensive, bursty	Serverless	Parallel scaling, no idle cost
ML inference (latency-critical)	Low latency, GPU	EC2/EKS	GPU instances, warm models
Scheduled batch jobs	Cost efficiency	Serverless or Fargate Spot	No idle between runs
Real-time analytics	High throughput state	Flink/Kinesis	Managed stream processing

Strategic Advantages of Hybrid:

Hybrid Architecture Benefits

•Cost optimization — Use the most economical compute for each workload type. Don't overpay for serverless on steady-state or for servers on sporadic traffic.
•Performance optimization — Choose compute based on latency and throughput requirements. Don't force-fit latency-sensitive paths into serverless.
•Risk mitigation — Diversify compute models to avoid single points of failure or vendor dependencies.
•Incremental adoption — Migrate to serverless progressively, proving value before full commitment.
•Team flexibility — Allow teams to choose appropriate tools for their specific problems.

The Pragmatic Approach

Hybrid Architecture Patterns

Several recurring patterns emerge in successful hybrid architectures. Understanding these patterns helps you recognize opportunities in your own systems.

Pattern 1: Serverless Frontend + Container Backend

Converting Mermaid diagram...

When to Use This Pattern:

API traffic is variable but backend services have steady internal load
Backend services require persistent connections (database pools, caches)
Latency-sensitive operations that can't tolerate cold starts
Complex services with large memory requirements or long startup times

Pattern 2: Core Containers + Serverless Extensions

hybrid-architecture-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
// Pattern 2: Core Container Service + Serverless Extensions
 
// Core Order Service (runs on ECS Fargate)
// - Handles order creation, updates, queries
// - Maintains database connections
// - Low latency for customer interactions
class OrderService {
    private db: Pool;
    private eventBridge: EventBridge;
    
    async createOrder(order: Order): Promise<OrderResult> {
        // Core transaction with database
        const result = await this.db.transaction(async (tx) => {
            const created = await tx.insert(orders).values(order);
            await tx.update(inventory).where(/*...*/);
            return created;
        });
        
        // Emit event for serverless extensions
        // Non-blocking - doesn't affect order creation latency
        await this.eventBridge.putEvents({
            Entries: [{
                Source: 'order-service',
                DetailType: 'OrderCreated',
                Detail: JSON.stringify({
                    orderId: result.id,
                    customerId: order.customerId,
                    items: order.items,
                    totalAmount: order.totalAmount,
                }),
            }],
        });
        
        return result;
    }
}
 
// Serverless Extension: Email Notification (Lambda)
// - Triggered by OrderCreated event
// - Scales independently
// - Failure doesn't affect order creation
export const sendOrderConfirmation: EventBridgeHandler<'OrderCreated', OrderEvent> = 
    async (event) => {
        const { orderId, customerId } = event.detail;
        
        const [order, customer] = await Promise.all([
            getOrder(orderId),
            getCustomer(customerId),
        ]);
        
        await ses.sendEmail({
            to: customer.email,
            template: 'order-confirmation',
            data: { order, customer },
        });
    };
 
// Serverless Extension: Analytics Update (Lambda)
// - Updates analytics data warehouse
// - Batched for efficiency
export const updateAnalytics: SQSHandler = async (event) => {
    const orders = event.Records.map(r => JSON.parse(r.body));
    
    await firehose.putRecordBatch({
        DeliveryStreamName: 'order-analytics',
        Records: orders.map(o => ({ Data: JSON.stringify(o) })),
    });
};
 
// Serverless Extension: Fraud Detection (Lambda)
// - Async fraud analysis
// - Can flag orders for review without blocking checkout
export const detectFraud: SNSHandler = async (event) => {
    const order = JSON.parse(event.Records[0].Sns.Message);
    
    const riskScore = await fraudModel.analyze(order);
    
    if (riskScore > FRAUD_THRESHOLD) {
        await flagOrderForReview(order.id, riskScore);
    }
};

Pattern 3: Serverless Processing + Container Serving

Use serverless for data processing, transformation, and preparation while using containers to serve the processed data with low latency.

Example: ML Pipeline

•Data Ingestion (Lambda) — Receives raw data events, validates, and queues for processing
•Feature Engineering (Lambda/Step Functions) — Transforms raw data into ML features, batched for efficiency
•Model Training (SageMaker/EC2) — Long-running training jobs on specialized instances
•Model Serving (ECS/EKS) — Low-latency inference API with warm model in memory
•Result Storage (Lambda) — Stores predictions, triggers downstream workflows

Drawing Boundaries Between Compute Models

Boundary Decision Framework:

Boundary Decision Criteria
Criterion	Favor Serverless	Favor Containers	Boundary Indicator
Traffic Pattern	Variable, event-driven	Steady, predictable	Traffic variability changes
Latency Sensitivity	Tolerate 100ms+ variance	Require consistent <50ms	SLA requirements differ
State Requirements	Stateless or external state	In-memory state needed	State management complexity
Execution Duration	Seconds to minutes	Hours or persistent	Processing time boundaries
Connection Patterns	Short-lived, pooled	Persistent, bi-directional	Connection lifetime differs
Coupling Level	Loosely coupled, event-based	Tightly coupled, synchronous	Coupling requirements change

Good Boundary Examples:

Clean Boundaries

•Public API → Internal services (traffic variability changes)
•Request handler → Background workers (sync/async boundary)
•Core domain → Integrations (coupling differs)
•Data ingestion → Data serving (latency requirements differ)
•Write path → Read path (consistency requirements differ)

Poor Boundaries

•Splitting single transaction across compute models
•Synchronous chains of serverless → container → serverless
•Moving state across boundaries repeatedly
•Different compute for same traffic pattern
•Boundary based on team preference, not workload

The Event Bus Pattern:

Event buses (like Amazon EventBridge, Azure Event Grid, or Kafka) are often the ideal integration pattern at hybrid boundaries. They provide:

Decoupling — Producers and consumers don't know about each other's implementation
Schema evolution — Events can version independently of consumers
Replay capability — New consumers can process historical events
Observability — Central point for monitoring cross-boundary communication

Align Boundaries with Team Ownership

Integration Strategies

Seamless integration between serverless and traditional components requires careful attention to communication patterns, data consistency, and failure handling.

Synchronous Integration Patterns:

integration-patterns.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
// Pattern 1: Lambda → Container via Internal ALB
// Lambda invokes container service through private Application Load Balancer
 
// Lambda function
export const handler: APIGatewayProxyHandler = async (event) => {
    // Call container service via internal ALB
    const response = await fetch(
        process.env.ORDER_SERVICE_URL + '/orders',
        {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'X-Request-ID': event.requestContext.requestId,
            },
            body: event.body,
            // Set timeout less than Lambda timeout
            signal: AbortSignal.timeout(25000),
        }
    );
    
    if (!response.ok) {
        throw new Error(`Order service error: ${response.status}`);
    }
    
    return {
        statusCode: response.status,
        body: await response.text(),
    };
};
 
// Pattern 2: Lambda → Container via Service Discovery
// Using Cloud Map or Kubernetes service discovery
 
import { ServiceDiscovery } from '@aws-sdk/client-servicediscovery';
 
const sd = new ServiceDiscovery({});
 
async function discoverService(serviceName: string): Promise<string> {
    // Cache discovery results to avoid repeated lookups
    if (serviceCache.has(serviceName)) {
        return serviceCache.get(serviceName)!;
    }
    
    const instances = await sd.discoverInstances({
        NamespaceName: 'internal.mycompany.com',
        ServiceName: serviceName,
        HealthStatus: 'HEALTHY',
    });
    
    const instance = instances.Instances?.[0];
    if (!instance) throw new Error(`No healthy instances for ${serviceName}`);
    
    const url = `http://${instance.Attributes?.AWS_INSTANCE_IPV4}:${instance.Attributes?.port}`;
    serviceCache.set(serviceName, url);
    
    return url;
}
 
// Pattern 3: Container → Lambda via SDK invoke
// Container directly invokes Lambda function
 
import { LambdaClient, InvokeCommand } from '@aws-sdk/client-lambda';
 
class ContainerService {
    private lambda = new LambdaClient({});
    
    async processWithLambda(data: ProcessingRequest): Promise<ProcessingResult> {
        const response = await this.lambda.send(new InvokeCommand({
            FunctionName: 'data-processor',
            InvocationType: 'RequestResponse', // Sync invoke
            Payload: JSON.stringify(data),
        }));
        
        if (response.FunctionError) {
            throw new Error(`Lambda error: ${response.FunctionError}`);
        }
        
        return JSON.parse(
            new TextDecoder().decode(response.Payload)
        );
    }
    
    async triggerAsync(data: AsyncRequest): Promise<void> {
        await this.lambda.send(new InvokeCommand({
            FunctionName: 'async-handler',
            InvocationType: 'Event', // Async invoke
            Payload: JSON.stringify(data),
        }));
    }
}

Asynchronous Integration Patterns:

Async integration is often preferable in hybrid architectures—it decouples components and handles failure more gracefully.

Async Integration Options

•EventBridge — Schema-based event routing. Best for domain events across microservices. Supports filtering, transformation, and multiple targets.
•SQS — Point-to-point messaging. Best for work queues and task distribution. Supports DLQ, visibility timeout, and FIFO ordering.
•SNS — Pub/sub messaging. Best for fan-out to multiple consumers. Supports filtering and various subscription types.
•Kinesis — Stream processing. Best for ordered event streams requiring replay. Supports parallel consumers with sharding.
•Step Functions — Workflow orchestration. Best for complex multi-step processes spanning both compute models.

Watch for Synchronous Chains

Data Consistency Across Boundaries

Maintaining data consistency across hybrid boundaries presents unique challenges. Transactions that span serverless and container components require careful design.

The Distributed Transaction Problem:

In hybrid architectures, a single logical operation might involve:

A Lambda function receiving a request
A container service updating a database
Another Lambda processing the result

Traditional database transactions don't span these boundaries. You need explicit patterns to maintain consistency.

Pattern 1: Saga with Compensation

Break operations into steps, each with a compensating action for rollback:

saga-pattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// Saga Pattern for Cross-Boundary Consistency
// Using Step Functions to orchestrate
 
// Step Functions state machine definition
const orderSaga = {
    Comment: "Order Processing Saga",
    StartAt: "ReserveInventory",
    States: {
        ReserveInventory: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:reserve-inventory",
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "ReservationFailed",
            }],
            Next: "ProcessPayment",
        },
        ProcessPayment: {
            Type: "Task",
            Resource: "arn:aws:states:::ecs:runTask.sync",
            Parameters: {
                Cluster: "payment-cluster",
                TaskDefinition: "payment-processor",
                LaunchType: "FARGATE",
            },
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "ReleaseInventory", // Compensate
            }],
            Next: "FulfillOrder",
        },
        FulfillOrder: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:fulfill-order",
            Catch: [{
                ErrorEquals: ["States.ALL"],
                Next: "RefundPayment", // Compensate
            }],
            End: true,
        },
        // Compensation handlers
        RefundPayment: {
            Type: "Task",
            Resource: "arn:aws:states:::ecs:runTask.sync",
            Parameters: {
                TaskDefinition: "payment-refund",
            },
            Next: "ReleaseInventory",
        },
        ReleaseInventory: {
            Type: "Task",
            Resource: "arn:aws:lambda:...:release-inventory",
            Next: "SagaFailed",
        },
        ReservationFailed: { Type: "Fail", Cause: "Inventory reservation failed" },
        SagaFailed: { Type: "Fail", Cause: "Order saga failed after compensation" },
    },
};
 
// Each step must be idempotent for saga reliability
async function reserveInventory(event: InventoryRequest): Promise<ReservationResult> {
    // Check if already reserved (idempotency)
    const existing = await getReservation(event.orderId);
    if (existing) {
        return existing; // Already done, return existing result
    }
    
    // Create reservation with unique constraint
    return await createReservation(event);
}

Pattern 2: Outbox for Reliable Publishing

When a container service needs to reliably publish events for Lambda consumption:

Transactional Outbox Steps

•Container service performs database update and writes event to 'outbox' table in same transaction
•Separate process (or DynamoDB Streams/Change Data Capture) reads outbox table
•Events are published to EventBridge/SQS
•After successful publish, outbox record is marked as published (or deleted)
•Lambdas consume events with at-least-once guarantee
•Consumer idempotency handles duplicate deliveries

Embrace Eventual Consistency

Operating Hybrid Architectures

Unified Observability:

The biggest operational challenge is maintaining visibility across the hybrid boundary. A single request might traverse Lambda → Container → Lambda, and you need end-to-end traceability.

Unified Observability Requirements
Aspect	Serverless Approach	Container Approach	Unified Requirement
Tracing	X-Ray SDK	X-Ray daemon/agent	Same trace ID across boundaries
Logging	CloudWatch Logs	CloudWatch/Fluent Bit	Consistent log format, correlation IDs
Metrics	Lambda metrics + custom	Container/application metrics	Unified dashboard with both
Alerting	CloudWatch alarms	CloudWatch/PagerDuty	Joined alerts for request flows
Dashboards	Function-level views	Service-level views	Request flow visualization

unified-tracing.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// Unified Tracing Across Hybrid Boundaries
 
// In Lambda: Extract/propagate trace context
import { Tracer } from '@aws-lambda-powertools/tracer';
 
export const lambdaHandler = async (event: APIGatewayEvent) => {
    const tracer = new Tracer();
    
    // Add correlation to subsegment
    const subsegment = tracer.getSegment()?.addNewSubsegment('call-container-service');
    
    try {
        // Propagate trace header to container service
        const response = await fetch(process.env.CONTAINER_SERVICE_URL, {
            headers: {
                // X-Ray trace header propagation
                'X-Amzn-Trace-Id': process.env._X_AMZN_TRACE_ID!,
                // Custom correlation ID for logs
                'X-Correlation-ID': event.requestContext.requestId,
            },
        });
        
        return await response.json();
    } finally {
        subsegment?.close();
    }
};
 
// In Container: Continue the trace
import * as AWSXRay from 'aws-xray-sdk-core';
 
app.use((req, res, next) => {
    // Extract incoming trace context
    const traceHeader = req.headers['x-amzn-trace-id'];
    
    if (traceHeader) {
        // Continue the trace from Lambda
        const segment = AWSXRay.getSegment();
        if (segment) {
            segment.addAnnotation('correlationId', req.headers['x-correlation-id']);
        }
    }
    
    // Add correlation ID to all logs
    req.correlationId = req.headers['x-correlation-id'] || uuid();
    next();
});
 
// All subsequent calls automatically continue the trace
const http = AWSXRay.captureHTTPs(require('http'));

Deployment Coordination:

Hybrid architectures may require coordinated deployments when interfaces change:

Deployment Coordination Strategies

•Version APIs explicitly — Use versioned endpoints (v1, v2) to enable independent deployments
•Maintain backward compatibility — New versions must work with old consumers during rollout
•Deploy consumers before producers — New event consumers should deploy before producers emit new event types
•Use feature flags — Toggle new cross-boundary features independently of deployment
•Implement canary deployments — Gradually shift traffic to validate hybrid integrations

Blast Radius Awareness

Real-World Hybrid Architecture Examples

Let's examine complete hybrid architectures from real-world scenarios to understand how the patterns combine in practice.

Example 1: E-Commerce Platform

E-Commerce Hybrid Architecture
Component	Compute Model	Rationale
Product Catalog API	ECS Fargate	High traffic, needs consistent latency, complex queries
Search	ECS Fargate + OpenSearch	Heavy indexing, persistent connections to search cluster
Shopping Cart	Lambda + DynamoDB	Variable traffic, stateless with external state
Checkout API	ECS Fargate	Transaction-heavy, payment integrations need reliability
Order Processing	Step Functions + Lambda	Complex workflow, compensation logic required
Notification Service	Lambda + SES/SNS	Event-driven, highly variable volume
Analytics Pipeline	Lambda + Kinesis + Redshift	Event ingestion, batch processing to warehouse
Recommendation Engine	ECS + SageMaker	ML inference requires warm models, GPU
Image Processing	Lambda	Sporadic uploads, embarrassingly parallel
Admin Dashboard API	Lambda	Low traffic, cost-sensitive, acceptable latency

Example 2: Real-Time Analytics Platform

Converting Mermaid diagram...

Why This Architecture Works:

Ingestion is serverless — Variable event volumes, short processing per event, scales automatically
Stream processing is containerized — Flink requires persistent state, complex windowing, long-running processes
Storage writing is serverless — Event-driven, stateless writes, scales with throughput
Query serving is containerized — Consistent latency requirements, connection pooling to databases
Alerting is serverless — Event-driven, sporadic execution, independent scaling

Key Insight

Migrating to Hybrid Architecture

Whether you're adding serverless to an existing system or introducing containers to a serverless-first architecture, migration requires careful planning.

Migration from Monolith to Hybrid:

Strangler Fig with Hybrid Target

•Analyze workload characteristics — Map each major function to optimal compute model based on traffic, latency, state requirements
•Identify initial candidates — Start with clearly suitable workloads: event handlers for serverless, core APIs for containers
•Build integration layer — Establish event bus and API routing infrastructure that supports both models
•Extract incrementally — Move one component at a time, validating integration at each step
•Establish operational parity — Ensure observability, deployment, and incident response work across both models
•Iterate based on learning — Initial compute assignments may prove wrong; be willing to refactor

Migration from Pure Serverless to Hybrid:

Sometimes organizations start serverless-first and discover certain workloads need traditional infrastructure:

Signs You Need to Add Containers

•Cold start SLAs violated — P99 latency requirements can't be met even with provisioned concurrency
•Cost curve inverted — Serverless costs exceed container alternatives at current volume
•Connection limits hit — Database or external service connections exhaust limits under load
•Execution duration exceeded — Processes consistently approach or hit time limits
•State management complexity — Externalizing state creates more complexity than it solves
•Debugging needs — Distributed serverless debugging is impeding velocity on critical components

Preserve Event-Driven Boundaries

Summary: Mastering Hybrid Architectures

Key Takeaways

•Hybrid is often optimal — Real applications have diverse workloads; single compute models rarely optimize all of them
•Boundaries matter more than components — Well-placed boundaries create clean systems; poor boundaries create integration nightmares
•Align boundaries with workload characteristics — Traffic patterns, latency requirements, and state needs should drive boundary decisions
•Prefer async integration — Event-driven communication across boundaries provides resilience and decoupling
•Embrace eventual consistency — Cross-boundary strong consistency is often impossible; design for eventual consistency with idempotency
•Unify observability — Distributed tracing and correlation IDs are essential for debugging across boundaries
•Coordinate deployments carefully — Interface changes require coordinated rollouts with backward compatibility
•Migrate incrementally — Prove hybrid patterns on suitable workloads before broad adoption

What's Next:

Page Complete

4 / 5