Start a Conversation
DemosCRASH DEMO

Unacknowledged

A distributed system is least trustworthy in the moment between deciding to send a message and actually sending it. If the process dies there, the sender is no longer in a position to say whether the message arrived — and what it does with that gap is more revealing than how it recovers. Here the gap is opened deliberately: one actor sells something, records that it is telling another, and is killed before the message leaves.

The question

After a crash, who is entitled to say whether a message arrived — and what should a system record while nothing can honestly be said yet?

First, who owns the relationship

The same purchase-and-reward runs three ways over the same two actors. Every style rewards the customer, so the outcome is not what differs. What differs is who ends up holding the fact that the purchase and the reward belong together.

StyleOutcomeOwns the relationship
Orchestrated sagaCustomer rewardedA coordinator
Event choreographyCustomer rewardedA bus log, outside every program
Told directlyCustomer rewardedThe sender itself

Read off the printed records of a run rather than from a diagram. In the first two styles the sender's own record holds its purchase and nothing about the reward. In the third it holds the purchase, the assertion that produced the reward, and the acknowledgement that closed the exchange — one history, in the order it happened.

Then the crash

The interesting failure is not a lost message. It is a message whose fate is unknown.

  1. 01Commit · tell recordedThe sender commits the purchase, and records that it is telling the reward engine.
  2. 02Process diesBefore the transport ever sees the message, the process dies.the window in which nothing can be inferred from outside
  3. 03Reconstructed from the recordA new actor is reconstructed entirely from the persisted record.
  4. 04One fate unknownIt finds one message whose fate is still unknown.
  5. 05Transport askedOnly then does it ask the transport what actually happened.

From there, the uncertainty can be resolved in three ways, and two of them are guesses: assume it worked, retry blindly, or reconstruct the story afterwards from records kept somewhere else. Here the record keeps the uncertainty instead — until a party genuinely able to resolve it can speak. Uncertainty becomes part of the history rather than something hidden by recovery.

Three fates, three things written

The same crash and the same record, with three different answers from the transport. What gets written differs in each — including the case where nothing does.

  1. FateIt failed

    Transport's answer
    Not delivered
    What the record gets
    tell 'ord-100' unacknowledged by RewardEngine;

    Unacknowledged

  2. FateIt arrived

    Transport's answer
    Delivered
    What the record gets
    An acknowledgement

    Acknowledged

  3. FateNobody knows yet

    Transport's answer
    Still in flight
    What the record gets
    Nothing at all — the message stays pending

    Pending

The first outcome carries the strongest claim, and three things had to hold before that line could be written.

  1. The sender speaks only about the actor that failed to answer, never about the infrastructure it has no standing to speak for.
  2. It never invents an acknowledgement that did not happen.
  3. And recovery reconstructs the pending message without sending it again.

What follows from the record alone

Three further properties measured on that same record, each of them about something that turns out not to be needed.

  • ReconstructionA fresh actor reconstructs the in-flight message from the record alone — no transport, no receiver, no state handed to it from anywhere.No longer needed: TransportReceiverState handed over
  • ReplicationCopying the record's bytes to another site carries the cross-actor chain with them, because the relation was written in the one place replication already moves.No longer needed: Replicating the relation separately
  • Causal explanationAsking why something happened is reading one record: the cause, the message it produced and the acknowledgement that closed it are all in the sender's history. No distributed tracing, no correlation identifiers, no log aggregation.No longer needed: Distributed tracingCorrelation identifiersLog aggregation

What it does not establish

Three limits, and the last line is the one to keep.

  1. It holds per edge, not end to end. No single record holds a whole A→B→C chain; reconstructing one means composing the records of A and of B, linked by the message's identifier across them. The sender's-record property covers the hops that sender originates — which is the whole chain only when the chain is one hop.
  2. The verdict is only as good as what the transport can testify. A transport that cannot say leaves the message pending, which is the honest answer rather than a good one.
  3. Nothing here is a throughput or a latency result. The laboratory is deterministic and its evidence is records, which is what the paper says of itself.

The guarantee, in the paper's own words, is “honesty about the outcome, not omniscience.”

Grounded in

Where this comes from.