Follow a buy order from start to finish
Run the scenario with Previous and Next event. Choose whether a trade notification arrives and how the order ends, then compare the target, holding and records.
Constructed data, with no connection to a real account. This browser model illustrates its rules, not production system performance.
You run the simulation.
Target 2. No order yet.
Target 2 unitsOrder O1 · Not submitted
- Order
- Records
- Outcome
Next · Trading system
Submit a buy order for two units
Target two minus holding zero gives an order for two. This scenario assumes acceptance.
At the provider
Executed trades and holdings
0 units left on the order.
In the books
What the system has recorded
No trade records received yet.
Positions not yet checked
The system has not queried a provider snapshot yet.
Review earlier events
The target, the order and the books
The scenario starts with no holdings and a target of two units. The trading system submits a buy order for those two units. The provider executes trades and keeps its own records; the system updates its books from notifications or queries. Advancing the simulation lets the reader observe each participant’s part.
After the first unit is bought, a notification tells the system to record it. If that notification arrives, both positions are one. If it is lost, the system still records zero.
Querying the provider’s position reveals the difference. Checking its trade history identifies F1 as the missing record. The system can then add F1 and compare the positions again. Reading F1 again does not count it twice.
There is still one unit left on the order. If it fills, the final holding reaches two. If the provider confirms cancellation, the holding stays at one, short of the target. Either way, a final check can confirm that the position in the books matches the provider’s. An unfinished target does not necessarily mean incorrect records.
The accompanying Note explains how this demo’s feedback and next-step guidance changed, with an interactive comparison of the repeat-read layouts.
Why might the same fill arrive again?
A consumer can write F1 into its books, then stop before confirming that it finished. Recovering from the last confirmed point can bring F1 back. At-least-once processing allows that repetition; the books still need to count the trade once.
The repeat-read button illustrates that result. A separate Kafka crash-and-restart experiment examines how to obtain it: keep the fill’s identity and its effect on the holding in the same database transaction. The browser demo itself does not run Kafka.
Model assumptions, inputs and calculation rules
The example starts with zero holdings in one account and one instrument, and a fixed target of two units. Submitting order O1 requests the difference: buy two. Acceptance is assumed; this page does not run a risk engine or simulate rejected orders. The provider executes one unit as fill F1, leaving one unit open.
The provider stores its own fills and position. The internal books only change when they record a received fill. Dropping the F1 notification changes delivery alone. At comparison, new fills are paused and notification processing has ended. The position snapshot and fill-history query cover the same account, instrument and cutoff, through F1.
After the first position check or recovery, the remaining unit can execute as F2, whose notification always arrives. Alternatively, cancellation removes the unfilled quantity only after the provider confirms it. That confirmation is included in the simulated cancel action; cancellation races and failures are outside this example. Neither ending changes the target. Both require a fresh final snapshot, through F2 if it executed or F1 if the remainder was cancelled. There are no other trades, corrections or position adjustments.
The comparison checks position quantity at that checkpoint. Equal quantities do not prove that every underlying record is correct. A difference alone does not identify its cause. Recovery requires a missing fill record: if the history cannot be retrieved, the difference remains unresolved. A previously recorded fill ID is not added again.
Next event calculates the next state from the model inputs. Selecting a notification outcome or ending previews that event; advancing applies it. Previous and the branch links revisit earlier checkpoints in the scenario, rather than reversing a live trade. The downloads below contain the inputs and the code used on this page.
Download model inputs (JSON)Download calculation rules (JavaScript)