Stock trading & order matching engine

I remove concurrency from the decision itself. Every accepted order passes through a sequencer that stamps one monotonic sequence number per partition, and each symbol's book is owned by exactly one pinned thread. That thread reads events in sequence order, so time priority is simply sequence order. No locks, no clock comparisons. Price levels sit in a sorted structure with a FIFO queue per level, and everything lives in preallocated memory to avoid GC or malloc on the hot path. To scale, I add symbol shards rather than threads per book. Busy symbols can get dedicated cores. Networking uses kernel bypass, and I measure p99.9 latency, not averages, because fairness complaints come from the tail.

Because the system is event-sourced, nothing that was acknowledged is lost. The sequencer writes each input to a replicated journal before matching sees it, and clients only get acks after that write. A hot standby consumes the same journal and runs the same deterministic matching code, so its book is identical. I verify this by comparing periodic book hashes. On failure, the standby is promoted, finishes replaying any tail events, and resumes from the next sequence number. Output events carry sequence numbers, so brokers and market-data clients can discard duplicates and request any gaps. Determinism is the key requirement: no random numbers, no wall-clock reads and no hash-map iteration order in matching logic.

The broker OMS validates symbol, lot and tick size, order type, KYC and segment permissions. Its RMS blocks margin in the ledger, then sends the order over FIX or the native protocol. The exchange gateway authenticates the session, applies rate limits and timestamps it. Pre-trade risk checks price bands, quantity and value limits, and member limits. The sequencer assigns a sequence number and durably journals the order. The symbol's matching engine then rests or matches it by price-time priority. Execution reports flow back to the OMS, which updates state and adjusts margin. Book and trade events go out on multicast. Trades go to the clearing corporation, which nets and novates them. Funds and securities settle on T+1, and the broker ledger and the client's demat holding are updated.

Partition by instrument. Each symbol's book has exactly one owner thread, and many symbols share a partition, each with its own sequencer and journal. Hot symbols and heavy derivative underlyings get their own partitions, and we rebalance only between sessions so that ordering never moves mid-day. Ordering is then guaranteed per partition, not globally. Multi-leg orders such as calendar spreads are the hard part. Either all legs live in the same partition, which is the usual answer for spread books on the same underlying, or you need a coordinator. Atomic matching across partitions brings in distributed locking and latency. Exchanges avoid it by co-locating related contracts and listing spreads as their own instruments.

Each order carries a client order ID that is unique per member session or trading day, such as ClOrdID in FIX. The OMS generates it before the first send and stores it with the order. The gateway or sequencer keeps a dedupe index of member plus ClOrdID. If a resend arrives, it returns the existing order's state instead of creating a new one. FIX session-level sequence numbers and the PossDup and PossResend flags handle retransmission at the transport layer. The dedupe index must be rebuilt from the journal on failover, or a retry right after a crash could double-book. Cancels and modifies reference the original order ID, so replaying them is naturally safe.

Primarily at the broker's RMS, before the order leaves, because the broker owns the client's funds and holdings. The RMS keeps an in-memory view of available margin per client, backed by an ACID ledger. It atomically blocks the required margin for each order, so two concurrent orders cannot spend the same money. Fills convert blocked margin into used margin. Rejects and confirmed cancels release it, but only after the exchange confirms them. The exchange adds its own checks, such as price bands and member and position limits, as a second line of defence. End-of-day obligations from the clearing corporation reconcile the ledger. I keep risk off the matching thread so that matching latency stays predictable.

If you match first and the process dies before the log write, you may already have sent an ack or fill that no recovery can reproduce. That loses an acknowledged trade, which is the one thing we must never do. Journaling first means every effect the engine produces can be rebuilt by deterministic replay of the journal. A standby replaying it reaches the identical book and the identical outputs. The cost is replication latency on the critical path, which we keep small with quorum replication across nearby nodes, kernel-bypass networking and small batches. Writing a write-ahead log before any externally visible effect is the core rule here.

The rule should be explicit and documented, because it is part of fairness. The common convention is that reducing quantity keeps the order's place in the queue. It takes no advantage from anyone behind it. Changing the price, or increasing the quantity, is treated as a new arrival: the order loses time priority and joins the back of its price level with a new sequence number. Otherwise a trader could join early with one lot and then grow the order while keeping a front-of-queue place. The engine applies a modify as an in-place update or as a cancel plus insert. Either way it is a journaled, sequenced event, so replay reaches the same queue position.

Each side holds price levels in sorted order. Because prices are discrete ticks within a price band, an array indexed by tick offset gives O(1) level access. A sorted tree or skip list is the alternative when the range is wide. Each level is a FIFO doubly linked list of orders plus aggregate quantity. A hash map from order ID to node gives O(1) cancel and modify. Best bid and best ask pointers are cached. Prices are fixed-point integers, never floats. Memory is preallocated from object pools so the hot path never allocates or triggers garbage collection. Each order node holds the remaining quantity, member, client code, flags such as STP group, and its sequence number.

State your assumptions clearly and work from peaks, not averages. Assume N instruments, a peak order-message rate R per second, and a burst factor at market open or during news. Size the gateways for that burst plus headroom, then split R across partitions by hot-symbol skew. A single matching thread handles a known rate based on its per-event cost, so the hottest symbol decides whether one thread per symbol is enough. Journal bandwidth is R times message size times the replication factor. Market data is usually several times the order rate, because each order produces book updates. Daily storage is the journal plus trades, kept for the regulatory retention period. I would validate all of it by replaying recorded peak days.

Use a token bucket per member session, and optionally per user ID, with limits set by membership tier or the exchange's policy. It is enforced at the gateway before sequencing, so excess traffic never reaches risk or matching. Over-limit messages are rejected or throttled with a clear reason code. They are not queued indefinitely, because hidden queues create unfair latency. Limits should apply equally to members on the same tier, and cancels may get separate or more generous limits so firms can always reduce risk. Gateways are sharded per member so one noisy member cannot slow another's session. All throttling events are logged for surveillance.

Static price bands per instrument are checked at pre-trade risk, so orders outside the band are rejected before sequencing. Dynamic bands can also be checked by the engine against the last traded price, because only it knows the current price. Market-wide circuit breakers are triggered by index moves at defined thresholds and halt trading across the market. A halt is a sequenced control event in the journal. Every partition processes it at a deterministic point, stops matching, rejects or queues new orders by rule, and often resumes through a call auction. Treating halts as journaled events keeps replay exact and makes it auditable which orders came before and after the halt.

Offer cancel-on-disconnect as a session option. If the session drops, or heartbeats stop for a configured interval, the gateway generates cancel requests for all of that session's open orders, and possibly only for day orders. Those cancels go through the sequencer like any other event, so they are ordered and replayable. They are not applied by silently editing the book. The member gets cancel execution reports when they reconnect and resync. Without this feature, a broker that loses connectivity during a fast market keeps stale quotes it cannot manage. A per-member kill switch covers the case where the session is up but the member's systems have gone wrong.

Treat execution reports as an ordered stream per order, keyed by the exchange's execution ID and per-order sequence. Apply each one idempotently and ignore duplicates by execution ID. Margin is a state machine on the order. Margin is blocked for the full order at entry. Each fill converts part of the block into a position obligation. A cancel or reject releases only the unfilled part. If a report arrives with a gap, the OMS asks the exchange for the missing ones rather than guessing. Ledger updates and order-state changes commit in one transaction. End-of-day reconciliation against exchange trade files and clearing obligations catches anything left over.

Each feed channel carries a monotonically increasing sequence number. The subscriber spots a gap when a sequence number is skipped. Exchanges usually publish A and B feeds over separate paths, so arbitrating between the two fills most single-packet losses. For small gaps, it asks the retransmit service, usually over TCP, for the missing range. For large gaps or a late start, it fetches a snapshot tagged with a sequence number. It then drops buffered incremental messages up to that number and applies the rest. Neither service ever talks to the matching engine. They read from a separately published copy of the event stream, so recovery traffic cannot slow matching.

Replicate synchronously to a quorum of nodes in the same data centre or nearby racks. Use kernel-bypass or RDMA networking and preallocated, append-only memory-mapped or NVMe-backed logs. Durability then comes from the quorum holding the entry, not from a local fsync on every message. Small, adaptive batches amortise round trips under load while keeping single-message latency low when the system is idle. Replication to a far DR site runs asynchronously, so the speed of light does not set matching latency. The trade-off is a small RPO at the remote site. Monitor replication lag continuously, and stop accepting orders if the quorum is lost rather than running with less durability.

The primary site runs synchronous quorum replication locally. The journal streams asynchronously to the DR site, where warm engines continuously replay it. On a site failure, operations declares DR, often under regulatory procedure rather than automatically. The DR site fences the old primary by bumping the epoch and replays to the last received sequence. The exchange then reconciles with members: brokers compare their last execution reports with what DR holds, and orders past that point are treated as not received. Members reconnect to DR gateways and resync with sequence-based recovery. The regulator sets recovery-time expectations, so regular live DR drills, including trading sessions run from DR, are essential.

Fairness has two parts: equal treatment once an order arrives, and equal access paths. Inside the system, a single sequencer per partition and strict FIFO make treatment equal. For access, colocation racks get equal-length cabling and identical network gear, so no member gets a shorter path to the gateway. Gateway load is balanced, and members cannot pay to pick a faster gateway without disclosure. Market data is sent to all colocated subscribers at the same time over multicast, with no unicast fast path. Indian regulators have looked closely at fair access to colocation and tick-by-tick data in the past, so the design must be auditable and logged end to end.

Novation means the clearing corporation becomes the buyer to every seller and the seller to every buyer. Members then face the CCP, not each other, which removes bilateral counterparty risk. Netting collapses each member's many trades into a single net funds and net securities obligation per settlement. That cuts the volume of transfers dramatically. For the design, the trade feed to clearing must be complete, exactly-once and reconcilable. Each trade needs a unique ID and both legs' member and client codes. The CCP's own risk system, with margins and default funds, depends on it, so a lost or duplicated trade becomes a direct financial error.

A kill switch lets a member or the exchange immediately cancel all open orders for a scope and block new ones. The scope can be a member, a dealer, a client or an instrument. The trigger is an authenticated admin message, or an automatic breach such as a loss limit or an abnormal order rate. The gateway starts rejecting new orders for that scope at once. It also sends a sequenced mass-cancel event that each matching partition processes in order, so the result is deterministic and replayable. Confirmations come back as cancel reports. Re-enabling needs a deliberate action. Because a fast-failing algorithm can do great damage within seconds, the kill switch path must be tested regularly.

Self-trade prevention stops a buy and a sell from the same beneficial owner, or the same STP group, from trading with each other. Such trades are wash trades: they create fake volume and can be manipulative. When an incoming order would match a resting order with the same STP key, the engine applies a configured policy. It can cancel the incoming order, cancel the resting order, cancel both, or decrement both by the overlapping quantity. The check runs inside the matching loop, so it is deterministic and replayable, and it never lets the order skip ahead of other resting orders. The cancellation is reported in the execution report with a specific reason.

A pure market order can sweep through many levels in an illiquid book and fill at absurd prices. Common protections are market protection limits, which convert the order to a limit at a set distance from the reference price. Price bands still cap execution, and some venues reject market orders in certain segments. The engine matches level by level until the order is filled or hits its protection limit. The leftover is cancelled, as with IOC, rather than resting at an unbounded price. Broker RMS must block margin against a worst-case price, for example the band limit, because the final fill price is unknown when the order is sent.

Untriggered stop orders sit in a separate trigger book inside the same matching engine, sorted by trigger price and then by sequence. They are not visible in the market-data book. When a trade moves the last traded price through trigger levels, the engine collects the triggered orders and releases them into the main book. It does this in a deterministic order, typically by trigger price and then by original sequence. Triggering happens synchronously inside the matching loop, not on a timer, so replay reproduces it exactly. Cascades, where triggered orders move price and trigger more stops, are processed iteratively in that same deterministic order. Price bands limit how far a cascade can go.

Feed the same journal to two builds, or to the primary and standby, and compare output streams and book-state hashes at checkpoints. Any difference is a bug. Inside the engine, ban nondeterministic inputs. Wall-clock time, randomness, hash-map iteration order, thread scheduling and floating point must not affect results unless the value came in through the journal. Replay production journals nightly against new builds. Use property-based tests for invariants such as no crossed book, quantity conservation, and FIFO order within a level. Periodic in-production hash comparison between primary and standby catches drift early, before a failover depends on it.

Priority comes from the sequencer's sequence number, not from wall-clock time. Clocks on different machines can never be synchronised perfectly, so using them for ordering would be unfair and hard to reproduce. Timestamps still matter for latency monitoring, audit trails and regulatory reporting. Gateways and engines sync clocks with PTP to the exchange's time source and stamp receive, sequence and match times. Those timestamps are recorded in the journal and reports, so investigators can rebuild what happened. If clock drift is detected, it raises an alert but never reorders events.

Each member session is authenticated with credentials or certificates on dedicated leased lines or colocation links, and TLS is used where the protocol supports it. The gateway binds every message to the authenticated member and trader ID and ignores any member field in the message itself. Cancels and modifies are authorised by checking that the target order belongs to the same member. Some venues also check the same user or dealer group. Admin actions such as kill switches and halts go through separate, strongly authenticated operator channels with dual control. Every action is journaled with the identity behind it, which gives an unchangeable audit trail.

Client identity such as PAN, KYC details and bank accounts stays with the broker and the depository and clearing systems. The matching engine needs only an opaque client code and member ID. Public market data is anonymous: it shows price, quantity and side, never member or client. Order-level data with client codes is restricted to surveillance, clearing and regulatory reporting, with role-based access and audit logs. Data is encrypted in transit and at rest, and retention follows regulatory requirements. India's DPDP Act also applies to personal data the broker holds, so brokers must limit its use to the stated purposes and protect access to the client app.

The clearing corporation publishes obligation and settlement files or APIs per member: net funds payable or receivable, and securities to deliver or receive. The depository moves securities between demat accounts, and clearing banks move funds. The broker loads these into its back office and checks three sources against each other: its own trade book from execution reports, the exchange's trade file, and the CCP's obligations. Any break is investigated before client ledgers are finalised. The broker then credits client holdings and funds. In India, rules on client fund segregation and how quickly funds are returned shape how fast the broker must update and release client balances.

During the call auction, orders are collected but not matched, and an indicative equilibrium price may be published. At the end of the collection window, which may close at a randomised point to deter gaming, the engine computes the single price that maximises traded volume. Tie-breakers include minimum imbalance and closeness to a reference price. All eligible orders trade at that one price, allocated by price-time priority. Leftover orders move into the continuous book. The auction end is a sequenced control event, and any randomness comes from a journaled value, so replay gives the same result. Auctions are commonly used for price discovery at the open and when trading resumes after a halt.

Strict, instant limits across partitions would need cross-partition coordination on every order, which is far too slow. A common approach is to give each partition an allocation of the member's limit and rebalance it asynchronously. Another is to check against a shared risk state that is updated from fills, with slightly conservative buffers. The broker's RMS remains the main line of margin protection. Exchange limits are a safety net, so slight staleness that only ever errs on the safe side is acceptable. Market-wide open-interest limits, such as MWPL, can be enforced by a separate risk service that sends sequenced restriction events when thresholds are crossed.

The matching engine must never wait on them. It writes outputs to an append-only output journal or ring buffer. Each consumer has its own cursor and reads at its own pace, and slow consumers are allowed to fall behind and catch up from the log. If a broker's session is slow, its gateway queue grows. Past a threshold, that session is disconnected and resynced from the log, so the backlog does not spread. Lag per consumer is monitored, and alerts fire well before log retention could be exceeded. Input backpressure happens only at the gateway, through rate limits and rejects, never by stalling the engine.

First, replay months of production journals through the new build and diff outputs and book hashes against the old build, bit for bit. Next, run it in shadow mode in production, reading the live journal while its outputs are discarded and compared. Any rule change, such as new order types or a new STP policy, is put behind a config flag. Flags are switched only at session boundaries and are recorded in the journal so replay knows which rules applied. Deploy only between sessions, never intraday. Keep the previous build ready to restore by replay. Notify members of behaviour changes and run mock trading sessions so they can test against the new version.

An iceberg shows only a disclosed quantity while the rest stays hidden. The visible part sits at its price level with normal time priority. When it is fully filled, the engine refreshes the next disclosed tranche from the hidden reserve. That refresh gets a new time priority at the back of the level, as if it were a fresh arrival. This stops icebergs from always beating displayed orders that arrived later but were fully visible. The refresh happens inside the matching loop, so it is deterministic. Market data shows only the disclosed quantity, so the reserve is never revealed.

1. AThe one from the member with the higher rate limit
2. BThey are filled pro-rata by quantity
3. CThe one with the larger quantity
4. DThe one that was sequenced earlierCorrect answer

Why: Under price-time priority, orders at the same price level are filled first-in, first-out by arrival (sequence) order. Pro-rata allocation is a different matching algorithm.

1. AIt is moved to the front of the level
2. BThe order is rejected and must be resent
3. CIt keeps its place in the queueCorrect answer
4. DIt moves to the back of the price level

Why: Reducing quantity does not disadvantage anyone behind the order, so priority is normally kept. Increasing quantity or changing price resets it.

1. AThe sequencer's sequence numberCorrect answer
2. BThe trader's device clock
3. CThe broker OMS timestamp
4. DThe gateway receive timestamp

Why: The sequencer assigns one sequence number per partition and journals it. That number, not any clock, defines processing order and priority.

1. AAccept it as a new order
2. BReject both orders
3. CCancel the original and accept the resend
4. DRecognise the duplicate and return the existing order's stateCorrect answer

Why: Dedupe by member and client order ID makes entry idempotent, so retries never create duplicate orders.

1. AThe clearing corporation after the trade
2. BThe depository
3. CThe broker RMS, before the order leaves the brokerCorrect answer
4. DThe exchange matching engine

Why: The broker RMS blocks margin or holdings in the margin ledger before sending, so no order goes out without cover.

1. AMulticast encrypts data automatically
2. BUDP guarantees delivery and ordering
3. CMulticast sends one copy to all subscribers, and a slow client cannot apply backpressure to the engineCorrect answer
4. DTCP cannot carry binary messages

Why: Multicast fans out one stream to everyone with low and equal latency. Sequence numbers let clients detect gaps and recover through snapshot or retransmit channels, without slowing the matching engine.

1. ADeterministic matching logic replaying a durable, sequenced input journalCorrect answer
2. BHaving the standby subscribe to the public market-data feed
3. CUsing wall-clock timestamps to reorder events on replay
4. DPeriodically copying the primary's database tables

Why: If matching is deterministic and every input is journaled in sequence order, replaying the journal reproduces identical state. Public market data is lossy and lacks private order details.

1. AIn the matching engine after it rests
2. BAt exchange pre-trade risk, before sequencingCorrect answer
3. CAt the clearing corporation
4. DBy the market data feed handler

Why: Pre-trade risk rejects band violations straight back to the gateway, so the order never touches the book.

1. AIt reduces memory use by sharing books between threads
2. BIt allows the book to be stored in a relational database
3. CIt removes the need for a journal
4. DIt gives deterministic, lock-free processing in strict sequence orderCorrect answer

Why: One owner thread processes events strictly in order with no lock contention. That makes the output deterministic and replayable.

1. A100Correct answer
2. BIt does not trade
3. C101
4. D100.5

Why: Trades execute at the resting order's price. The incoming aggressive order gets the price improvement.

1. ABy checksum errors only
2. BBy TCP retransmission timers
3. CBy a gap in the feed's sequence numbersCorrect answer
4. DBy comparing wall-clock timestamps

Why: Each multicast channel carries increasing sequence numbers. A skipped number signals lost messages.

1. ATo hide order quantities
2. BTo enforce tick size
3. CTo speed up matching
4. DTo stop orders from the same beneficial owner trading with each otherCorrect answer

Why: Self-trades are wash trades that create fake volume. STP cancels or decrements the conflicting orders instead.

1. ABrokers settle bilaterally with each other
2. BTrades are converted into derivatives
3. CThe clearing corporation becomes the counterparty to both buyer and sellerCorrect answer
4. DTrades are cancelled and re-entered the next day

Why: Through novation the CCP stands between the parties, which removes bilateral counterparty risk.

1. APrice band breaches
2. BStale open orders left behind when a member's session dropsCorrect answer
3. CDuplicate client order IDs
4. DMulticast packet loss

Why: It automatically cancels a session's resting orders when the connection or heartbeats fail, so the member is not exposed to orders it cannot manage.

1. AA quorum of replicas has acknowledged itCorrect answer
2. BThe far DR site has written it
3. CThe event is in the sequencer's memory
4. DThe broker has acknowledged it

Why: Synchronous quorum replication nearby gives durability without the latency of waiting on a distant site.

1. AA relational table indexed by timestamp
2. BA min-heap of all orders by quantity
3. CA single unsorted list of all orders
4. DSorted price levels, each a FIFO queue, plus an order-ID hash mapCorrect answer

Why: Sorted levels give fast best-price access, FIFO queues enforce time priority, and the hash map gives O(1) cancel and modify.

1. AClient PAN
2. BOrder type
3. CInstrument or symbolCorrect answer
4. DBroker member ID

Why: Price-time priority is defined per instrument, so partitioning by symbol keeps each book's ordering inside one owner.

1. ARelease all of it
2. BKeep all of it until settlement
3. CRelease the margin for the 60 unfilled shares onlyCorrect answer
4. DBlock more margin

Why: Margin for the 40 filled shares becomes a position obligation. Only the unfilled part is released.

1. AProcessing events in sequence order
2. BWriting outputs to a log
3. CReading wall-clock time or random values that are not in the journalCorrect answer
4. DUsing fixed-point prices

Why: Any input that is not journaled, such as local time or randomness, would make replay diverge from the original run.

1. ADeletes the member's trade history
2. BCancels the member's open orders in scope and blocks new onesCorrect answer
3. CPauses market data for everyone
4. DRestarts the matching engine

Why: A kill switch removes risk quickly through sequenced mass cancels and blocks further entry until it is re-enabled.

1. AHave brokers report trades instead
2. BSend it over UDP once
3. CUse unique trade IDs with dedupe and reconciliation against the journalCorrect answer
4. DSend it only at end of day by email

Why: At-least-once delivery plus idempotent trade IDs and reconciliation gives an effectively exactly-once trade feed.

1. AFaster clocks
2. BFencing with an epoch or term number that rejects the old primary's writesCorrect answer
3. CRestarting all brokers
4. DBigger rate limits

Why: Epoch fencing rejects journal and output writes from a stale leader, which avoids split brain.

1. AAsking the matching engine for its in-memory book
2. BWaiting until the next trading day
3. CLoading a sequence-tagged snapshot, then applying buffered incremental updates after that sequenceCorrect answer
4. DApplying incremental updates from the current point only

Why: A snapshot tagged with a sequence number, followed by later incremental updates, rebuilds a consistent book without touching the engine.

1. AThe same Monday
2. BWednesday
3. CTuesday, the next business dayCorrect answer
4. DThe following Monday

Why: T+1 means settlement one business day after the trade date.

1. ATo stop one member from flooding the system and hurting othersCorrect answer
2. BTo set price-time priority
3. CTo net trades
4. DTo encrypt traffic

Why: Rate limits protect shared capacity and fairness by rejecting excess traffic before it reaches risk or matching.

1. AIt goes to the back of the price levelCorrect answer
2. BIt moves to the front of the level
3. CIt moves to a better price
4. DIt keeps the original priority

Why: A refreshed tranche is treated as a new arrival, so displayed orders are not always beaten by hidden quantity.

1. AA multicast gap
2. BA slow clearing feed
3. CIndex moves crossing defined percentage thresholdsCorrect answer
4. DA single broker's disconnect

Why: Market-wide circuit breakers are tied to index moves and halt trading across the market at set thresholds.

1. AAsk the trader
2. BDeduplicate on the exchange execution ID and apply it only onceCorrect answer
3. CApply both and fix it at end of day
4. DReject the order

Why: Applying reports idempotently by execution ID keeps order state and margin correct even when reports are redelivered.

1. ATo change price-time priority
2. BTo shorten recovery by replaying only events after the snapshotCorrect answer
3. CTo replace the journal
4. DTo publish to market data subscribers

Why: Snapshots bound replay time. The journal stays authoritative for events after each snapshot.

1. AThe first order's price
2. BThe average of all bids
3. CThe previous day's close, always
4. DThe price that maximises traded volume, with defined tie-breakersCorrect answer

Why: Auctions pick the equilibrium price that matches the most quantity, and use tie-breakers such as minimum imbalance.

1. AThe broker's margin balance
2. BThe trader's IP address
3. CThe client's PAN
4. DPrice, quantity and side, without member or client identityCorrect answer

Why: Public feeds are anonymous. Identities are kept for surveillance, clearing and regulators.

1. ATo save network bandwidth only
2. BBecause FIX requires integers
3. CTo hide prices from subscribers
4. DTo avoid floating-point rounding errors and keep comparisons exact and deterministicCorrect answer

Why: Floating-point rounding can break exact price comparisons and replay determinism. Integer ticks avoid both problems.

1. ALoss of price-time priority
2. BA small possible data loss window (RPO) at the DR siteCorrect answer
3. CUnbounded broker rate limits
4. DSlower local matching

Why: Async replication keeps long-distance latency off the critical path, but the DR site may lag slightly behind the primary.