Multi-Event Triggers for Serverless Computing

Basic Information

• Paper ID: 2505.21199
• Title: Multi-Event Triggers for Serverless Computing
• Authors: Natalie Carl, Trever Schirmer, Niklas Kowallik, Joshua Adamek, Tobias Pfandzelter, Sergio Lucia, David Bermbach
• Classification: cs.DC (Distributed, Parallel, and Cluster Computing)
• Publication Date: arXiv:2505.21199v3 cs.DC 11 Oct 2025
• Paper Link: https://arxiv.org/abs/2505.21199

Abstract

Function-as-a-Service (FaaS) is an event-driven serverless cloud computing model in which small stateless functions are invoked in response to events such as HTTP requests, new database entries, or messages. Current FaaS platforms assume that each function invocation corresponds to a single event. However, from an application perspective, it is desirable for functions to respond to collections of different event types or to be invoked only on every nth event. To achieve this, functions require additional state management (e.g., databases) and custom logic to determine whether trigger conditions are satisfied. This paper proposes multi-event triggers (MET), which enable the specification of complex function invocation conditions. Evaluation results demonstrate that in an event detection use case, this approach reduces event-to-invocation latency by 62.5%, and the system can handle over 300,000 requests/second on limited hardware.

Research Background and Motivation

Problem Definition

Current FaaS platforms have a fundamental limitation: each function invocation can only respond to a single event. However, practical applications frequently require more complex triggering patterns:

1. Fan-in/Join Pattern: Requires collecting multiple different types of events before triggering a function
2. Count-based Triggering: Triggers a function only after receiving n events
3. Complex Conditional Triggering: Based on AND/OR combinations of event types and quantities

Limitations of Existing Approaches

Currently, implementing multi-event triggering requires:

• Maintaining state within functions using external databases
• Invoking functions for every event, with most invocations serving only to update state rather than execute business logic
• Resulting in unnecessary resource consumption, increased latency, and higher costs
• Violating the FaaS platform design principle that the platform should handle event distribution and function invocation

Research Motivation

To maintain the advantages of the FaaS programming model (loose coupling, automatic scaling, ease of development), multi-event triggering logic should be integrated into the FaaS platform's triggering mechanism rather than requiring application developers to handle it manually.

Core Contributions

1. Proposes the Multi-Event Trigger Concept: Extends the FaaS function triggering mechanism to support complex triggering conditions based on event collections
2. Designs the MET Engine Architecture: Proposes a multi-event trigger engine design that can be integrated into existing FaaS platforms
3. Develops a Prototype System: Implements a proof-of-concept prototype demonstrating the feasibility of the design
4. Performance Evaluation: Validates the potential and performance of multi-event triggers in an event detection use case

Methodology Details

Task Definition

Multi-event triggers allow developers to define complex triggering rules that specify when functions should be invoked based on specific event combination conditions. Triggering rules consist of event types and corresponding counts, supporting combinations of AND and OR conditions.

Formal Definition of Triggering Rules

<rule> ::= <count> ":" <type> |
           <condition> "(" <rule> "," <rule> ")"
<condition> ::= "AND" | "OR"
<count> ::= regexp:[0-9]+
<type> ::= regexp:[a-zA-Z]+

MET Engine Architecture

Overall Design

The MET engine comprises two independently scalable components:

1. Dispatcher:
   • Receives events from the load balancer
   • Forwards events to appropriate invokers
2. Invoker:
   • Handles triggering logic
   • Creates trigger handlers for each MET
   • Maintains trigger sets for each event type
   • Checks whether triggering rules are satisfied and invokes functions

Communication Mechanism

• Dispatchers and invokers use broker-less publish/subscribe messaging
• Invokers subscribe to dispatcher events based on event types in their handled triggering rules
• Supports distributed deployment in both multi-node and single-machine setups

Scalability Design

• Increases the number of handleable triggers by deploying additional invokers
• Supports trigger partitioning for further increased processing capacity
• Target processing capacity: high 10^5 to low 10^5 requests/second (reference: AWS Lambda single AZ load)

Technical Innovations

1. Native Platform Support: Integrates multi-event logic into the triggering mechanism rather than the application layer
2. Optimized State Management: Centralizes state management in the triggering engine, avoiding function invocation for every event
3. Modular Architecture: Supports independent scaling of dispatcher and invoker components
4. Trigger Partitioning: Enables higher concurrent processing capacity through partitioning

Experimental Setup

Prototype Implementation

• Programming Language: Go for dispatcher and invoker implementation
• Deployment Platform: Kubernetes cluster (Google Kubernetes Engine)
• Message Passing: ZeroMQ library
• Load Balancing: Kubernetes LoadBalancer service
• Function Platform: Any HTTP-capable FaaS platform

Evaluation Scenarios

Experiment 1: Latency Testing

• Use Case: Data center event detection application
• Sensor Types: Temperature, packet loss rate, power consumption
• Triggering Rule: OR(AND(5:packetLoss, 1:temperature), 1:powerConsumption)
• Baseline Comparison: Manual state management using PostgreSQL database
• Load Generation: k6 load generator, 30-minute test

Experiment 2: Concurrent Request Testing

• Hardware Configuration:
  • Single node: c7i.2xlarge (8 vCPU, 16 GiB)
  • Four nodes: 4×c7i.2xlarge
  • Load generator: c7i.16xlarge (64 vCPU, 128 GiB)
• Triggering Rule: 3:a (trigger once every three events)
• Load: 1,024-byte random character payload

Experiment 3: Concurrent Trigger Testing

• Hardware: c7i.large (4 vCPU, 8 GiB)
• Triggering Rule: AND(2:a, 2:b), up to 1,024 concurrent triggers
• Load: 128 virtual users, 1,024-byte payload

Experimental Results

Main Results

Latency Performance Improvement

• Event-to-invocation latency reduction of 62.5% (median)
• Function invocation count reduced by 4.3× (compared to baseline invoking function for every event)
• Significantly reduced overhead from unnecessary function invocations

Throughput Performance

• Single-node configuration: Maximum 131,012.7 requests/second (4,096 virtual users)
• Four-node configuration: Maximum 313,154.81 requests/second (64 virtual users)
• Throughput scales linearly with concurrent requests up to 2^11 requests

Concurrent Trigger Performance

• Single trigger: 236,601.77 requests/second
• 8 triggers: 63,717.27 requests/second
• 1,024 triggers: 883.67 requests/second
• Performance primarily limited by CPU; optimization through parallelized trigger rule checking

Experimental Findings

1. Significant Latency Improvement: MET engine significantly reduces event processing latency compared to manual state management approaches
2. Good Scalability: System demonstrates good horizontal scaling capability
3. High Throughput: Achieves processing capacity required by large-scale FaaS platforms on limited hardware
4. Concurrency Limitations: Single invoker has CPU-limited concurrent trigger capacity, but can be mitigated through partitioning

Related Work

State Management Solutions

• Crucial: Distributed shared object layer
• Cloudburst: Integrated auto-scaling key-value store
• Boki: Log API-based state persistence
• Faasm: Memory region sharing for WebAssembly runtime

Workflow Orchestration

• TriggerFlow: Custom workflow engine based on Knative
• FaaSFlow: Distributed workflow scheduling across FaaS worker nodes
• DataFlower: Function scheduling based on data availability

Distinction from Existing Solutions

This paper's approach is unique in that functions are only invoked when complete triggering conditions are satisfied, reducing unnecessary executions and avoiding the need for locking mechanisms to handle race conditions.

Conclusions and Discussion

Main Conclusions

1. Multi-event triggers effectively address the lack of native fan-in support in FaaS platforms
2. MET engine significantly reduces invocation latency and resource consumption
3. System demonstrates performance capability for deployment in large-scale cloud environments
4. Maintains core advantages of the serverless paradigm (loose coupling, automatic scaling, minimal operational overhead)

Limitations

1. Geographic Distribution Constraints: Current design focuses on multi-node single-datacenter setups, unsuitable for geographically distributed multi-event triggers
2. NOT Condition Unsupported: Cannot guarantee that certain event types have not been received in distributed environments, thus NOT conditions are unsupported
3. Event Synchronization Issues: Requires addressing event loss and synchronization issues caused by sensor failures

Future Directions

1. Geographic Distribution Support: Use Conflict-free Replicated Data Types (CRDTs) to track events
2. Trigger Type Extension: Support additional trigger types such as XOR
3. Fault Tolerance Mechanisms: Introduce event time-to-live (TTL) mechanisms to handle expired events
4. Platform Integration: Deep integration with FaaS platform features such as load balancing

In-Depth Evaluation

Strengths

1. Accurate Problem Identification: Precisely identifies fundamental limitations of FaaS platforms in complex event processing
2. Reasonable Solution Design: MET engine architecture design considers scalability and practicality
3. Comprehensive Experiments: Thorough evaluation across multiple dimensions including latency, throughput, and concurrency
4. High Practical Value: Addresses real-world pain points with strong practical applicability
5. Excellent Performance: 62.5% latency reduction and 300,000+ requests/second processing capacity demonstrate solution effectiveness

Weaknesses

1. Geographic Distribution Limitations: Insufficient support for globally distributed application scenarios
2. Simple Fault Tolerance: Incomplete handling mechanisms for anomalies such as network partitions and node failures
3. Limited Trigger Rule Expressiveness: Current AND/OR combinations may not cover all complex business scenarios
4. Platform Integration: As an external component, may not fully leverage platform-internal optimizations

Impact

1. Academic Contribution: Provides new research directions and solutions for the FaaS field
2. Industrial Value: Can be directly applied to existing FaaS platforms to enhance complex event processing capabilities
3. Standardization Potential: May become the standard implementation approach for multi-event triggering in FaaS platforms
4. Reproducibility: Open-source prototype implementation provides good reproducibility

Applicable Scenarios

1. IoT Data Processing: IoT applications requiring aggregation of data from multiple sensors
2. Complex Event Processing: Scenarios such as financial transaction monitoring and network security detection requiring correlation analysis
3. Workflow Orchestration: Serverless workflows requiring completion of multiple prerequisite tasks
4. Batch Processing Optimization: Aggregating multiple small events for batch processing to improve efficiency

References

The paper cites 34 related references, primarily covering:

• FaaS platforms and triggering mechanism research
• Serverless workflow orchestration
• State management and complex event processing
• Performance evaluation and benchmarking

Key references include AWS Lambda architecture analysis, serverless computing surveys, and related workflow orchestration systems.

This paper proposes an innovative solution to an important limitation of FaaS platforms with strong theoretical and practical value. The MET engine design balances performance and scalability, with comprehensive experimental evaluation validating the solution's effectiveness. While there is room for improvement in geographic distribution and fault tolerance, overall this is a high-quality research work.