Optiver's Reconciliation System Design Question
Optiver's design rounds for systems engineers start with a clean solution, then deliberately break your assumptions to see whether your design bends or shatters. This reconciliation question is a recurring on-site. Here is the full question, the staged design, and the rubric.
The question
Design a system that reconciles two independent views of the same trades, for example the firm's internal record against the exchange's drop-copy feed, and reports discrepancies. It must detect missing records, extra records, and field-level mismatches, handle records arriving asynchronously and out of order, and produce a reconciled stream plus a discrepancy report.
The initial design
Start simple and state it cleanly. Match records by a stable primary key, hold unmatched records per source, and expire them after a window so a late arrival from the other side can still pair up.
Match key: trade ID (stable, present on both feeds)
Per-source store: unmatchedInternal{tradeId -> record}, unmatchedExchange{tradeId -> record}
On record from a source:
if the OTHER source has a pending record with this key:
compare fields -> emit MATCH or FIELD_MISMATCH(diff); remove from both
else:
store in this source's pending map with an expiry timestamp
Sweeper (periodic):
expire pending records older than the window -> emit MISSING_ON_OTHER_SIDEThat handles the happy path: out-of-order and asynchronous arrivals are absorbed by the pending maps and the expiry window. Then the interviewer breaks the assumptions.
Follow-up · Break the assumptions
Three constraints arrive after your first solution. The test is whether you evolve the design rather than rewriting it.
- No stable key on one side. Match on a composite of fields with tolerances: timestamp within plus or minus N seconds, price within a tick, same instrument and quantity.
- Amendments. A record can be corrected after publication, so an already-matched pair must be re-opened and re-evaluated.
- Replays. One source can replay history, so duplicates across replays must be deduplicated.
Evolve each piece in place. The pending stores and the emit-on-match skeleton stay; only the matching and versioning layers change.
Fuzzy matching (no stable key):
bucket pending records by a coarse blocking key (instrument, rounded time)
within a bucket, score candidate pairs on |dt|<=N, |dprice|<=1 tick, qty ==
take the best-scoring candidate above a threshold; leave the rest pending
Amendments:
give every record a (recordId, version); store the latest version
on a higher version for an already-matched record:
re-open the pair, re-run the comparison, emit an updated result
Replays / dedup:
track seen (recordId, version, sourceHash); ignore exact repeats
a replay that carries a new version is treated as an amendment, not a duplicateNotice what did not change: the per-source pending stores, the expiry sweeper, and the discrepancy emit path. Only matching (exact to fuzzy) and identity (key to versioned id) were swapped. That is the Optiver signal, evolving a design under pressure instead of restarting.
How Optiver scores it
| Dimension | Weak | Strong |
|---|---|---|
| Initial model | Vague or stateful mush | Key match, per-source pending, expiry window |
| Out-of-order | Assumes synchronized feeds | Pending maps absorb async, late, gapped arrivals |
| Fuzzy matching | Gives up without a stable key | Blocking plus tolerance-scored best match |
| Amendments | Treats a correction as a new trade | Versioned records, re-open and re-evaluate matches |
| Replays | Double-counts replayed history | Dedup on id, version, and content |
| Evolves cleanly | Rewrites for each new constraint | Swaps matching and identity, keeps the skeleton |
This is one question of 34 pages
Get the full Optiver question bank
The full Optiver bank carries the low-latency systems and design rounds, each problem with its staged follow-ups and a rubric, compiled from people familiar with the process and cross-verified across sources.
Optiver interview FAQ
What does the Optiver system design interview ask?+
Low-latency, correctness-critical trading systems: market-data fan-out, position tracking, and reconciliation. The interviewer typically gives an initial design, then breaks the assumptions and asks you to evolve it without starting over.
Is the Optiver interview only quant brainteasers?+
For systems and backend roles, no. This bank focuses on C++ and low-latency design, performance debugging, and concurrency, alongside the probability questions Optiver is also known for.
How is the Optiver design round scored?+
On a correct initial matching model, then how cleanly you evolve it under new constraints (fuzzy matching, amendments, replays) without a rewrite, plus handling of out-of-order and asynchronous arrivals and a clear discrepancy report.
Where can I find real Optiver interview questions?+
Pichup maintains a 34-page Optiver question bank compiled from people familiar with the process, with the low-latency systems and design rounds, their follow-ups, and rubrics. The question in this guide is one of them.