Examples
Walk through writes, retries, and recovery.
Ceramic mug · $18 3 in stock
Illustrative purchase · no payment collected
Three mugs. Ready to sell.
The store has three mugs. Its service reads the price and stock from its own memory. Click Buy one to purchase a mug for $18.
Cart: 1 mug · $18Inside the log
0 entries · next position 100| Position | Write · expand to inspect | Processed by |
|---|
No new entries yet. Step forward to record a data change.
Purchase application rules
The log records both successful and rejected requests. Your application decides the result during ordered application:
- Reuse the saved result for an identical request ID and command. Reject the same ID with different content.
- For a new request, check stock in the current applied state. Reserve one item or record an out-of-stock result.
- Save the state, request ID, command, result, and next unread position together before replying.
- Replay the same rules after recovery, including rejected requests and saved results. Protect external payments separately.
This walkthrough illustrates those application rules. Try live runs a versioned-text engine; it does not implement stock or payments.
Read the engine algorithm
From the explanation to the engine
Pseudocode using the Mainframe Engine API. Application helpers are illustrative, not a complete implementation. Click any row to follow it in the diagram.
Your engine checks state during apply and saves state, request results, and progress atomically. The handler waits with sync_and_apply(p.next()) before reading the result; p.next() includes entry p. Apply callbacks must tolerate retries after failure or cancellation.
The receipt does not need to wait for every replica. Payment and shipping require separate handling.