Backbone
Kafka as the market-data backbone.
In the planned architecture, exchange connectors publish normalized option-book, trade, future, and index updates into currency-partitioned Kafka topics. Downstream consumers can replay, inspect, and recover without turning that roadmap into a current live-coverage claim.
Topic model
Separate raw events, normalized quotes, fits, and patches.
A pragmatic topic model separates raw exchange events, normalized option quotes, forward context, fitted SVI surfaces, risk nodes, fit diagnostics, and websocket-ready patches.
Keys should include currency, expiry, strike, venue, and instrument where relevant.
Workloads
Kubernetes gives each runtime a scaling boundary.
In Kubernetes, ingestion pods, calibration workers, API gateways, and websocket broadcasters can scale independently. Calibration workers scale with fit latency and topic lag, while websocket gateways scale with connected users and fanout pressure.
Reliability
Replay and recovery become explicit.
Kafka offsets make replay and recovery explicit. Kubernetes readiness checks should fail when a worker is stale, unable to reach Kafka, or publishing fits that violate quality thresholds.
Dead-letter topics preserve bad payloads for inspection.
Dashboard contract
What changes for the UI.
The browser should still receive compact websocket snapshots and patches. Kafka and Kubernetes change the reliability and scaling of the backend, not the trader-facing contract.
The UI remains focused on current surface state, RR/fly metrics, quote overlays, and fit health.
Access
API testing remains the external boundary.
Approved evaluators can consume beta WebSocket snapshots and patches for the live BTC surface. REST behavior and other maintained currency configurations remain in testing and are supplied only under the applicable evaluation contract.