OMS / Matching Engine Best Practices

Building an OMS or matching engine on Aeron Cluster is less about the framework and more about the operational patterns around it: how you deploy, upgrade, snapshot, and recover without ever telling the market “we’re closed.” This section collects those patterns.

Work in progress

This section is being built out. Pages appear as they’re written; the planned list below is the roadmap.

In this section

New here? Start with the two shard axes — it is the whole-system map the other pages zoom into.

• Rolling Upgrade of Cluster Member Nodes — How to upgrade Aeron Cluster members one node at a time — follower-first ordering, leader handoff, version compatibility, and verification at each step.
• How the OMS and ME Fit Together: Two Shard Axes — The whole-system map: a user-sharded OMS account layer in front of a symbol-sharded matching engine, how an order flows through both, and why a fill crosses the two axes.
• Sharding an OMS by the Actor Pattern — Scaling a matching engine past a single deterministic state machine by partitioning the instrument universe into single-threaded actors — shard keys, routing, cross-shard coordination, and how it maps onto Aeron Cluster.
• Sharding the OMS by User: Hot-User Actors with Eviction — Sharding the per-user account/risk/session layer of an OMS across Aeron Clusters as evictable actors — hydrate a user on first order, dehydrate when they go cold, and keep it all deterministic and single-writer.
• Choosing an Order-Book Data Structure — How to pick the structure at the heart of a matching engine — price-indexed arrays, balanced trees, skip lists, linked levels, hash+heap, and adaptive radix trees — judged by hot-path latency, cache behavior, liquidity profile, and the cancel-heavy order flow they must survive.

Planned

• Deterministic state machines — keeping the replicated service replayable (no wall clocks, no randomness, no external I/O in the business logic).
• Snapshot discipline — when to snapshot, sizing the recovery window, testing restores.
• Session and duty-cycle design — backpressure handling on ingress/egress.
• Failover drills — leader loss, follower loss, AZ loss, and what the runbook says for each.

Related foundations elsewhere on this site: performance tuning, operations & resilience.