AtomicFaaS: Offloading Side-Effect Compensation to the Serverless Platform

AtomicFaaS: Offloading Side-Effect Compensation to the Serverless Platform Jonas Heisterberg

Sebastian Koch

Technische Universität Berlin Berlin, Germany jh@3s.tu-berlin.de

Technische Universität Berlin Berlin, Germany sk@3s.tu-berlin.de

arXiv:2611.06601v1 [cs.DC] 4 Nov 2026

Trever Schirmer

David Bermbach

Technische Universität Berlin Berlin, Germany ts@3s.tu-berlin.de

Abstract Function-as-a-Service (FaaS) simplifies distributed application development by offloading operational concerns to the platform, but developers remain responsible for recovering from failures. Retries require idempotent functions, which means that developers have to write complex, error-prone code that undoes or skips the already completed operations of a failed function. To address this, we propose AtomicFaaS, a platform extension that provides semantic atomicity for the external side effects of a function invocation, whether the function fails or its instance crashes, without developer-written compensation code. AtomicFaaS intercepts outbound calls and records their effects in a faulttolerant log, from which the platform compensates leaked effects outside the failed instance. Compared with a manually implemented saga, AtomicFaaS eliminates compensation code and leaves no compensatable effects after any tested failure, while adding ∼1 ms per intercepted call. Under load, it lowers the sustainable throughput of CPU-bound functions, while its latency overhead becomes negligible once calls to external services dominate the invocation time.

CCS Concepts • Computer systems organization → Cloud computing.

Technische Universität Berlin Berlin, Germany db@3s.tu-berlin.de stateful operations [12]. A function may perform several operations with side effects before it fails, so developers must either undo already performed operations or roll forward through them when the function is retried. While the rollback itself runs within the function instance and cannot protect against failures of that instance, rolling forward requires additional persistence and coordination outside the function for every operation [19, 33]. Either way, developers have to reason about failure scenarios and write error-prone code that distracts from the business logic, which contradicts the simplicity that FaaS promises. Following the idea that the system rather than the application should run compensations [7, 15], we introduce AtomicFaaS, which brings it to serverless platforms. Under AtomicFaaS, an invocation either commits all of its external side effects, or the platform compensates those that were already applied, independent of the failure cause. To provide this guarantee, AtomicFaaS logs the outbound calls of a function and, if the invocation fails, issues compensating calls from outside the failed instance, using a catalog of inverses maintained by the platform or the service providers. Once every effect of an invocation has been compensated, it can be retried without producing duplicate effects, and developers write only the simple forward path of their functions. In this paper, we make the following contributions: • We propose compensating the external effects of failed functions as a platform responsibility and present the design of AtomicFaaS (§3). • We implement an open-source prototype on Knative that requires no changes to Knative or to the function code (§4). • Our evaluation shows that AtomicFaaS renders compensation code unnecessary, leaves no compensatable effects behind after any tested failure, and adds ∼1 ms per intercepted call (§4).

Keywords serverless, FaaS, compensation, semantic atomicity, failure handling

1

Introduction

Function-as-a-Service (FaaS) aims to simplify distributed application development by letting developers focus on business logic rather than operational concerns. The platform handles infrastructure provisioning, resource management, scaling, and fault tolerance [20]. Developers write applications as small, often stateless functions that the platform invokes in response to events [17, 31]. Failure handling, however, has only partly moved to the platform. It may re-execute a failed invocation, which is safe only for idempotent functions that developers must implement [18], and hence the consequences of a failed execution remain the developer’s responsibility. Ensuring idempotency can be challenging [11, 32], especially as functions often rely on external services to perform

This work is licensed under a Creative Commons Attribution 4.0 International License.

2

Background & Related Work

FaaS abstracts operational tasks away from developers, who write business logic as functions while the platform manages the infrastructure [20]. Functions are short-lived, stateless, and eventdriven [17, 31], and the platform treats each invocation as a black box. This lets it multiplex many functions onto shared resources and scale them independently on demand. For state and stateful operations, functions rely on external services such as databases, managed services, or third-party APIs [12]. Responsibilities for

Jonas Heisterberg, Sebastian Koch, Trever Schirmer, and David Bermbach

failure handling are split between the platform and the developers. For synchronous invocations, every failure, even one caused by the platform, is returned to the client, which has to handle it, most commonly with a retry. For asynchronous invocations, the platform automates this retry. Developers, on the other hand, are required to write idempotent functions, as functions can fail at any point in their execution and be retried [18], a requirement that is challenging to meet [11, 32].

Function instance Function call (external service)

2.2

Reliability in FaaS

Several research systems aim for exactly-once guarantees for serverless functions in the presence of failures [19, 23, 27, 33]. They retry a failed function under at-least-once semantics and skip its already completed operations, which gives each operation at-most-once semantics. While these approaches aim for transactional guarantees on FaaS functions, they do not extend beyond databases, and developers still have to write compensations for any external effects. Beldi, for instance, is a library that wraps a function’s database calls and logs every read, write and invocation, so a retried function skips the operations already done and always rolls forward to completion [33]. It also supports transactions with aborts through shadow tables, but an abort is initiated by the developer and covers only the storage the framework manages. Apiary instead compiles

External service compensate

append Effect log

Atomicity for External Effects

A central concern in distributed systems is that a sequence of operations on different services can fail partway through, leaving partial effects at those services. Database systems solved this problem decades ago, guaranteeing that a transaction either completes or leaves no lasting change [16]. An aborted transaction is undone by restoring the original value of every item it modified, which is possible because the database owns all the data a transaction touches. In a distributed system, neither the platform nor the application owns the state of external services, so an abort cannot simply restore it [24]. The alternative is compensation, an operation that semantically undoes the effect of a committed operation [22]. Sagas build on this idea, a long-running transaction is split into sequential sub-transactions, each paired with a compensating transaction, and when one fails the system runs the compensations of all committed steps in reverse order [14]. FaaS workflow engines adopt the same idea, the developer pairs each workflow step with a compensating step and the engine executes them in reverse when a step fails [3, 10]. Runtimes for agentic workflows follow, with the compensation for tool calls either provided by a developer [26] or generated by a model [9]. Compensation can roll back effects on external services, but it weakens atomicity in three ways. First, effects remain visible to other services until the compensation executes [14]. Second, some effects are irreversible, such as a sent e-mail, which cannot be compensated [24]. Third, a compensation restores only a semantically equivalent state, not the original one, and its correctness is not guaranteed [22]. Compensation therefore provides semantic atomicity [13], not the physical atomicity of a database transaction. We use the term in this sense throughout the paper: an invocation either commits all of its effects, or every compensatable effect it leaked is semantically undone by the platform.

call

Interceptor

watch

2.1

intended call

notify

Crash detector

read logs Catalog

Reverter

Figure 1: In AtomicFaaS, an interceptor logs every outbound call to external services before forwarding it, and a reverter compensates failed invocations according to a shared catalog of inverses.

functions into stored procedures, so that execution is co-located with the data and inherits the DBMS’s ACID guarantees [23]. Calls to external services cannot be covered by the database, so Apiary requires them to be idempotent and re-executes them on a retry. Zhuang et al. [34] come closest to our goal, their workflow engine rolls back the external outputs of a failed execution before it replays the workflow, but the developer writes the rollback function for every such output. Durable execution engines [8], which commercial platforms have integrated [2, 25], offer the same roll-forward approach as a platform service. The orchestrator stores the result of each step defined by the developer and, when the function invocation is retried, returns the stored result instead of executing the step again. Within a step, partial effects remain possible, and the developer has to keep every step idempotent. None of these systems removes the burden from the developer, who still writes the failure handling, whether as idempotent steps or as compensations. To the best of our knowledge, no existing platform takes the entire responsibility for undoing the external effects of a failed function.

3

Design

We propose AtomicFaaS, a system that brings semantic atomicity for external effects to FaaS platforms. An invocation either commits all of its effects or the platform compensates the effects that leaked, even if the function crashes partway through its execution. The approach requires a platform that can intercept the outbound calls of a function, tell from each response whether the call succeeded, and observe the lifecycle of its function instances. The unit of this guarantee is the invocation and its side effects, AtomicFaaS neither makes a single outbound call atomic nor re-executes the function. AtomicFaaS consists of three core parts that communicate through a shared, low-latency, fault-tolerant effect log, as shown in Figure 1. The interceptor lives alongside the user code inside the instance and intercepts every outbound call the function instance makes. Before it forwards a call, it appends a record of the call to the effect log, which lives outside the instance so that it survives an instance crash. If the function succeeds, the interceptor discards the corresponding entries from the effect log.

AtomicFaaS: Offloading Side-Effect Compensation to the Serverless Platform

An invocation aborts on one of two paths. On the first, the function returns an error, because an outbound call failed in a way it could not handle or because its own logic rejects the request, and the interceptor marks the invocation as aborted. On the second, the instance itself crashes, and the crash detector notices the failure from outside the sandbox. Either way, the reverter is notified, reads the effect log of the aborted invocation, and compensates the recorded calls in reverse order using a catalog of rules.

3.1

Effect Log and Catalog

The interceptor acts as a proxy, appending a record of a call to the effect log before it forwards the call and completing the record with the status and body of the response when it arrives. Both halves are kept, since the reverter may need values from the response, such as the identifier of a reservation, to construct the neutralizing call. Because the record precedes the call, a crash leaves the reverter either no record, and then no effect happened, or a record of an effect that may have happened, but never an effect without a record. The catalog holds rules that recognize a call by its method and path and, if the effect can be undone, describe the call that undoes it, with values taken from the recorded request and response. The catalog exists once per platform and is shared across all tenants. We envision the platform owning this catalog, maintaining the rules for its own services, deriving them from API specifications for external ones, and letting third parties contribute rules for their services. Not every action that leads to a side effect can be compensated, so the catalog also assigns each action one of three classes: Invertible actions have a documented neutralizing operation, such as a payment cancellation or a refund. Actions with two-phase semantics, such as inventory holds, fall into the same class, their inverse is the release. The interceptor forwards these calls to the target services, and on abort the reverter executes the neutralizing call. Deferrable actions have an irreversible effect that the function does not need to compute its result, such as sending a confirmation e-mail. The interceptor does not forward them and immediately returns a placeholder response to the function, which continues its execution but must not depend on the reply. It forwards them to the target services after the function has returned successfully, a rule adapted from Gray [16]. All remaining actions are uncompensatable. The interceptor also stores them in the effect log before forwarding them. Such an action lies outside the guarantee. On abort, it is reported for manual resolution or handled by an error handling component, which would also be required if the function did not run on AtomicFaaS.

3.2

Commit, Abort, and Compensation

When the function returns, its response passes through the interceptor, which first flushes the deferred actions in the order they were recorded. It only marks the invocation as committed and answers the invoker once all of them have succeeded. Hence, a successful response to the caller means that all side effects have occurred, including irreversible ones. Like any other call, a deferred call can fail, in which case it is retried with an exponential backoff. If the call ultimately fails, the invocation aborts and any deferred action already delivered is treated as an uncompensatable one.

Whether an invocation commits is decided by the function’s response, the flush of its deferred actions, and the survival of its instance. Beyond a failed flush, the interceptor marks an invocation as aborted if the function returns an error, which also lets a developer abort deliberately without writing any compensation code. Developers can still decide to handle certain failures in their business logic, so a failed call alone does not abort the invocation. A crash of the instance, however, takes the interceptor with it, so the platform has to notice it from the outside, which is the job of the crash detector. Either way, the reverter is notified and processes the recorded actions of an aborted invocation in reverse order. For each record it looks up the action in the catalog to determine its class and, for an invertible action, instantiates the template of the neutralizing call with values from the recorded request and response and issues it to the service. Deferred actions that were never forwarded are discarded, uncompensatable actions are reported for manual resolution, and any neutralizing call that still fails after retries is likewise reported.

4

Evaluation

We first show that AtomicFaaS reverts effects correctly and then quantify what atomicity costs in latency and throughput. Prototype. We implement AtomicFaaS as a proof-of-concept prototype in Go that extends Knative [21] for HTTP-triggered functions written in JavaScript whose effects stem from outbound HTTP calls. To leave existing functions unaltered, a shim modifies the Fetch API so that every outbound call is routed through an interceptor running as a proxy next to the function in the same pod. The interceptor records each call in the effect log, a Redis [28] store in the same cluster, and then forwards it to the target service. In production, this store would be replicated for fault tolerance, whereas our prototype runs a single instance. The crash detector and the reverter also run in the same cluster. As Knative provides no hook to detect a function failure, the crash detector watches the Kubernetes API for terminated pods and marks the invocations that were running on them as aborted. The reverter polls the effect log for aborted invocations and issues the inverse of each recorded effect. We publish the prototype and all results as open source.1 Use Case. We adapt the SeBS-Flow trip-booking workload [29] and implement it as a single function, which calls a sequence of external APIs, as shown in Figure 2. We refer to the original workload as the base flow and derive an extended flow by adding two effects, a payment, which has to be refunded, and a confirmation e-mail, which is irreversible but deferrable. Both flows exist in two versions. The forward-only version issues the calls and nothing else, which is the code a developer would ship on our platform. The manual saga carries the compensation inside the function, which is what a developer currently has to write for the same outcome. On a failure, the saga compensates every completed call in reverse order.

4.1

Developer Effort and Correctness

First we measure the developer effort AtomicFaaS saves, counting the lines of code of both versions with scc [6]. As shown in Figure 3, the saga grows the base flow from 43 to 74 lines and the extended 1 https://github.com/persists/atomicfaas

Jonas Heisterberg, Sebastian Koch, Trever Schirmer, and David Bermbach

Reserve hotel

Reserve car

Reserve flight

Charge payment

Send e-mail

Create trip record

base workload

added in extended workload

Figure 2: The trip-booking workload [29] runs in one function, where each step is one outbound call to an external API.

100

74 43

Manual saga 93

Extended flow

Figure 3: Lines of code of the forward-only function on AtomicFaaS and the manual saga with its compensation code.

flow from 56 to 93, an increase of 72 % and 66 %, respectively. Everything the saga adds is compensation, a list of the steps completed so far and a reverse call for each of them, while functions on AtomicFaaS are plain without any failure handling. Compensation code is not difficult to write, but it has to be kept in step with the forward path and tested for every point at which the flow can fail. Second we show that the compensation works in every tested failure case. We deploy three versions of the extended flow: the forward-only function on plain Knative, the same function on AtomicFaaS, and the manual saga on plain Knative. We mock the APIs of the external services. We fail one API at a time along the flow, either by having the mocked API refuse the call or by terminating the instance while a call is in progress. As expected, the forward-only function on plain Knative leaks every effect completed before the failure. The manual saga compensates after a refusal but leaks the e-mail once it is sent, as the saga cannot defer it and has no inverse for it. If the instance is terminated, the saga cannot compensate anything, as its compensation code is gone with the function. With AtomicFaaS, no effect survives the failure in any run, since the e-mail is deferred until the invocation commits and the effects are compensated from outside the function’s pod.

Cost of Atomicity

Every request to an external service passes through the interceptor and is recorded before it is forwarded. To quantify what this costs, we measure the end-to-end latency of a single invocation as well as the latency and throughput under load. Experimental setup. The performance experiments run on Google Cloud in zone europe-west1. Every cluster is a single Kubernetes node running Knative, an e2-standard-8 instance with 8 vCPU and 32 GB of memory. Every function instance requests 0.15 vCPU and 160 MiB of memory and serves one request at a time. On the AtomicFaaS cluster, the Redis store, the crash detector and the reverter run on the same node and draw from the same resource budget, so the cost of AtomicFaaS includes its own infrastructure. The load generator and the mocked services run on a separate

Manual saga

AtomicFaaS

Last API down

Cost of rollback

40 80 Latency (ms)

0

1.0

56

0 Base flow

4.2

Plain Knative No failures ECDF

Lines of code

Forward-only

0.5 0.0 0

40

80

0

40

80

Figure 4: End-to-end latency of one invocation without failures and with the last call failing, and rollback duration from the first to the last inverse call at the providers.

machine to isolate the load from the system under test [5]. Every mocked service answers a call after 5 ms, including the inverse calls. Latency of a single invocation. The first experiment measures the overhead of AtomicFaaS when nothing else competes for the node. We compare the same three versions of the extended flow as before, each deployed on the same machine. The load generator issues 1000 sequential invocations to each version and records the end-toend latency. We follow the randomized multiple interleaved trials method, RMIT [1], where a trial is one invocation on one version and each round runs one trial of every version in a fresh random order, to account for autocorrelation between invocations. Figure 4 shows the distributions. Without failures, the median invocation takes 51 ms on plain Knative and with the manual saga, and 57 ms on AtomicFaaS. AtomicFaaS therefore adds 6 ms to the six calls of the flow, ∼1 ms per intercepted call for the write-ahead record and the proxy hop. When the last call fails, plain Knative and AtomicFaaS answer in 43 ms, since both return as soon as the refusal arrives. The manual saga answers in 75 ms because it compensates before it replies, while AtomicFaaS compensates in the background. The right panel shows the compensation itself, measured at the mocked services from the first inverse call to the last. Beyond the 20 ms that both spend waiting on the four inverse calls at the mock, the reverter needs 4 ms for the compensation and the saga 9 ms, so undoing from the platform is not slower than the handwritten code. Both undo the effects in reverse order one call at a time. We attribute the difference to the reverter being a compiled service, whereas the saga issues its inverse calls from the interpreted JavaScript runtime of the function. Overall, AtomicFaaS adds ∼1 ms per intercepted call during normal operation and in contrast to the manual saga, it does not delay the function’s response when a failure occurs. Latency and throughput under load. The second experiment measures the overhead of AtomicFaaS under load, where concurrent

AtomicFaaS: Offloading Side-Effect Compensation to the Serverless Platform

Latency (ms)

Plain Knative

sustains 150 req/s and AtomicFaaS 125 req/s, which we identify as being limited by the number of instances the node admits. AtomicFaaS admits fewer instances because the store, the detector and the reverter draw from the same CPU budget. None of the components is a scaling bottleneck by design, the interceptor runs in every instance, and the effect log, the detector and the reverter can be partitioned by invocation, but our prototype runs one store and one reverter per cluster, which we did not scale out in this evaluation.

AtomicFaaS

70

200

50 100 0 50

100 150 200 250 300 350 400 450 500 Throughput (req/s)

Latency (ms)

Figure 5: Both variants receive increasing request rates while mocked external services answer after 5 ms.

Plain Knative

1000

0 75

Discussion

AtomicFaaS

500

50

5

We have shown that AtomicFaaS reduces developer effort, leaves no compensatable effect behind after any tested failure, where a manual saga still does, and costs ∼1 ms per intercepted call and a share of the node’s resources for its components.

100 125 Throughput (req/s)

150

Figure 6: Both variants receive increasing request rates while mocked external services answer after 50 ms. invocations share the node. To this end, we compare the forwardonly function on plain Knative and on AtomicFaaS, each deployed on a separate e2-standard-8 instance. The load generator drives both deployments in parallel, with one set of mocked API endpoints for each. Requests are issued in an open loop at a fixed rate, so arrivals do not wait for earlier invocations to finish [30]. Every rate runs for 10 min of measurement after 3 min of warm-up. We raise the rate in steps and count a rate as sustained if at least 95 % of the offered invocations complete successfully. Figure 5 shows the result with the 5 ms response delay. Plain Knative sustains 500 req/s and AtomicFaaS 300 req/s. Up to 200 req/s the median on AtomicFaaS stays between 57 and 61 ms against 51 ms on plain Knative, a similar offset as for a single invocation. At 250 req/s and 300 req/s the median rises to 69 ms and 106 ms, and at 350 req/s fewer than 95 % of the invocations complete, as the node is saturated. Plain Knative reaches the same point at 500 req/s with a median of 79 ms. The overhead per intercepted call therefore stays roughly constant at moderate load, and saturation arrives earlier for AtomicFaaS, which we attribute to the CPU that the interceptors and components consume. We repeat the experiment with the mocked API endpoints answering after 50 ms, so that an instance spends most of its time waiting for a response. We also reduce the CPU request of each function instance to 0.075 vCPU, so the node admits more instances and therefore more concurrent waiting invocations, which further increases the load on AtomicFaaS. Figure 6 shows that the difference between the two deployments largely disappears, as the interceptor’s work per call becomes a small share of the flow. Plain Knative

Failure handling as a platform responsibility. Moving failure handling out of the function establishes an additional responsibility for the platform. The platform takes over a class of failure handling that developers currently write, test and maintain by hand, the same trade the FaaS model already makes for scaling and resource management [20]. What it costs the developer is a small overhead per intercepted call, which is minor next to the time a call to an external service takes [4]. The platform’s cost is a share of its resources for the additional components, which it can bill like any other managed service. Where the failure handling runs matters beyond cost, and it is why AtomicFaaS is not a library inside the function, as opposed to other approaches [19, 27, 33]. Failure handling inside a function is untrusted tenant code, it runs in the sandbox of one instance, dies with that instance, and knows only what that instance has seen. Running the effect log and compensation outside this sandbox lets AtomicFaaS survive instance crashes. Compensation inside a function also delays the caller and keeps a fixed-size instance idle on synchronous calls, which the user pays for. Using AtomicFaaS, the platform compensates in the background and answers the caller as soon as the function fails. AtomicFaaS also opens new avenues for future work, as the platform can share aggregate knowledge, such as the failure rates of external services, across functions and tenants to coordinate efficient scheduling and failure handling. For instance, the platform could postpone invocations that call a failing service or open a circuit breaker for them until the service recovers. Boundaries of AtomicFaaS. The reverter can only undo what the catalog describes, but the same rollback knowledge is needed today by every developer for every function, whereas AtomicFaaS lets the platform acquire it once per service and apply it for all of its clients. Our prototype intercepts HTTP calls through the patched Fetch API, so effects through other transports escape the interceptor, but the same design extends to other transports the platform can wrap, such as database drivers, queue or gRPC clients. Lastly, in our prototype, if the instance dies while a call is in flight, the reverter does not know whether the effect exists, and if the inverse needs the provider’s response, it cannot issue it and reports the record, which a probe of the service or idempotent operations could address.

Jonas Heisterberg, Sebastian Koch, Trever Schirmer, and David Bermbach

6

Conclusion

We proposed AtomicFaaS, a system that undoes the compensatable external effects of failed function invocations without any developer-written compensation code, which brings FaaS closer to its promise that developers write only their business logic. It logs every outbound call and compensates leaked effects from outside the failed instance. Our prototype on Knative spares the 66 % of additional code that a manual saga adds to an extended trip-booking function and leaves no compensatable effect behind after any tested failure, including instance crashes that a manual saga cannot recover from. Atomicity costs ∼1 ms per intercepted call and reduces the sustainable throughput on a CPU-bound workload, while its latency overhead becomes negligible once calls to external services dominate the invocation time.

Acknowledgments Funded by Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) – 495343202.

References [1] Ali Abedi and Tim Brecht. 2017. Conducting Repeatable Experiments in Highly Variable Cloud Computing Environments. In Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering (ICPE ’17). ACM, New York, NY, USA, 287–292. doi:10.1145/3030207.3030229 [2] Amazon Web Services. 2026. AWS Lambda Durable Functions. https://aws. amazon.com/lambda/lambda-durable-functions/ Accessed: October 28, 2026. [3] Amazon Web Services. 2026. Saga Orchestration Pattern. https: //docs.aws.amazon.com/prescriptive-guidance/latest/cloud-designpatterns/saga-orchestration.html. Accessed: October 28, 2026. [4] David Bermbach and Erik Wittern. 2020. Benchmarking Web API Quality – Revisited. Journal of Web Engineering 19, 5–6 (Oct. 2020), 603–646. doi:10.13052/ jwe1540-9589.19563 [5] David Bermbach, Erik Wittern, and Stefan Tai. 2017. Cloud Service Benchmarking: Measuring Quality of Cloud Services From a Client Perspective. Springer, Cham, Switzerland. [6] Ben Boyter. 2026. scc: Sloc, Cloc and Code. https://github.com/boyter/scc Accessed: October 28, 2026. [7] Y. Breitbart, A. Deacon, H.-J. Schek, A. Sheth, and G. Weikum. 1993. Merging Application-Centric and Data-Centric Approaches to Support TransactionOriented Multi-System Workflows. SIGMOD Rec. 22, 3 (Sept. 1993), 23–30. doi:10.1145/163090.163095 [8] Sebastian Burckhardt, Chris Gillum, David Justo, Konstantinos Kallas, Connor McMahon, and Christopher S. Meiklejohn. 2021. Durable Functions: Semantics for Stateful Serverless. Proc. ACM Program. Lang. 5, OOPSLA, Article 133 (Oct. 2021), 27 pages. doi:10.1145/3485510 [9] Edward Y. Chang and Longling Geng. 2025. SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning. Proc. VLDB Endow. 18, 12 (Aug. 2025), 4874–4886. doi:10.14778/3750601.3750611 [10] Cloudflare. 2026. How We Built Saga Rollbacks for Cloudflare Workflows. https: //blog.cloudflare.com/rollbacks-for-workflows/. Accessed: October 28, 2026. [11] Haoran Ding, Zhaoguo Wang, Zhuohao Shen, Rong Chen, and Haibo Chen. 2023. Automated Verification of Idempotence for Stateful Serverless Applications. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’23). USENIX Association, Berkeley, CA, USA, 887–910. https://www.usenix. org/conference/osdi23/presentation/ding [12] Simon Eismann, Joel Scheuner, Erwin van Eyk, Maximilian Schwinger, Johannes Grohmann, Nikolas Herbst, Cristina L. Abad, and Alexandru Iosup. 2021. A Review of Serverless Use Cases and their Characteristics. arXiv:2008.11110 [cs.SE] https://arxiv.org/abs/2008.11110 [13] Hector Garcia-Molina. 1983. Using Semantic Knowledge for Transaction Processing in a Distributed Database. ACM Trans. Database Syst. 8, 2 (June 1983), 186–213. doi:10.1145/319983.319985 [14] Hector Garcia-Molina and Kenneth Salem. 1987. Sagas. SIGMOD Rec. 16, 3 (Dec. 1987), 249–259. doi:10.1145/38714.38742 [15] Dimitrios Georgakopoulos, Mark Hornick, and Amit Sheth. 1995. An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases 3, 2 (April 1995), 119–153. doi:10.1007/BF01277643

[16] Jim Gray. 1988. The Transaction Concept: Virtues and Limitations. In Readings in Database Systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 140–150. [17] Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, and Chenggang Wu. 2018. Serverless Computing: One Step Forward, Two Steps Back. arXiv:1812.03651 [cs.DC] https://arxiv.org/abs/1812.03651 [18] Abhinav Jangda, Donald Pinckney, Yuriy Brun, and Arjun Guha. 2019. Formal foundations of serverless computing. Proc. ACM Program. Lang. 3, OOPSLA, Article 149 (Oct. 2019), 26 pages. doi:10.1145/3360575 [19] Zhipeng Jia and Emmett Witchel. 2021. Boki: Stateful Serverless Computing with Shared Logs. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (SOSP ’21). ACM, New York, NY, USA, 691–707. doi:10.1145/ 3477132.3483541 [20] Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, and David A. Patterson. 2019. Cloud Programming Simplified: A Berkeley View on Serverless Computing. arXiv:1902.03383 [cs.OS] https://arxiv.org/abs/1902.03383 [21] Knative Authors. 2026. Knative. https://knative.dev Accessed: October 28, 2026. [22] Henry F. Korth, Eliezer Levy, and Abraham Silberschatz. 1990. A Formal Approach to Recovery by Compensating Transactions. In Proceedings of the 16th International Conference on Very Large Data Bases (VLDB ’90). Morgan Kaufmann, 95–106. [23] Peter Kraft, Qian Li, Kostis Kaffes, Athinagoras Skiadopoulos, Deeptaanshu Kumar, Danny Cho, Jason Li, Robert Redmond, Nathan Weckwerth, Brian Xia, Peter Bailis, Michael Cafarella, Goetz Graefe, Jeremy Kepner, Christos Kozyrakis, Michael Stonebraker, Lalith Suresh, Xiangyao Yu, and Matei Zaharia. 2023. Apiary: A DBMS-Integrated Transactional Function-as-a-Service Framework. arXiv:2208.13068 [cs.DB] https://arxiv.org/abs/2208.13068 [24] Barbara Liskov and Robert Scheifler. 1983. Guardians and Actions: Linguistic Support for Robust, Distributed Programs. ACM Trans. Program. Lang. Syst. 5, 3 (July 1983), 381–404. doi:10.1145/2166.357215 [25] Microsoft. 2026. Durable Functions Overview. https://learn.microsoft.com/enus/azure/durable-task/durable-functions/durable-functions-overview Accessed: October 28, 2026. [26] Bardia Mohammadi, Nearchos Potamitis, Lars Klein, Akhil Arora, and Laurent Bindschaedler. 2026. Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows. arXiv:2602.14849 [cs.LG] https://arxiv.org/abs/2602.14849 [27] Sheng Qi, Xuanzhe Liu, and Xin Jin. 2023. Halfmoon: Log-Optimal Fault-Tolerant Stateful Serverless Computing. In Proceedings of the 29th Symposium on Operating Systems Principles (SOSP ’23). ACM, New York, NY, USA, 314–330. doi:10.1145/ 3600006.3613154 [28] Redis Ltd. 2026. Redis. https://redis.io Accessed: October 28, 2026. [29] Larissa Schmid, Marcin Copik, Alexandru Calotoiu, Laurin Brandner, Anne Koziolek, and Torsten Hoefler. 2025. SeBS-Flow: Benchmarking Serverless Cloud Function Workflows. In Proceedings of the Twentieth European Conference on Computer Systems (EuroSys ’25). ACM, New York, NY, USA, 902–920. doi:10. 1145/3689031.3717465 [30] Bianca Schroeder, Adam Wierman, and Mor Harchol-Balter. 2006. Open Versus Closed: A Cautionary Tale. In 3rd Symposium on Networked Systems Design & Implementation (NSDI’06). USENIX Association, Berkeley, CA, USA, 239–252. https: //www.usenix.org/conference/nsdi-06/open-versus-closed-cautionary-tale [31] Mohammad Shahrad, Rodrigo Fonseca, Inigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, and Ricardo Bianchini. 2020. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. In 2020 USENIX Annual Technical Conference (ATC ’20). USENIX Association, Berkeley, CA, USA, 205–218. https: //www.usenix.org/conference/atc20/presentation/shahrad [32] Vikram Sreekanti, Chenggang Wu, Saurav Chhatrapati, Joseph E. Gonzalez, Joseph M. Hellerstein, and Jose M. Faleiro. 2020. A fault-tolerance shim for serverless computing. In Proceedings of the Fifteenth European Conference on Computer Systems (EuroSys ’20). ACM, New York, NY, USA, Article 15, 15 pages. doi:10.1145/3342195.3387535 [33] Haoran Zhang, Adney Cardoza, Peter Baile Chen, Sebastian Angel, and Vincent Liu. 2020. Fault-Tolerant and Transactional Stateful Serverless Workflows. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’20). USENIX Association, Berkeley, CA, USA, 1187–1204. https://www.usenix. org/conference/osdi20/presentation/zhang-haoran [34] Siyuan Zhuang, Stephanie Wang, Eric Liang, Yi Cheng, and Ion Stoica. 2023. ExoFlow: A Universal Workflow System for Exactly-Once DAGs. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’23). USENIX Association, Berkeley, CA, USA, 269–286. https://www.usenix.org/conference/ osdi23/presentation/zhuang

Related documents

• The Atom Publishing Protocol#500965
• Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD#1527863
• Safety Analysis of CPSs Over-the-air Updates: Test Case Prioritization and Selection#1389421
• Safety Analysis of CPSs Over-the-air Updates: Test Case Prioritization and Selection#1381331
• Audit-First Rollback Semantics for Safety-Critical Deployment Pipelines#819854