Skip to content
SAPPHIREENGINEERING PORTFOLIOExplore the architecture

System design / interactive atlas

Inside Sapphire.

From a market observation to a protected broker position. Explore native financial ownership, trace the remaining Python handoffs, and inspect the evidence behind the engineering decisions.

Engineering choices & measured timing ↓
Python on the execution path
ARCHITECTURE ATLAS

One system. Explicit ownership.

SAPPHIRE HFT / TRADING RUNTIMEPython-managed processes. Native execution authority.CONTROL & RESEARCHDATA & BROKER SERVICESON THE HFT HOSTcommands / eventsjobs / resultsSPY tradesquotestyped actionsquotes / risk actionsselected actionrequestsbroker evidencepersist / recoverA separate web control plane presents system state and coordinates operator requests and research jobs.CONTROL PLANESapphire ControlOperations & research control planeExplore component ↗The research host executes queued backtests against historical data and produces results for candidate review.RESEARCH HOSTAlgoTrader1Research, replay & candidate evaluationExplore component ↗Python manages the application around persistent native owners. It is an active orchestration layer, including order workers and an options quote adapter.PYTHON / TWO ACTIVE HANDOFFSPython runtime & execution handoffsQuote preparation · action dispatch · order workers · controlThe market child hosts a direct C++ data-to-decision path, with Python responsible for setup and checkpoints.NATIVE MARKET OWNERMarket processTicks → features → ordered decisionsExplore component ↗A primary options process and an optional flip/prewatch process host native chain and position-risk owners. A Python adapter connects feed records to them.PRIMARY + OPTIONAL FLIPOptions processesPython quote adapter → C++ books & riskExplore component ↗Native fan-in, reduction and order submission form the authoritative order and position lifecycle inside the router process.FINANCIAL LIFECYCLERouter native authorityOne event domain · exact positions · durable admissionExplore component ↗Durable journals preserve admitted intent and broker evidence across exceptions or process restarts.PERSISTENCEDurable recovery stateIntent WAL · broker evidence · action-result outboxAn external market-data provider supplies equity trades, option top-of-book records and contract identity information.EXTERNAL DATADatabentoSPY trades · option CMBP-1 · symbologyExplore component ↗IB Gateway is a separate local service, connected to Sapphire through the official native IBKR API.BROKER GATEWAYIB GatewaySeparate service on the HFT hostExplore component ↗The broker provides the financial evidence used to settle order and position state.EXTERNAL BROKERInteractive BrokersOrders · executions · position snapshotsExplore component ↗
100%
Select a component · drag to pan
C++ ownershipPython runtime & handoffsDurable stateServices & hostsTyped communication
READ THE BOUNDARIES

Explore the full architecture, then step through the lifecycle of a trade. Select any component to see its role and the boundary it protects.

1 / 7
Source architecture · component groups simplified for clarityTiming: Nov 6, 2026 observations · diagram is not a live status view
For a closer look · 8K downloadsWhole system PNGSapphireHFT C++ PNGSystem SVGC++ SVG

Engineering decisions / evidence & next steps

Correctness first.
Then the next boundary.

The C++ migration established durable order and position ownership while retaining existing Python orchestration. The remaining handoffs are visible, measured where evidence exists, and separate from financial authority.

01 / NATIVE FOUNDATION

Financial state has a native owner.

Broker fills commit exposure in C++ before Python callbacks or telemetry. Exact execution identities make repeated evidence idempotent.

02 / NATIVE FOUNDATION

Admission survives interruption.

Identity checks and entry fences precede durable intent and broker invocation. An uncertain send retains its authority for reconciliation.

03 / NATIVE FOUNDATION

Recovery preserves the lifecycle.

Fresh broker evidence rejoins retained order lineage. Position revisions bind protective watches to the quantity they actually protect.

Why this order of work

Make state dependable.
Keep the migration inspectable.

Native financial authority, durable admission, idempotence and recovery came first. Retaining the existing orchestration kept configuration, supervision and command delivery connected while those ownership boundaries moved into C++.

For the current stage, a typical 2–3 ms quote-ingestion handoff is an accepted tradeoff. The observed tail remains an optimization target. That choice is specific to this system and its current strategy.

Remaining Python boundary / quotes

Native feed → Python adapter → native option runtime

The official C++ session receives and decodes records. Python still drains the record pump and prepares typed quote inputs before calling the native option owner. Native quote and watch state does not make this entire ingestion path native.

Measured ingestion boundary below

Remaining Python boundary / orders

Selected action → Python dispatch → native admission

Python dispatch and order workers still participate before the native submission owner admits a command. Native admission, broker invocation and financial evidence retain their own authority. This separate handoff has not been benchmarked here.

Observed option-quote ingestion

What the timing actually measures.

Local arrival inside native translation → native ingestion return. Values below summarize rolling windows; they are not whole-session quote percentiles.

09:30–16:00 New York

45,986 telemetry snapshots

Option ingestion measurements. Every value is the median of a rolling 256-quote percentile, in milliseconds.
Timing boundary / window statisticPrimary options23,218 snapshotsFlip options22,768 snapshots
Local arrival → ingestion returnMedian of rolling-window p50 values1.85ms2.57ms
Same interval, tail behaviorMedian of rolling-window p99 values16.1ms20.3ms
Runtime-call envelopeMedian of rolling-window p50 values · includes Python conversion0.058ms0.065ms

Each value is the median across telemetry snapshots of a rolling 256-quote percentile. Windows may overlap. These are typical rolling-window statistics, not whole-session per-quote quantiles. Context-only quotes and watched-position quotes share the samples.

Measurement boundaries and limitations

Local arrival is timestamped inside native record translation, not at the network interface.

The runtime-call interval includes Python request replacement and conversion, native locking and work, backpressure retries, and return. It is not an isolated C++ compute measurement.

  • The 45,986 observations are telemetry snapshots, not a count of distinct quotes. Rolling windows can overlap.
  • Context-only quotes and quotes for watched positions share the timing samples; the measurements do not isolate protective-risk work.
  • Ingestion can return before the strategy evaluates a completed 100 ms observation. Idle advance_execution_clock processing is outside the measured interval.
  • These measurements do not establish network-arrival-to-risk, quote-to-action, order-submission, or broker-fill latency.
  • There is no before-and-after migration benchmark here. The observations do not quantify a speedup from removing Python or the separate order-dispatch handoff.
Download the curated timing evidence

Next / quote path

Drain quote batches in native code.

Move the record-drain and quote-conversion boundary into a native batch path. Preserve source ordering, sequence watermarks, exact protective-watch identity and backpressure behavior. Measure the same ingestion boundary again, with separate instrumentation for risk and action completion.

Later / order path

Evaluate the dispatch handoff separately.

Moving selected actions directly to native admission is a different change. It must preserve exact command identity, the sole submission owner, durable admission and recovery semantics. The quote-ingestion measurements do not quantify this handoff or its potential improvement.