The Life of an Order: From First Fill to Engine Recovery

A customer submits an order to buy ten units, sees a partial fill, presses Cancel, and loses the connection.

The engine stops before the cancellation result arrives. When service returns, the customer owns nine units. One unfilled unit was canceled.

To explain that outcome, we need the order book, queue rules, fill arithmetic, cancellation timing, and recoverable history to agree. A single incident lets us follow each decision from the original buy instruction to the final account record.

Our market’s contract

Harbor is a fictional single-venue market for BAG, a fictional instrument quoted in dollars. Its order book records buy and sell instructions waiting to trade. A resting order is one already waiting in the book; the matching engine selects compatible orders and records completed trades, called fills. A partial fill executes some of the requested quantity while leaving a remainder.

Harbor trades whole units at one-dollar price increments. All orders are fully displayed and belong to different owners. Price-time priority means the best eligible price comes first, then the earlier resting order at that price. Trades use the resting order’s price. A buy limit sets the most the buyer will pay, and a sell limit sets the least the seller will accept. Good till canceled (GTC) allows an unfilled remainder to keep working under Harbor’s rules.

There are no hidden orders, auctions, external routing, fees, or settlement calculations in the example. Coinbase Exchange documents comparable price-time and resting-price behavior, but Harbor’s recovery design and identifiers are our own explicit assumptions. Coinbase Exchange matching rules

Harbor keeps an ordered journal, a durable history of commands such as orders and cancellations, across three replicas. A command is committed when the replication protocol has established it as authoritative history; it is applied when matching has carried out its effect. Harbor requires a durable majority of the three replicas before applying a command or publishing its definitive business outcome.

A snapshot saves the complete application state at a known applied position. Recovery loads that snapshot and replays the later committed commands. Processing is deterministic: the same state and ordered instructions reproduce the same results. Stable request and output identities let clients and account systems recognize repeated delivery. The scenario assumes a single replica failure within those storage and protocol assumptions.

This architecture resembles the replicated-state-machine pattern documented by Aeron. It does not describe the internals of a named exchange. Aeron replicated state machines

Before the customer clicks

At applied command position 103, Harbor has saved a consistent snapshot. Sequence numbers identify processing positions on this market, with lower numbers coming first. Live units are the unfilled quantity still available to trade:

Order	Side	Limit	Live units	Priority sequence
B1	Buy	$99	6	100
S1	Sell	$100	4	101
S2	Sell	$100	3	102
S3	Sell	$101	5	103

The screen can show seven offered at $100. The engine retains S1 and S2 individually because they have different owners and different places in the queue.

B1 is a bid, an instruction to buy; S1, S2, and S3 are asks, instructions to sell. The highest bid is $99 and the lowest ask is $100. Those prices do not meet, so the initial orders wait for another participant.

The snapshot preserves those places and the other state needed to continue processing. Rebuilding an aggregate seven-unit ask without the individual priority would not restore the same market.

Command 104 turns one order into two trades

M1 arrives: buy ten at a $100 limit, GTC. Harbor’s gateway checks the request and admits it to the ordered command path. Once committed as command 104, matching applies it to the book.

S1 has the first eligible four units. S2 has the next three. S3 asks $101, so M1 cannot reach it.

Event identity	Maker	Taker	Units	Price	M1 cumulative fill
104.1	S1	M1	4	$100	4
104.2	S2	M1	3	$100	7

Harbor’s event identities are scoped to this market journal; they are not proposed FIX tags or Coinbase sequence numbers.

M1 has bought seven for $700. Its other three units rest at $100. B1 still bids $99; S3 still asks $101.

The order has changed roles. It took liquidity on arrival, then became a resting source of liquidity. A single label such as “limit order” does not tell us which role applied to each execution.

The incoming order that immediately consumes resting interest is called the taker; the resting counterparty is the maker. M1 was the taker against S1 and S2. If a later seller trades with M1’s waiting remainder, M1 will be the maker for that execution.

The customer starts cancellation while another order arrives

After seeing the partial fill, the customer sends C1 to cancel M1. The gateway receives it, but another participant’s S4 is already ahead in Harbor’s command ordering.

S4 sells two at a $100 limit and becomes command 105. It matches against M1’s resting bid. Trade 105.1 buys two more units for M1 at $100.

M1 now has nine executed for $900 and one unit still working. It has an execution as a resting maker as well as its earlier executions as an incoming taker. No fees are modeled here.

C1 becomes command 106. Harbor durably commits it. Then the active matching process fails before applying the cancellation or delivering its outcome.

At failure, the client knows it sent a cancel. Depending on which reports reached it, it may still display seven executed and three pending cancellation. The committed market history already contains the command that will resolve the remaining quantity.

FIX’s cancellation examples show why a pending request and a newly arriving fill can coexist. That protocol model supports the race; Harbor supplies this particular command order and quantity result. FIX order-state changes, scenarios B.1.b and B.1.c

Three positions describe the interruption

An operator needs to distinguish:

Position or observation	State at the interruption
Latest consistent snapshot	Through command 103
Matching process applied state	Through command 105
Authoritative committed history	Through command 106
Customer’s observed reports	Possibly only the first seven units, plus local cancel intent

These do not need to be equal at every instant. The design must explain how they converge.

The failed process’s memory alone would leave one unit working. The customer’s screen might suggest three. The committed journal tells recovery to apply C1 after the two-unit fill. Each layer needs an identified position and a documented way to catch up.

The diagram shows the full path from request admission to matching, reports, and recovery. The return path through matching represents controlled state reconstruction. It does not permit replay to place new economic trades on behalf of the customer.

Recovery finishes the established history

Harbor establishes a replacement leader authorized to order work, blocks the former leader’s output from being accepted, and selects the committed recovery boundary. It loads snapshot 103 and applies the journal:

1. Replay 104. Reproduce the four- and three-unit trades and M1’s three-unit bid.
2. Replay 105. Reproduce the two-unit trade and reduce M1 to one working unit.
3. Replay 106. Cancel that unit and record C1’s completed result.

The reconstructed events retain identities 104.1, 104.2, and 105.1; Harbor records the cancellation outcome as 106.1. Replayed state changes and recovered report delivery must not create fresh financial postings for executions that consumers already recorded.

Harbor’s retained request-result state also lets it recognize a supported retry of C1 within its promised retry window. A lost response does not turn C1 into a new instruction. The Raft paper discusses this ambiguity and a client-serial/result approach; the exact identity scope and retention remain part of Harbor’s application contract. Raft paper, section 8

Recovery does not replay the customer’s last screen, sort instructions by click time, or rearrange 105 and 106 because the cancel feels as though it should have won.

Figure 6.1. After 104, M1 has seven executed and three working. After 105, it has nine executed and one working. At the crash that applied state remains, while cancel 106 is already committed. Replay through 106 leaves nine executed, one canceled and zero working.

What the customer and operator should see

After private report recovery and reconciliation, M1’s final accounting is:

Quantity or value	Final result
Original requested units	10
Executed units	9
Gross executed value	$900
Average execution price	$100
Canceled, unfilled units	1
Still working	0

M1 is terminal with an unfilled cancellation, while retaining all nine executed units. “Canceled” cannot mean the position is zero.

Harbor’s remaining relevant book is B1 buying six at $99 and S3 selling five at $101. Those orders stayed untouched throughout. The operator also checks the private execution records, risk state, and ledger consumers; the correct public book alone cannot establish the customer’s position.

Figure 6.2. Events 104.1, 104.2 and 105.1 execute four, three and two units at $100, for $400, $300 and $200. Cancellation 106.1 removes one unfilled unit and adds no purchase. Total executed quantity remains nine and gross spend remains $900 after replay.

Change the history, and the answer changes

If C1 had been committed before S4, it would remove M1’s three-unit remainder. M1 would finish with seven executed and three canceled. In this book, S4’s $100 sell could not trade with B1’s $99 bid; its GTC remainder would rest at $100.

If S4 instead sold all three remaining units before C1, M1 would finish fully filled. Harbor would reject C1 as too late.

If C1 had reached only a failed gateway and never entered committed history, recovery could not presume a successful cancellation. The client would need the venue’s recovery procedure to resolve the request and the live order.

Those are alternative histories. Restarting the same committed history must preserve its answer.

Reopening the market

Harbor resumes intake after its authority, restored state, report recovery, and required consumer reconciliation checks pass. A real venue may also impose a halt, order purge, or reopening auction under its own rules; our continuous-book scenario promises none of those policies for other markets.

Matching determines which orders trade. Brokers, risk services, account ledgers, custody, clearing, and settlement carry additional responsibilities outside this example. Restoring the execution history does not complete all of them.

The customer’s incident can now be stated precisely: M1 bought seven on arrival, bought two more before its cancellation was sequenced, and canceled the last unit after committed-history recovery. The client learned the last events late. Its final position still needs to include nine units.