Resilient by design, not by diagram
MatchCore's default architecture is built so nothing is ever lost: every order is safely recorded before it's confirmed, and recovery is instant and fully verified. This is the trade-off most production matching engines actually make — full clustering costs real latency on every order, for a guarantee our recovery model already provides. Clustered replication is available as an option, not forced on every deployment by default.
Instant, verified recovery — not a leader election
Every action that changes the book — a new order, a cancel, a resolution — is safely recorded before it's applied or confirmed to the client. On restart, the engine picks up exactly where it left off, replaying that record with no ambiguity and no guesswork, so the rebuilt state is identical every time.
This is the project's own correctness bar: an automated test simulates real crashes at multiple points and confirms the recovered state matches an uninterrupted run exactly, not approximately. That's what "resilient by design" means here — it's the first thing that had to pass, before anything else was built on top of it.
Honest properties, not marketing ones
One consistent order book, always
A single source of truth for every market, so there's never a conflicting or ambiguous state to reconcile.
Recovery, proven not assumed
Restart-and-recover is tested against real, simulated crash scenarios — not just asserted in a diagram.
Clustering, when you want it
Real, available multi-node replication for venues that want it and accept its latency cost — not the default, and not vaporware either.
Immutable audit trail
Every action is sequenced and retained, giving compliance teams exact point-in-time reconstruction.
What resilience actually costs you in practice: nothing
Replication & clustering, answered
Why doesn't MatchCore cluster by default?
Because that's the trade-off most production matching engines actually make. Synchronous replication across multiple nodes adds a round-trip's worth of latency to every single order, to guarantee something our recovery model already provides on its own: an exact return to the last confirmed state. We built and tested full clustering — it's available, just not forced on every deployment by default.
What happens if the matching engine goes down?
It restarts and picks up exactly where it left off — every order it confirmed was safely recorded before that confirmation was ever sent, so nothing confirmed is ever lost. This is proven with an automated test that simulates real crashes and confirms the recovered state is identical, not just described in a diagram.
Is clustered, multi-node replication available at all?
Yes — a real, available option for venues that specifically want synchronous replication and are willing to accept its added latency. It isn't the default because most production exchanges don't want that trade-off on every order; ask us about it if your venue does.
Is the audit trail regulator-ready?
Yes — the trade record is immutable and fully sequenced, so a regulator or internal surveillance team can reconstruct the exact state of the book at any point in time.