Engineering publication hub
This ordered series documents the Derivasys engineering journey from a first real-time BTC options surface through normalized order books, selective implied-volatility recalculation, domain-aware production monitoring, Kafka/Kubernetes worker boundaries, and the threaded Rust market-data engine now powering BTC and ETH. The maintained Derivasys editions are the preferred long-term references; links to external publications remain visible where relevant.
Reading paths
Begin with the first working surface before moving into specialized pipeline layers.
EngineersFollow order-book identity, sequencing, replay, IV throughput, monitoring, and worker boundaries.
QuantsTrace book state through IV inversion, SVI acceptance, residual diagnostics, and published risk nodes.
NewestUse the recent list for updates; series numbers always mean conceptual order.
Conceptual order
Order here reflects prerequisites and learning outcome, not publication date.
01 / Engineering article
The first Derivasys build looked like a quant modelling problem. In practice, the hard parts were market-data pressure, implied-volatility recomputation, batching, and keeping the dashboard fresh without starving the event loop.
02 / Engineering article
A volatility surface is only as trustworthy as the market data beneath it. This article covers the order-book layer Derivasys needs before implied volatility, SVI fitting, risk nodes, and dashboard snapshots can be trusted.
03 / Engineering article
The second article focuses on the live volatility layer: why BTC options can force tens of thousands of implied-volatility recalculations in bursts, and why blocked event loops show up as market-data reliability problems.
04 / Engineering article
A live volatility surface needs monitoring that understands market data, not only servers. This article covers the Derivasys checks that make stale books, delayed workers, unstable SVI fits, and bad risk nodes visible before users trust the dashboard.
05 / Engineering article
The third article moves the volatility platform from a coupled object graph into a distributed event pipeline: exchange connectors, order-book workers, volatility workers, surface workers, API consumers, and replayable contracts.
06 / Engineering article
Two Python cores were pinned at 100%, Kafka and Kubernetes had cost roughly $1,000 in a week, and asyncio could not create more CPU. Article IV covers the Rust engine, warm-started Newton solver, Unix-socket protocol, LLM-assisted parity testing, and the route from BTC into ETH and SOL.
Newest publications
Two Python cores were pinned at 100%, Kafka and Kubernetes had cost roughly $1,000 in a week, and asyncio could not create more CPU. Article IV covers the Rust engine, warm-started Newton solver, Unix-socket protocol, LLM-assisted parity testing, and the route from BTC into ETH and SOL.
A volatility surface is only as trustworthy as the market data beneath it. This article covers the order-book layer Derivasys needs before implied volatility, SVI fitting, risk nodes, and dashboard snapshots can be trusted.
A live volatility surface needs monitoring that understands market data, not only servers. This article covers the Derivasys checks that make stale books, delayed workers, unstable SVI fits, and bad risk nodes visible before users trust the dashboard.
The third article moves the volatility platform from a coupled object graph into a distributed event pipeline: exchange connectors, order-book workers, volatility workers, surface workers, API consumers, and replayable contracts.
The second article focuses on the live volatility layer: why BTC options can force tens of thousands of implied-volatility recalculations in bursts, and why blocked event loops show up as market-data reliability problems.
The first Derivasys build looked like a quant modelling problem. In practice, the hard parts were market-data pressure, implied-volatility recomputation, batching, and keeping the dashboard fresh without starving the event loop.
