Full replication & clustering, not an afterthought
MatchCore is built around a replicated, deterministic state machine from the first line of the design — not retrofitted with a database underneath. Run it as log-based replication or as a Raft consensus cluster: same deterministic core, same 1,000,000 tx/sec cluster throughput, either way.
Deterministic replication, two ways to commit it
Every command that changes state — a new order, a cancel, a resolution event — is written to a replicated log before it is acknowledged to the client. Every replica applies the exact same commands in the exact same order, so given the same log, every node arrives at the same book state.
Where MatchCore's two replication principles differ is how a commit reaches durability — a single writer streaming to standbys, or a quorum of nodes voting on it. MatchCore is the rare matching engine that gives you both, on the same core.
Log-based replication or a Raft cluster
Two different ways to make a commit durable — pick the one that fits your venue's scale and operating budget.
Single writer, replicated WAL
One active node writes; the replicated write-ahead log streams to one or more standbys, which replay the identical deterministic state machine to stay byte-for-byte current.
- Two or three nodes — no consensus protocol overhead
- Promotion on failover completes in milliseconds
- Lowest infrastructure footprint to run in production
Especially chosen by smaller, cost-conscious exchanges that want real HA without operating a quorum.
Multi-node quorum, automatic election
An odd-numbered quorum of nodes (3, 5, 7…) commits state only once a majority acknowledges, with fully automatic leader election on top of the same deterministic core.
- No external coordinator or manual promotion step
- Survives loss of any minority of nodes unattended
- Built for continuous availability at regulated scale
The default for larger exchanges and MTFs that need zero single points of failure with no manual step.
Both run the same matching logic, gateway protocols and audit log format — switching from log-based replication to a Raft cluster (or running either per-venue) is an operations decision, not a re-integration.
What clustering buys you
Zero-downtime failover
Leader promotion in milliseconds, not a cold restart or replay from cold storage.
Geo-distributed DR
Cross-region replication keeps a warm standby cluster ready in a second jurisdiction.
Horizontal sharding
Instruments shard across cluster segments, scaling throughput close to linearly with node count.
Immutable audit log
Every command is sequenced and retained, giving compliance teams exact point-in-time reconstruction.
How throughput scales with cluster size
Replication & clustering, answered
How does MatchCore achieve full replication?
Every state-changing command — new order, cancel, resolution event — is appended to a replicated write-ahead log before it is acknowledged. Standby nodes apply the identical deterministic state machine to that log, so their in-memory book state stays byte-identical to the leader's.
What happens during failover?
A standby replica is promoted to leader and resumes processing from the last committed log entry. Because state is deterministic and fully replicated, there is no rebuild or resynchronisation window — failover is a promotion, not a recovery.
Can MatchCore run across multiple regions?
Yes. Clusters can be deployed per region with cross-region replication for disaster recovery, or a single logical venue can shard instruments across regional clusters to keep matching close to its primary user base.
Is the audit trail regulator-ready?
The write-ahead log is immutable, fully sequenced, and deterministically replayable, so a regulator or internal surveillance team can reconstruct the exact state of the book at any point in time from the log alone.
Should I choose log-based replication or a Raft cluster?
It depends on scale and budget, not capability — both give you the same deterministic core. Log-based replication (single writer, replicated WAL, promoted standby) is what most smaller and cost-conscious exchanges start with: fewer moving parts, lower infrastructure cost, and HA without running a quorum. A Raft consensus cluster adds automatic leader election and majority-vote commits across an odd-numbered node quorum, which larger or regulated venues often want for continuous availability with no manual failover step. MatchCore supports both under the same integration, and venues commonly start on log-based replication and move to a Raft cluster later without re-architecting.