Multi-Event Triggers for Serverless Computing

TL;DR

The paper tackles the limitation of current FaaS platforms that trigger functions on single events by introducing multi-event triggers and the MET engine, enabling fan-in and join-style invocation conditions. It defines a formal rule system with AND/OR compositions and builds a prototype MET engine consisting of dispatchers and invokers that process events and trigger functions without embedding complex logic in the functions themselves. The evaluation shows substantial latency improvements (about 62.5% median reduction) and high throughput (exceeding 300k rps in a four-node setup), demonstrating that MET can scale to large FaaS platforms while preserving serverless benefits. This approach reduces unnecessary invocations and related costs, improves responsiveness for complex event processing, and lays groundwork for future geo-distributed deployments and richer trigger rule types.

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 platform assume that each function invocation corresponds to a single event. However, from an application perspective, it is desirable to invoke functions in response to a collection of events of different types or only with every n\textsuperscript{th} event. To implement this today, a function would need additional state management, e.g., in a database, and custom logic to determine whether its trigger condition is fulfilled and the actual application code should run. In such an implementation, most function invocations would be rendered essentially useless, leading to unnecessarily high resource usage, latency, and cost for applications. In this paper, we introduce multi-event triggers, through which complex conditions for function invocations can be specified. Specifically, we introduce abstractions for invoking functions based on a set of $n$ events and joins of multiple events of different types. This enables application developers to define intricate conditions for function invocations, workflow steps, and complex event processing. Our evaluation with a proof-of-concept prototype shows that this reduces event--invocation latency by 62.5\% in an incident detection use-case and that our system can handle more than 300,000 requests per second on limited hardware, which is sufficient load for implementation in large FaaS platforms.

Figures (6)

• Figure 1: An overview of the MET engine's architecture. Different client devices produce events and send them to the MET engine. A load balancer distributes events between dispatchers, which process the events by forwarding them to the invokers that handle triggers using that event type. Each invoker handles a set of triggers, stores them, checks whether the trigger condition is fulfilled, and triggers the functions accordingly.
• Figure 2: Cumulative distribution of latency values from the creation time of the last event that should trigger a function and the time at which the function logic actually starts. By using the MET engine over handling event logic within the function and coordinating database access across function instances, event–invocation latency is reduced by 62.5% in the median.
• Figure 3: Baseline implementation for handling MET without the SUT. The load generator calls the function detectIncident for each event. The function handles the event logic in addition to the use case and uses a database for keeping state across executions.
• Figure 4: Experiment setup for measuring event–invocation latency with the SUT. The load generator sends requests to the MET engine's load balancer, which distributed events across three dispatchers. As we only use a single MET for the function, there is only one invoker. This invoker collects events until the trigger rule is fulfilled, after which the function detectIncident is called.
• Figure 5: Throughput for different amounts of virtual users for a single-node and four-node cluster configuration. The single node reaches its maximum at 131,012.7 requests per second with 4,096 virtual users. With four nodes, maximum throughput increases to 313,154.81 requests per second.