Reamer Server
A live execution server for mid-frequency trading. It holds order state and sequencing, runs the pre-trade decision path between your strategy and your venue, and publishes every intent, fill, and reject on a shared-memory event bus. You link it against a stable C ABI, wire in your gate and your broker connector, and that call is your server process.
Integration demo
A coding agent reads the shipped kit documents with no prior exposure and no source access, and builds its own gate and broker connector against the ABI, driving order flow to a fill against a simulated venue. A wall clock runs throughout, and the elapsed time is the measurement. Your own venue dialect, sequence persistence, and certification follow.
The clean-latency region tracks your core count.
A full 1→512 concurrent-strategy sweep. Throughput here means orders per second — the number of order intents the core accepts or rejects each second. Latency here is measured per order, end to end: from the moment a strategy submits an order intent to the moment the core returns its acknowledgement. Throughput plateaus across the core band, and every order matched its accept-or-reject event exactly once at every point.
Selected points from a 130-point sweep, 1→128 in steps of 1 plus 256 and 512. Throughput (orders per second) plateaus through about one strategy per physical core, then falls steadily under oversubscription while the latency tail widens. Every order matched its accept-or-reject event exactly once at every point through 512. Latency is per order, core to a local acceptor on the same machine, with no network or venue time included. One rented single-socket box, stub broker. Verify absolute numbers on your own hardware.
Measured cost, layer by layer
Don't conflate the layers. The boundary is ~1% of per-order core cost. Your gate and broker logic dominate, not the ABI. All figures below are the AMD EPYC 9575F run.
Single rented single-socket box. Verify absolute numbers on your own hardware.
Every order leaves a trail you can read
The core writes the flow as it runs. A live event stream, scrape targets your orchestrator already speaks, and a one-command bundle for a support request. Nothing to bolt on.
The core broadcasts each pipeline event on a shared-memory ring. Any number of reader processes attach independently and replay from a sequence number. Accepted, rejected, filled, cancelled, each with its reason.
A Prometheus /metrics surface and a liveness/readiness /health route your orchestrator scrapes directly. Order counts, rejection reasons, table saturation, broker and relay connectivity.
reamer-diag-bundle scrapes health, metrics, and the retained event history into a single JSON file, stamped with the build. The auth token is never written to it. Attach it to a support email as is.
Every line the core writes is one JSON object, ready for journald, ELK, or Datadog. Set REAMER_TIMING_DEBUG=1 and the main loop reports poll latency, batch size, and outlier dispatch, inert until you ask.
Two vtables and a socket, in your language
The core links into your process. You implement a gate and a broker connector as C structs of function pointers, connect your strategy over a socket, and call reamer_server_run(). Reference skeletons run before you write anything real.
One pre-trade decision per intent. Pass or reject, given the intent and the venue's last known state.
Your venue session. Reports fills back and is the sole source of venue state: positions, open orders, connection status.
A local Unix domain socket, or a remote relay for a strategy in another process or host. Both wire protocols shipped in full.
A plain C callback API. A C++ implementation closes over its object through a trampoline; Go connects through cgo. Both documented.
An accept-all gate and in-memory paper broker, in C++ and Rust. The smallest thing that runs, to confirm your wiring first.
A FIX 4.4 session, broker connector, and strategy relay driven to a fill in one command. Reference material, not a supported surface.
What's in scope
The gate, broker connector, and OEMS are customer-built, not pre-wired extension points. Platform: linux_x86_64, glibc 2.39, ABI 3.
Per seat, per year. Evaluation kit available on request.
Request evaluation kit