Pith. sign in

REVIEW 4 major objections 7 minor 1 cited by

Distributed Speculative Execution for Resilient Cloud Applications

T0 review · 4 major / 7 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that the durable execution abstraction can be provided without synchronous persistence on the common path, by speculatively running ahead of persistence and rolling back state after failures.

desk verdict A solid systems paper whose correctness rests on an unproven equivalence to DPR; worth refereeing, with the proof sketch and the self-simulated baseline as the main open questions. read the letter →

arxiv 2412.13314 v1 pith:X55V5KK4 submitted 2024-12-17 cs.DC

Tianyu Li , Badrish Chandramouli , Philip A. Bernstein , Samuel Madden This is my paper · ORCID
classification cs.DC
keywords distributedspeculativeexecutiondurablerollbackrecoveryfaulttolerancedependencygraphmessage-passingstateobjectscloudapplicationslatencyoptimization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Durable execution systems today make each step of a distributed workflow wait for its state to hit durable storage, so latency grows with workflow depth. This paper proposes distributed speculative execution (DSE): let code run as if persistence were synchronous, but persist asynchronously and repair inconsistencies by rollback only if a failure actually occurs. The paper presents libDSE, a framework that realizes this with message-passing StateObjects, atomic actions, and lightweight sthreads with barriers, and builds four speculative services from it: a write-ahead log, a key-value store, an event broker, and a workflow engine. In measurements on three assembled applications, DSE cuts end-to-end latency by 20% to up to an order of magnitude compared with non-speculative durable execution, with the explicit trade-off that failure recovery becomes slower and rolls back more work.

What carries the argument

The load-bearing object is the recovery dependency graph over recoverable points, where a recoverable point of a StateObject is a persisted version indexed by a global failure counter and a local persistence counter. Each message carries its originating vertex, and receiving a message adds an edge from the receiver's current vertex to the sender's vertex. The coordinator periodically finds a recoverable boundary as a closure of the graph—vertices that are all persisted and have no edges to non-persisted vertices—and only messages originating behind such a boundary are treated as safe to expose. Two invariants carry the correctness argument: the commit ordering rule, which lets vertex $A^y_x$ receive a message from $B^n_m$ only if $y \ge n$ and thereby prevents unbounded rollback cascades, and the recovery sequencing and partition rules, which order rollbacks by failure sequence number and forbid communication across incarnations. Actions and sthreads are the programmer-facing mechanism that keeps persistence and rollback from interleaving with application code.

What would settle it

A decisive test would be fault injection on a small libDSE cluster: have one StateObject send a message and then be killed before its Persist completes, and check whether any surviving object ever exposes a result derived from that lost message to an external client; a second decisive test is to enumerate reachable executions of a small libDSE program and the corresponding DPR cache-store program and compare their recoverable boundaries, since a mismatch would disprove the asserted protocol equivalence.

Watch

Extended reading notes

Core claim

The paper's central claim is that the durable execution abstraction can be decoupled from physical synchronous persistence. In libDSE, a service's state lives in a StateObject, operations run as atomic actions, and long-running operations detach into sthreads that carry dependency metadata. Messages are tagged with their originating recoverable point, the runtime builds a recovery dependency graph, and a coordinator advances a recoverable boundary—a closure with no edges leaving it—so that only results behind the boundary are exposed to external clients. On failure, the coordinator assigns a global failure sequence number, rolls back affected participants to their latest recoverable points, and partitions the cluster so pre-recovery and post-recovery incarnations cannot communicate. The correctness argument is that this message-passing protocol is equivalent to the Distributed Prefix Recovery (DPR) cache-store protocol, with a new stateless coordinator that removes one coordinator persistence from the failure-free path, and that it applies to arbitrary fail-restart message-passing applications without determinism or user annotations.

Load-bearing premise

The paper's correctness claim rests on an asserted equivalence, given only as a sketch, between libDSE's message-passing state objects and the earlier Distributed Prefix Recovery cache-store protocol; if that equivalence fails, the rollback protocol may not preserve consistency after a crash.

Editorial extensions

If this is right

  • On the failure-free path, the persistence cost of a workflow DAG changes from the sum of per-step synchronous writes to roughly the maximum of their asynchronous writes, so latency no longer grows linearly with workflow depth.
  • Durable execution engines can support non-deterministic tasks without developer-supplied replay or rollback annotations, and speculative services can interoperate with ordinary non-speculative services through barriers.
  • Event-processing pipelines can save storage bandwidth in addition to latency, because intermediate results that are generated, consumed, and pruned during speculative execution never need to reach storage.
  • Standard distributed primitives such as two-phase commit can be optimized by bypassing synchronous logging without redesigning the protocol.
  • Recovery becomes rarer but more expensive and more aggressive, so DSE is a favorable trade only when failures are uncommon—the situation the authors argue is typical in the cloud.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The stateless, log-backed coordinator makes DSE a plausible fit for serverless or elastic settings where the coordinator can be rebuilt from a persistent log; the paper leaves implicit that boundary queries must pause until all participants reconnect after a coordinator restart.
  • The commit ordering rule's requirement that communicating services persist at similar rates points to a tunable family of protocols—relaxing $y \ge n$ to a bounded lag would trade controlled rollback-cascade risk for better behavior under skewed persistence rates, an extension the paper only gestures at.
  • Because libDSE rolls back more than strictly necessary on failure, a natural follow-up is a recovery-time voting protocol in which participants negotiate the minimal rollback boundary; the paper names this direction as future work rather than claiming it.
  • The framework excludes replicated and quorum-based services because they lack a clear restart semantic; if a restart-like abstraction could be defined for them, DSE's latency argument would extend to a broader class of cloud storage.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper proposes distributed speculative execution (DSE), a technique that decouples the durable execution abstraction from synchronous persistence by letting applications run ahead of persistence and repairing state through rollback after failures. The authors present libDSE, a C# framework built around StateObjects, atomic actions, and lightweight threads (sthreads), and adapt the Distributed Prefix Recovery (DPR) protocol to a message-passing peer model with a stateless coordinator. They implement four speculative services and evaluate three end-to-end applications, reporting up to an order-of-magnitude latency reduction over a non-speculative baseline, low instrumentation overhead, and quick recovery in two scenarios.

Significance. If the correctness argument can be made rigorous, DSE is a significant systems idea: it would remove synchronous persistence from the critical path of durable execution and shift the cost to rare rollback-based recovery, which is arguably the right trade-off for many cloud workloads. The paper's strengths are its clear problem formulation, the concrete API design, the measured microbenchmarks showing that the libDSE primitives sustain millions of operations per second, and the demonstration that heterogeneous services can be assembled on one runtime. The main advertised latency improvement, however, is currently supported only by a self-simulated baseline rather than by comparison with actual durable execution systems, and the correctness transfer from DPR to libDSE is asserted rather than proved. Both issues are load-bearing for the paper's central claims.

major comments (4)
  1. [§4.2 (Correctness Sketch)] The correctness of the whole system rests on the claim that libDSE's message-passing StateObject/action/sthread protocol is equivalent to DPR's cache-store/session model, but this is only asserted at a high level and no formal proof or model checking is provided. Three protocol elements have no explicit DPR counterpart: sthreads, which are outside the dependency graph yet can Send, Receive, and Merge into a parent that may have rolled back; concurrent actions within a StateObject; and the stateless coordinator. In particular, the Recovery Sequencing Rule and the Recovery Partition Rule (Definitions 4.2 and 4.3) are stated for graph vertices and do not specify the behavior of a surviving sthread across a recovery partition. Please supply a formal equivalence proof or a standalone correctness proof that covers these elements; without it, DPR's prefix-recoverability guarantee cannot be transferred to libDSE.
  2. [§4.3 (Coordinator Design, Finding Boundaries)] The claim that 'any recoverable boundaries the coordinator finds on its present view must also be recoverable on a later view' is asserted without proof. Because the coordinator's view can lag the true graph by missing in-flight vertices and edges, a closure in the coordinator's view need not be a closure in the actual graph unless one proves that no later-reported edge can leave the candidate boundary; the immutability of the persistent part of the graph does not by itself rule out, for example, an edge added to an already-persisted vertex by a message receipt before the next persist operation. A precise invariant about when edges can be added relative to persistence, and a proof that the boundary search is monotone, are needed.
  3. [§6.1 (TravelReservations)] The headline latency comparison is against a baseline constructed by disabling speculation in libDSE rather than against an actual durable execution system such as Temporal, Azure Durable Functions, Beldi, or Boki. The paper states that this normalizes other parts of the system, but that implicitly assumes the only relevant difference is the number of synchronous persistence operations. Real systems have different protocols, logging formats, and batching behaviors, so the reported 'up to an order of magnitude' improvement over 'current generations of durable execution systems' is not directly substantiated. Please benchmark against at least one real system, or carefully restrict the claim to the self-simulated baseline.
  4. [§5.3 and §6.2 (Recovery)] The recovery evaluation covers only a single Kubernetes kill with restart and a synthetic atomic rollback, and does not exercise overlapping failures, coordinator failure and recovery, or the more aggressive rollback behavior that Section 5.3 acknowledges. Since the paper explicitly trades failure-free latency for slower and more complex recovery, the absence of a stress test for the recovery path leaves the central trade-off only partially evaluated. Adding experiments with concurrent failures or coordinator restart would make the recovery claims more convincing.
minor comments (7)
  1. [§8] The word 'clodu' in 'clodu applications' is a typo and should be 'cloud'.
  2. [§6.1] The phrase 'the the search trend alert' contains a duplicated article and should be corrected.
  3. [§6.2] The word 'concucrrent' in 'concucrrent clients' is a typo and should be 'concurrent'.
  4. [§5.1] The sentence 'StateObjects first Connect to a the coordinator' contains an extra article 'a' and should be 'Connect to the coordinator'.
  5. [References] Reference [31], cited for the saga pattern, points to an Azure storage redundancy page; the citation target should be replaced with an appropriate saga reference.
  6. [§6.3] The text reports that the libDSE protocol itself causes 'less than 5% reduction in throughput' but does not state the exact measured numbers; including them would make the comparison easier to verify.
  7. [§4.2] The citation '[48]' for 'consistency' points to Lamport's time-clocks paper, which does not define consistency in the rollback-recovery sense used here; a more specific reference would help.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central latency claim is experimentally measured, and reliance on DPR is an independently published result; the Section 4.2 equivalence is an unproved derivation gap, not a circular step.

full rationale

I walked the paper's derivation chain. The central performance claim in the abstract, that libDSE "reduces end-to-end latency by up to an order of magnitude," is supported by direct measurements in Section 6 rather than by fitting or by assuming the claim. The baseline is obtained by "turning off speculation in our system; doing so will cause our system to perform the same number of synchronous persistence as Beldi/Boki would," which is a controlled experimental comparison, not a prediction derived from the claimed result. The protocol's safety argument is inherited from DPR [51]: Section 4.2 says "Because our protocol is mostly a restatement of the DPR protocol in a message-passing model, its correctness largely follows from DPR," and then sketches an equivalence between a libDSE StateObject and "the combination of a cache-store and an execution thread." This is a self-citation and it is load-bearing, but DPR is an independently published SIGMOD result with its own proof and assumptions that do not include the libDSE result. Under the reviewing rules, such a citation counts as real evidence and does not constitute circularity. The genuine gap is that the equivalence is asserted as "one can demonstrate" without a formal proof, and the treatment of sthreads, concurrent actions, and the stateless coordinator is abbreviated; that is an omitted proof and a correctness risk, not a reduction of the conclusion to the premise. No equation or protocol definition in the paper is defined in terms of its own output: the Commit Ordering Rule and the Recovery Sequencing and Partition Rules are stated invariants, and dependency graph edges are defined by recovery dependency rather than by the prefix-recoverability property they are used to establish. I found no fitted parameter renamed as a prediction, no uniqueness theorem imported from the authors, and no ansatz smuggled in via citation. Section 5.3 candidly lists limitations such as aggressive rollback and the need for applications to switch to speculative building blocks; those are honest scope statements, not circular reasoning. Therefore the appropriate finding is no significant circularity.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central protocol claim rests on the untransferred correctness of DPR and on the coordinator's ability to compute boundaries from an outdated view; the quantitative claim rests on the self-simulated baseline. No new physical entities are introduced; DSE, actions, and sthreads are behavioral abstractions of the existing execution model, not entities with falsifiable handles outside the paper.

free parameters (1)
  • group commit frequency = 10ms in most experiments; 500ms in one event-processing run
    Design knob for how often StateObjects persist. The latency savings claim depends on this value; larger values increase savings but also increase rollback scope. Chosen by the authors, not fitted to data.
assumptions (4)
  • domain assumption DPR protocol correctness transfers to libDSE's message-passing StateObject/action model via the stated equivalence
    Section 4.2 states 'its correctness largely follows from DPR' after sketching an equivalence between StateObjects and DPR cache-stores. The equivalence is asserted, not formally proved.
  • ad hoc to paper The coordinator's possibly-outdated view of the dependency graph is sufficient to compute correct recoverable boundaries
    Section 4.3 claims any boundary found on the coordinator's view must also be recoverable on a later view, relying on immutability of persistent graph fragments. No proof is given.
  • domain assumption Services are fail-restart stateful components whose external environment (e.g., Kubernetes) detects failures and reconnects new incarnations
    Section 5.1: 'This assumes that external systems (e.g., Kubernetes) detect down services, replace them, and attempt to reconnect.'
  • domain assumption The self-simulated non-speculative baseline performs the same number of synchronous persistances as Beldi/Boki
    Section 6.1 baseline methodology relies on equivalence of persistence counts; not validated against actual Beldi/Boki runs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Distributed Speculative Execution for Resilient Cloud Applications." pith.science (2026). https://pith.science/paper/X55V5KK4

@misc{pith2026241213314,
  author       = {Pith},
  title        = {Pith review of: Distributed Speculative Execution for Resilient Cloud Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X55V5KK4}},
  note         = {Machine review of arXiv:2412.13314}
}
read the original abstract

Fault-tolerance is critically important in highly-distributed modern cloud applications. Solutions such as Temporal, Azure Durable Functions, and Beldi hide fault-tolerance complexity from developers by persisting execution state and resuming seamlessly from persisted state after failure. This pattern, often called durable execution, usually forces frequent and synchronous persistence and results in hefty latency overheads. In this paper, we propose distributed speculative execution (DSE), a technique for implementing the durable execution abstraction without incurring this penalty. With DSE, developers write code assuming synchronous persistence, and a DSE runtime is responsible for transparently bypassing persistence and reactively repairing application state on failure. We present libDSE, the first DSE application framework that achieves this vision. The key tension in designing libDSE is between imposing restrictions on user programs so the framework can safely and transparently change execution behavior, and avoiding assumptions so libDSE can support more use cases. We address this with a novel programming model centered around message-passing, atomic code blocks, and lightweight threads, and show that it allows developers to build a variety of speculative services, including write-ahead logs, key-value stores, event brokers, and fault-tolerant workflows. Our evaluation shows that libDSE reduces end-to-end latency by up to an order of magnitude compared to current generations of durable execution systems with minimal run-time overhead and manageable complexity.

Figures

Figures reproduced from arXiv: 2412.13314 by the authors.

Figure 1
Figure 1. A Simple Running Example 2 Motivation 2.1 Background: Durable Execution Durable execution creates an illusion of uninterrupted, failure￾free execution by persisting application state at every step and automatically retrying execution after failure. This strong abstraction hides many distributed system complexities from the average developer, but often at the cost of performance. Running Example. Consider a toy examp… view at source ↗
Figure 2
Figure 2. Example Applications that benefit from DSE frequently and synchronously persist state, causing increased latency that DSE can help address. We later describe how we build an application from each class with libDSE and demonstrate the benefits in Section 6. Resilient Workflows. As mentioned, resilient workflow sys￾tems typically must persist their state synchronously between steps of the workflow. In the example of F… view at source ↗
Figure 3
Figure 3. Example StateObject Implementation 1 message IncrementRequest { 2 bytes header = 1; 3 int incrementBy = 2; 4 } 5 message IncrementResponse { 6 bytes header = 1; 7 int result = 2; 8 } 9 service CounterService { 10 ... 11 } 13 // gRPC generated interface 14 class CounterImpl : CounterServiceBase { 15 CounterStateObject so; 17 override IncrementResponse Increment( 18 IncrementRequest r) { 19 if (!so. StartAction(r.head… view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Example CounterService Implementation time uses ListVersions to determine (unpruned) successful Persist calls. This API easily allows for alternative imple￾mentations of persistence and recovery. For example, one can implement the counter service via either logging and…
Figure 6
Figure 6. Figure 6: Distributed Prefix Recovery caches fail, which may cause application anomalies as readers may have acted on lost updates. DPR presents a lightweight protocol for addressing this problem. First, operation com￾pletion and persistence are decoupled using two acknowl￾edgem…
Figure 5
Figure 5. Figure 5: Example Workflow Implementation with libDSE ceived becomes non-speculative, thus preventing speculation across the barrier. Only sthreads are allowed to invoke barri￾ers, as they are, by definition, blocking. Barriers are useful when interacting with external entities.…
Figure 7
Figure 7. Figure 7: Example Dependency Graph 4.2 Protocol Details Like DPR, the libDSE protocol centers around explicit recov￾ery dependency tracking with a dependency graph, as shown in [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: libDSE Coordinator Design local cache-store), the libDSE protocol is equivalent to the DPR protocol. 4.3 Coordinator Design We now describe the design of our coordinator. As shown in [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: TravelReservations group commit frequency of 10ms. For microbenchmarks, we use a pair of D32s_v3 machines [15] (as client and server), each with 32 vCPUs and 128 GB of RAM. 6.1 End-to-End Benchmarks TravelReservations. We first assemble a travel reservation system base…
Figure 10
Figure 10. Figure 10: shows the result of our experiment. We issue a pre-generated trace of events at a steady rate of 50k events/s for 120 seconds, varying the group commit frequency (c). p50 latency p95 latency bytes written dse baseline 0 40 80 120 160 Latency (ms) (a) c=10ms dse baseli…
Figure 11
Figure 11. Figure 11: TwoPhaseCommit The first two plots demonstrate latency savings, where DSE drastically reduces the end-to-end latency of the workload. Importantly, in the case of stream processing, DSE is more than a latency saving; the bottom graph shows the number of bytes written t…
Figure 12
Figure 12. Figure 12: EventProcessing-recovery (a) speculative (b) non-speculative [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: TwoPhaseCommit-recovery group commit frequency. There are a few “lucky” transactions that complete the first round of messages at the end of the last group commit and therefore finish close to 10ms, but most transactions wait for longer. With speculative execution, th…
Figure 15
Figure 15. Figure 15: Thread scalability of libDSE Primitives acquire protection under a tight-loop concurrently, report￾ing throughput as the number of concurrent threads increase. A background thread periodically performs (empty) check￾points to advance versions. We measure three sets of…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. SpecBox: Speculative Sandbox Scheduling for Efficient LLM Agent Serving

    cs.DC 2026-07 conditional novelty 6.0 of 10

    SpecBox overlaps LLM agent sandbox preparation with token generation and predicts future tool sandboxes, cutting P99 latency by 2.9× and peak memory by 45.9% in its prototype.

Reference graph

Works this paper leans on

74 extracted references · 72 canonical work pages · cited by 1 Pith paper

  1. [1]

    https://pubs.opengroup.org/ onlinepubs/009680699/toc.pdf, 1991

    Technical standard – distributed transaction processing: the xa specification. https://pubs.opengroup.org/ onlinepubs/009680699/toc.pdf, 1991

    work page arXiv 1991

  2. [2]

    https://qconnewyork.com/ny2013/ node/231.html, 2013

    Decomposing twitter: Adventures in service-oriented architecture. https://qconnewyork.com/ny2013/ node/231.html, 2013. QCon New York 2013

    work page 2013

  3. [3]

    https://hpts.ws/papers/2019/ PhilBernsteinHPTS2019.pdf, 2019

    Orleans transactions for middle-tier stateful ap- plications. https://hpts.ws/papers/2019/ PhilBernsteinHPTS2019.pdf, 2019

    work page 2019

  4. [4]

    https://microsoft.github.io/ AMBROSIA/, 2024

    Ambrosia: Robust distributed programming made easy and efficient. https://microsoft.github.io/ AMBROSIA/, 2024

    work page 2024

  5. [5]

    https://airflow.apache.org/, 2024

    Apache airflow. https://airflow.apache.org/, 2024

    work page 2024

  6. [6]

    https://dotnet.microsoft.com/en- us/apps/aspnet, 2024

    Asp.net core. https://dotnet.microsoft.com/en- us/apps/aspnet, 2024

    work page 2024

  7. [7]

    https://learn.microsoft.com/en-us/azure/ event-hubs/event-hubs-about , 2024

    Azure event hubs: A real-time data stream- ing platform with native apache kafka support. https://learn.microsoft.com/en-us/azure/ event-hubs/event-hubs-about , 2024

    work page 2024

  8. [8]

    https:// learn.microsoft.com/en-us/azure/azure- functions/functions-overview, 2024

    Azure functions overview. https:// learn.microsoft.com/en-us/azure/azure- functions/functions-overview, 2024

    work page 2024

Show all 74 references
  1. [9]

    https:// learn.microsoft.com/en-us/azure/storage/ common/storage-redundancy, 2024

    Azure storage redundancy. https:// learn.microsoft.com/en-us/azure/storage/ common/storage-redundancy, 2024

    2024

  2. [10]

    https://temporal.io/blog/building-reliable- distributed-systems-in-node , 2024

    Building reliable distributed systmes in node.js. https://temporal.io/blog/building-reliable- distributed-systems-in-node , 2024

    2024

  3. [11]

    https://cloud.google.com/ composer, 2024

    Cloud composer. https://cloud.google.com/ composer, 2024

    2024

  4. [12]

    https://www.dbos.dev/, 2024

    Dbos – transactional serverless platform for typescript. https://www.dbos.dev/, 2024

    2024

  5. [13]

    https:// orkes.io/blog/durable-execution-explained- how-conductor-delivers-resilient-systems/ , 2024

    Durable execution explained – how conductor de- livers resilient systems out of the box. https:// orkes.io/blog/durable-execution-explained- how-conductor-delivers-resilient-systems/ , 2024

    2024

  6. [14]

    https://temporal.io/blog/building-reliable- distributed-systems-in-node , 2024

    Durable execution: Justifying the bubble. https://temporal.io/blog/building-reliable- distributed-systems-in-node , 2024

    2024

  7. [15]

    https:// learn.microsoft.com/en-us/azure/virtual- machines/dv3-dsv3-series, 2024

    Dv3 and dsv3-series. https:// learn.microsoft.com/en-us/azure/virtual- machines/dv3-dsv3-series, 2024

    2024

  8. [16]

    https: //blog.redplanetlabs.com/2024/01/09/ everything-wrong-with-databases-and-why- their-complexity-is-now-unnecessary/ , 2024

    Everything wrong with databases and why their complexity is now unnecessary. https: //blog.redplanetlabs.com/2024/01/09/ everything-wrong-with-databases-and-why- their-complexity-is-now-unnecessary/ , 2024

    2024

  9. [17]

    https: //stealthrocket.tech/blog/fairy-tales-of- workflow-orchestration, 2024

    Fairy tales of workflow orchestration. https: //stealthrocket.tech/blog/fairy-tales-of- workflow-orchestration, 2024

    2024

  10. [18]

    https://microsoft.github.io/FASTER/, 2024

    Faster: A fast concurrent persistent key-value store and log. https://microsoft.github.io/FASTER/, 2024

    2024

  11. [19]

    https://microsoft.github.io/ FASTER/docs/fasterlog-basics/, 2024

    Fasterlog basics. https://microsoft.github.io/ FASTER/docs/fasterlog-basics/, 2024

    2024

  12. [20]

    https://flawless.dev/, 2024

    Flawless. https://flawless.dev/, 2024

    2024

  13. [21]

    https://grpc.io/, 2024

    grpc: A high performance, open source universal rpc framework. https://grpc.io/, 2024

    2024

  14. [22]

    https://stack.convex.dev/ how-convex-works, 2024

    How convex works. https://stack.convex.dev/ how-convex-works, 2024. 13

    2024

  15. [23]

    https://grpc.io/docs/guides/ interceptors/, 2024

    Interceptors. https://grpc.io/docs/guides/ interceptors/, 2024

    2024

  16. [24]

    https://www.microsoft.com/en- us/research/blog/introducing-garnet-an- open-source-next-generation-faster-cache- store-for-accelerating-applications-and- services/, 2024

    Introducing garnet – an open-source, next-generation, faster cache-store for accelerating applications and services. https://www.microsoft.com/en- us/research/blog/introducing-garnet-an- open-source-next-generation-faster-cache- store-for-accelerating-applications-and- services/, 2024

    2024

  17. [25]

    https://www.kubeflow.org/, 2024

    Kubeflow. https://www.kubeflow.org/, 2024

    2024

  18. [26]

    https: //git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git/tree/Documentation/ memory-barriers.txt, 2024

    Linux kernel memory barriers. https: //git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git/tree/Documentation/ memory-barriers.txt, 2024

    2024

  19. [27]

    https: //littlehorse.dev/, 2024

    Littlehorse: Workflow-driven microservices. https: //littlehorse.dev/, 2024

    2024

  20. [28]

    https: //azure.microsoft.com/en-us/products/ kubernetes-service, 2024

    Managed kubernetes service (aks). https: //azure.microsoft.com/en-us/products/ kubernetes-service, 2024

    2024

  21. [29]

    https://learn.microsoft.com/ en-us/dotnet/orleans/overview, 2024

    Microsoft orleans. https://learn.microsoft.com/ en-us/dotnet/orleans/overview, 2024

    2024

  22. [30]

    https://temporal.io/, 2024

    Open source durable execution | temporal technologies. https://temporal.io/, 2024

    2024

  23. [31]

    https: //learn.microsoft.com/en-us/azure/storage/ common/storage-redundancy, 2024

    Saga distributed transaction pattern. https: //learn.microsoft.com/en-us/azure/storage/ common/storage-redundancy, 2024

    2024

  24. [32]

    https://restate.dev/blog/ why-we-built-restate/ , 2024

    Why we built restate. https://restate.dev/blog/ why-we-built-restate/ , 2024

    2024

  25. [33]

    Berenson, P

    H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O’Neil, and P. O’Neil. A critique of ansi sql isolation levels. SIGMOD Rec., 24(2):1–10, may 1995

    1995

  26. [34]

    DeCandia, D

    G. DeCandia, D. Hastorun, M. Jampani, G. Kakula- pati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. V osshall, and W. V ogels. Dynamo: amazon’s highly available key-value store. In Proceedings of Twenty- First ACM SIGOPS Symposium on Operating Systems Principles, SOSP ’07, ...

    2007

  27. [35]

    D. J. DeWitt, R. H. Katz, F. Olken, L. D. Shapiro, M. R. Stonebraker, and D. A. Wood. Implementation tech- niques for main memory database systems. SIGMOD Rec., 14(2):1–8, jun 1984

    1984

  28. [36]

    Dice and A

    D. Dice and A. Kogan. BRA VO—Biased locking for Reader-Writer locks. In 2019 USENIX Annual Technical Conference (USENIX ATC 19), pages 315–328, Renton, W A, July 2019. USENIX Association

    2019

  29. [37]

    Eldeeb and P

    T. Eldeeb and P. Bernstein. Transactions for distributed actors in the cloud. Technical Report MSR-TR-2016- 1001, October 2016

    2016

  30. [38]

    Eldeeb, S

    T. Eldeeb, S. Burckhardt, R. Bond, A. Cidon, J. Yang, and P. A. Bernstein. Cloud actor-oriented database trans- actions in orleans. volume 17, page 3720–3730. VLDB Endowment, aug 2024

    2024

  31. [39]

    E. N. M. Elnozahy, L. Alvisi, Y .-M. Wang, and D. B. Johnson. A survey of rollback-recovery protocols in message-passing systems. ACM Comput. Surv. , 34(3):375–408, sep 2002

    2002

  32. [40]

    Y . Gan, Y . Zhang, D. Cheng, A. Shetty, P. Rathi, N. Katarki, A. Bruno, J. Hu, B. Ritchken, B. Jackson, K. Hu, M. Pancholi, Y . He, B. Clancy, C. Colen, F. Wen, C. Leung, S. Wang, L. Zaruvinsky, M. Espinosa, R. Lin, Z. Liu, J. Padilla, and C. Delimitrou. An open-source benchm...

    2019

  33. [41]

    Gawlick and D

    D. Gawlick and D. Kinkade. Varieties of concurrency control in ims/vs fast path. IEEE Database Eng. Bull., 8:3–10, 01 1985

    1985

  34. [42]

    Goldstein, A

    J. Goldstein, A. Abdelhamid, M. Barnett, S. Burckhardt, B. Chandramouli, D. Gehring, N. Lebeck, C. Meikle- john, U. F. Minhas, R. Newton, R. Ghosh Peshawaria, T. Zaccai, and I. Zhang. A.m.b.r.o.s.i.a: Providing per- formant virtual resiliency for distributed applications. Tech...

    2018

  35. [43]

    Jia and E

    Z. Jia and E. Witchel. Boki: Stateful serverless com- puting with shared logs. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Prin- ciples, SOSP ’21, page 691–707, New York, NY , USA,

  36. [44]

    Jonas, J

    E. Jonas, J. Schleier-Smith, V . Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V . Shankar, J. Carreira, K. Krauth, N. Yadwadkar, J. E. Gonzalez, R. A. Popa, I. Stoica, and D. A. Patterson. Cloud programming simplified: A berkeley view on serverless computing, 2019

    2019

  37. [45]

    Kraft, Q

    P. Kraft, Q. Li, K. Kaffes, A. Skiadopoulos, D. Ku- mar, D. Cho, J. Li, R. Redmond, N. Weckwerth, B. Xia, P. Bailis, M. Cafarella, G. Graefe, J. Kepner, C. Kozyrakis, M. Stonebraker, L. Suresh, X. Yu, and M. Zaharia. Apiary: A dbms-integrated transactional function-as-a-servic...

    2023

  38. [46]

    Kraft, Q

    P. Kraft, Q. Li, X. Zhou, P. Bailis, M. Stonebraker, M. Zaharia, and X. Yu. Epoxy: Acid transactions across diverse data stores. Proc. VLDB Endow. , 16(11):2742–2754, jul 2023

    2023

  39. [47]

    Kreps, N

    J. Kreps, N. Narkhede, J. Rao, et al. Kafka: A distributed messaging system for log processing. In Proceedings of the NetDB, volume 11, pages 1–7. Athens, Greece, 2011

    2011

  40. [48]

    L. Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558–565, jul 1978

    1978

  41. [49]

    Lee and J

    C. Lee and J. Ousterhout. Granular computing. In Proceedings of the Workshop on Hot Topics in Operat- ing Systems, HotOS ’19, page 149–154, New York, NY , USA, 2019. Association for Computing Machinery

    2019

  42. [50]

    T. Li, B. Chandramouli, S. Burckhardt, and S. Madden. Darq matter binds everything: Performant and compos- able cloud programming via resilient steps. Proc. ACM Manag. Data, 1(2), jun 2023

    2023

  43. [51]

    T. Li, B. Chandramouli, J. M. Faleiro, S. Madden, and D. Kossmann. Asynchronous prefix recoverability for fast distributed stores. In Proceedings of the 2021 Inter- national Conference on Management of Data, SIGMOD ’21, page 1090–1102, New York, NY , USA, 2021. Asso- ciation f...

    2021

  44. [52]

    T. Li, B. Chandramouli, and S. Madden. Performant almost-latch-free data structures using epoch protection. In Proceedings of the 18th International Workshop on Data Management on New Hardware, DaMoN ’22, New York, NY , USA, 2022. Association for Computing Ma- chinery

    2022

  45. [53]

    T. Li, B. Chandramouli, and S. Madden. Performant almost-latch-free data structures using epoch protection in more depth. The VLDB Journal, 2024

    2024

  46. [54]

    N. A. Lynch and M. R. Tuttle. Hierarchical correct- ness proofs for distributed algorithms. In Proceedings of the Sixth Annual ACM Symposium on Principles of Distributed Computing, PODC ’87, page 137–151, New York, NY , USA, 1987. Association for Computing Ma- chinery

    1987

  47. [55]

    Mohan, B

    C. Mohan, B. Lindsay, and R. Obermarck. Transaction management in the r* distributed database management system. ACM Trans. Database Syst. , 11(4):378–396, dec 1986

    1986

  48. [56]

    D. G. Murray, F. McSherry, R. Isaacs, M. Isard, P. Barham, and M. Abadi. Naiad: a timely dataflow system. In Proceedings of the Twenty-Fourth ACM Sym- posium on Operating Systems Principles , SOSP ’13, page 439–455, New York, NY , USA, 2013. Association for Computing Machinery

    2013

  49. [57]

    E. B. Nightingale, P. M. Chen, and J. Flinn. Speculative execution in a distributed file system. SIGOPS Oper. Syst. Rev., 39(5):191–205, oct 2005

    2005

  50. [58]

    E. B. Nightingale, K. Veeraraghavan, P. M. Chen, and J. Flinn. Rethink the sync. ACM Trans. Comput. Syst., 26(3), Sept. 2008

    2008

  51. [59]

    Ongaro and J

    D. Ongaro and J. Ousterhout. In search of an under- standable consensus algorithm. In 2014 USENIX An- nual Technical Conference (USENIX ATC 14) , pages 305–319, Philadelphia, PA, June 2014. USENIX Asso- ciation

    2014

  52. [60]

    Prasaad, B

    G. Prasaad, B. Chandramouli, and D. Kossmann. Con- current prefix recovery: Performing cpr on a database. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD ’19, page 687–704, New York, NY , USA, 2019. Association for Computing Machinery

    2019

  53. [61]

    S. Qi, X. Liu, and X. Jin. Halfmoon: Log-optimal fault- tolerant stateful serverless computing. In Proceedings of the 29th Symposium on Operating Systems Principles, SOSP ’23, page 314–330, New York, NY , USA, 2023. Association for Computing Machinery

    2023

  54. [62]

    D. P. Reed. Naming and synchronization in a decentral- ized computer system. Technical report, USA, 1978. 15

    1978

  55. [63]

    Russell and D

    K. Russell and D. Detlefs. Eliminating synchronization- related atomic operations with biased locking and bulk rebiasing. In Proceedings of the 21st Annual ACM SIG- PLAN Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA ’06, page 263–272, N...

    2006

  56. [64]

    F. B. Schneider. Implementing fault-tolerant services us- ing the state machine approach: a tutorial.ACM Comput. Surv., 22(4):299–319, dec 1990

    1990

  57. [65]

    Setty, C

    S. Setty, C. Su, J. R. Lorch, L. Zhou, H. Chen, P. Patel, and J. Ren. Realizing the Fault-Tolerance promise of cloud storage using locks with intent. In 12th USENIX Symposium on Operating Systems Design and Imple- mentation (OSDI 16), pages 501–516, Savannah, GA, Nov. 2016. US...

    2016

  58. [66]

    J. E. Smith. A study of branch prediction strategies. In Proceedings of the 8th Annual Symposium on Computer Architecture, ISCA ’81, page 135–148, Washington, DC, USA, 1981. IEEE Computer Society Press

    1981

  59. [67]

    Sreekanti, C

    V . Sreekanti, C. Wu, S. Chhatrapati, J. E. Gonzalez, J. M. Hellerstein, and J. M. Faleiro. A fault-tolerance shim for serverless computing. In Proceedings of the Fifteenth European Conference on Computer Systems, EuroSys ’20, New York, NY , USA, 2020. Association for Computin...

    2020

  60. [68]

    G. Wang, L. Chen, A. Dikshit, J. Gustafson, B. Chen, M. J. Sax, J. Roesler, S. Blee-Goldman, B. Cadonna, A. Mehta, V . Madan, and J. Rao. Consistency and completeness: Rethinking distributed stream processing in apache kafka. In Proceedings of the 2021 Interna- tional Conferen...

    2021

  61. [69]

    S. Wang, J. Liagouris, R. Nishihara, P. Moritz, U. Misra, A. Tumanov, and I. Stoica. Lineage stash: fault tolerance off the critical path. In Proceedings of the 27th ACM Symposium on Operating Systems Principles, SOSP ’19, page 338–352, New York, NY , USA, 2019. Association fo...

    2019

  62. [70]

    Zaharia, M

    M. Zaharia, M. Chowdhury, T. Das, A. Dave, J. Ma, M. McCauley, M. J. Franklin, S. Shenker, and I. Stoica. Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing. In Proceedings of the 9th USENIX Conference on Networked Systems De- sign and...

    2012

  63. [71]

    Zhang, A

    H. Zhang, A. Cardoza, P. B. Chen, S. Angel, and V . Liu. Fault-tolerant and transactional stateful serverless work- flows. In 14th USENIX Symposium on Operating Sys- tems Design and Implementation (OSDI 20) , pages 1187–1204. USENIX Association, Nov. 2020

    2020

  64. [72]

    Zhang, K

    J. Zhang, K. Huang, T. Wang, and K. Lv. Skeena: Effi- cient and consistent cross-engine transactions. In Pro- ceedings of the 2022 International Conference on Man- agement of Data, SIGMOD ’22, page 34–48, New York, NY , USA, 2022. Association for Computing Machinery

    2022

  65. [73]

    Zhuang, S

    S. Zhuang, S. Wang, E. Liang, Y . Cheng, and I. Stoica. ExoFlow: A universal workflow system for Exactly- Once DAGs. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23), pages 269–286, Boston, MA, July 2023. USENIX Association. 16

    2023

  66. [2021]

    Association for Computing Machinery. 14

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.