The hard part
The surface fit is not the hard bit. The vols are.
This is a follow-up on the crypto options surface MVP I have been building. One thing became obvious quite quickly: everything downstream depends on implied volatility calculations.
The smile, SVI fit, ATM vols, skew, risk reversals, butterflies, surface patches, and UI updates all start with the vol layer. If that layer falls behind, the rest of the system inherits stale or uneven state.
At first it looks like an I/O problem. In practice, delayed heartbeats and bursty updates can be a symptom of your own volatility calculations blocking the event loop.
Async reality
WebSocket symptoms are not always WebSocket problems.
Live market-data systems have plenty of moving parts: websocket feeds, asyncio, order books, heartbeats, reconnect logic, and bursty exchange updates. When updates arrive in waves, it is natural to blame the sockets first.
Often the issue is simpler. The event loop is being blocked by implied volatility calculations. That matters because BTC options are a very effective stress test for a real-time options analytics pipeline.
BTC stress test
A meaningful BTC move can force the whole surface to move.
On Deribit alone, a BTC options feed can easily contain more than a thousand live instruments across expiries and strikes. Each instrument can receive continuous bid and ask updates.
Once BTC moves meaningfully, everything follows. Spot shifts, forwards move, moneyness changes, vols need recalculating, smiles update, and the volatility surface updates.
Forward and moneyness inputs change across expiries.
Bid, ask, and mid IVs need fresh inversion.
SVI fits and diagnostics consume the refreshed vol layer.
The dashboard and API receive updated state.
That turns a few calculations into potentially tens of thousands of implied volatility calculations in short bursts. The MVP became less about fitting the surface and more about avoiding recalculating the world on every tick.
Practical fixes
Throughput improved by making recalculation more selective.
The useful optimisations were practical rather than exotic. The goal was to reserve full implied-volatility inversion for moments where it changed the analytical state enough to matter.
- Ignoring tiny spot and ATM moves that would not realistically move volatility by even 1bp.
- Using linear approximations for small moves instead of full recalculation.
- Debouncing refreshes during bursts of market-data updates.
- Caching calculations with rounded state buckets.
- Using a C++ implementation of Let's Be Rational for implied-volatility inversion.
With those changes in place, throughput moved from hundreds of vols per second to roughly 5000 vols per second on a relatively small machine.
Scaling direction
The hard problem becomes systems engineering.
That throughput is useful for one currency and a couple of exchanges. Once you add more exchanges, more currencies, more expiries, and more downstream analytics, the design naturally moves toward distributed compute and partitioned market-data pipelines.
The interesting part is that the hard problem stopped being the maths. It became systems engineering: deciding when to compute, where to compute, how to partition live state, and how to keep the dashboard responsive while the market is moving.
Related links