EventBridge-Lambda Conditional Processing Pattern with CDK: Smart Event Routing Based on Business Logic

When developing serverless applications, you often encounter situations where "additional processing is needed only under specific conditions." For example, sending notifications only when a user's score is low, or executing additional review processes only for requests that don't meet certain thresholds.

Today, I'll introduce the EventBridge-Lambda conditional processing pattern that's useful in such scenarios, and explore when to use it, along with its advantages and limitations through real implementation examples.

Why Do We Need This Pattern?

Limitations of Traditional Approaches

In typical serverless APIs, all logic is processed within a single Lambda function:

User → API Gateway → Lambda → Response
                    ↓
            All business logic processing

However, this approach has several issues:

• Response Time Delays: Users have to wait for all processing to complete, leading to slower responses
• Unnecessary Processing: The entire logic must be executed even when conditions aren't met
• Scalability Constraints: All logic is concentrated in one function, making maintenance difficult

The EventBridge-Lambda Pattern Solution

The EventBridge-Lambda pattern solves these problems:

User → CloudFront → API Gateway → Lambda1 (Immediate Response)
                                    ↓ (When condition is met)
                            EventBridge → SQS → Lambda2 (Async Processing)

The core idea is "separation of fast response and safe follow-up processing."

Real Implementation Example: Score Validation System

Looking at the GitHub repository example, we implemented a score validation system:

Processing Flow

1. API Request: User calls API with a score parameter
2. Immediate Validation: Lambda1 validates the score and responds immediately
3. Conditional Event: Sends event to EventBridge if score is below 50 or missing
4. Safe Queuing: SQS safely stores the event
5. Async Processing: Lambda2 handles additional processing (notifications, logging, follow-up tasks, etc.)

Response Examples

High Score (≥50):

{
  "message": "Score validation passed",
  "score": 75,
  "status": "success",
  "timestamp": "2025-07-02T12:00:00.000Z"
}

Low Score (<50):

{
  "message": "Score validation failed - event sent to processing pipeline",
  "score": "25",
  "action": "EventBridge notification sent",
  "timestamp": "2025-07-02T12:00:00.000Z"
}

Core Architecture and Components

Architecture Components

CloudFront + CDN

• Global edge caching for fast loading
• Static asset optimization

API Gateway

• API endpoint management
• Query parameter forwarding optimization

Lambda1 (Primary Function)

• Immediate validation and response
• Conditional EventBridge calls

EventBridge

• Custom event bus usage
• Structured event format delivery

SQS

• Safe message storage
• Batch processing support
• Dead Letter Queue for failure handling

Lambda2 (Processor Function)

• Asynchronous follow-up processing
• Individual batch item failure handling

Special Design Principles

Fire-and-Forget Approach

// Non-blocking EventBridge call that doesn't affect user response
eventBridge.send(command).catch(error => {
  console.error('EventBridge failed:', error);
  // No impact on user response
});
return response; // Immediate response

Benefits of this approach:

• Fast response time (50-100ms)
• EventBridge failures don't affect user experience
• High throughput support

When Should You Use This Pattern?

Suitable Use Cases

Business Rule-Based Processing

• Credit score checks with follow-up actions
• Order validation with inventory updates
• Content review with approval processes

High-Throughput APIs + Conditional Follow-up Tasks

• Most requests require immediate response
• Additional processing needed only under specific conditions
• Users expect fast feedback

Systems Requiring Audit Trails

• Recording failed validations
• Event logging for compliance
• Notification and escalation processes

Event-Driven Microservices

• Loose coupling between services
• Scalable architecture
• Failure isolation

Unsuitable Cases

Real-time Response Requirements

• Real-time game interactions
• Chat message delivery
• Search autocomplete

Simple CRUD Operations

• Basic read/write operations
• Tasks requiring immediate result confirmation

Synchronous Processing Requirements

• Payment authorization (immediate approval/rejection needed)
• Login authentication (immediate success/failure response required)

Hands-on Practice

You can experience this firsthand through the GitHub repository:

Prerequisites

# Node.js 20+
# AWS CLI configured
# CDK CLI installation
npm install -g aws-cdk

Step-by-Step Practice

1. Clone Repository and Install Dependencies

git clone https://github.com/jaeneungsim/cdk-eventbridge-lambda-pattern.git
cd cdk-eventbridge-lambda-pattern
npm install

2. CDK Bootstrap (First time only)

cdk bootstrap

3. Deploy All Stacks

cdk deploy --all

4. System Testing After deployment, access the CloudFront URL:

• High score test: /api/score?score=75
• Low score test: /api/score?score=25
• Missing score test: /api/score

5. Direct API Testing

# High score - immediate response
curl "https://your-cloudfront-url/api/score?score=75"

# Low score - triggers event processing
curl "https://your-cloudfront-url/api/score?score=25"

# Missing score - triggers event processing
curl "https://your-cloudfront-url/api/score"

6. Monitoring Verification Check these metrics in CloudWatch:

• Lambda execution time
• EventBridge invocation count
• SQS queue depth
• Dead Letter Queue message count

7. Resource Cleanup bashcdk destroy --all

cdk destroy --all

Advantages and Considerations of This Pattern

Advantages

1. Fast Response Times

• Users receive immediate feedback
• Follow-up processing happens in the background

2. High Reliability

• Message guarantee through SQS
• Failure handling with Dead Letter Queue
• Failure isolation for each component

3. Scalability

• Independent scaling for each Lambda function
• Unlimited EventBridge throughput
• SQS batch processing optimization

4. Cost Efficiency

• Lambda2 executes only when needed
• Reduced origin requests through CloudFront caching
• No idle infrastructure costs

Considerations

1. Increased Complexity

• Need for coordination between multiple services
• Increased monitoring points
• Higher debugging complexity

2. Limited Immediate Feedback

• Can't immediately know follow-up processing results
• Need for separate status checking mechanisms

3. Eventual Consistency

• Event processing guarantees eventual consistency
• Unsuitable when real-time consistency is required

Extensibility

Based on this foundational pattern, you can add features such as:

Database Integration

• DynamoDB connections
• RDS integration
• Caching layer addition

Notification Systems

• Email notifications (SES)
• SMS notifications (SNS)
• Push notifications

File Processing

• S3 uploads
• Image resizing
• Document conversion

External Service Integration

• Third-party API calls
• Webhook delivery
• External system synchronization

Conclusion

The EventBridge-Lambda conditional processing pattern is a powerful architectural pattern that can achieve both "fast response and safe follow-up processing" - catching two birds with one stone.

This pattern is particularly useful when you have requirements such as:

• Providing fast feedback to users while
• Needing additional processing only under specific conditions and
• System reliability and scalability are important

Of course, it's not suitable for every situation. For real-time processing requirements or simple tasks, it might only increase complexity unnecessarily.

However, for modern serverless applications where business logic is complex and both user experience and system reliability are important, I believe this is a very valuable pattern.

If your next project has such requirements, I encourage you to consider this EventBridge-Lambda pattern.