Surface monitor Derivasys
Cloud Architecture

AWS architecture

The frontend is a static Vite application, but the full DerivaSys system is a live pricing workflow: exchange ingestion, normalized market data, SVI calibration, websocket broadcasting, and browser rendering for BTC, ETH, and altcoin options.

AWS architecture diagram for DerivaSys showing CloudFront, S3, websocket API, ECS or EKS services, market data exchanges, secrets, and observability
The dashboard is served as static content, while live exchange ingestion, SVI calibration, risk generation, and websocket fanout run behind the API boundary.

1. Static frontend delivery

The dashboard build can be deployed to S3 and served through CloudFront with TLS, caching, compression, and canonical host redirects. This keeps the UI cheap to serve and separates static delivery from the live pricing API.

MVP deployment model

The MVP keeps the frontend static and pushes live complexity behind one websocket API. The browser downloads the React/Vite build, opens a WSS connection, receives the active BTC, ETH, or altcoin surface, and merges snapshots and patches locally. The pricing stack remains responsible for exchange ingestion, quote normalization, SVI calibration, RR/fly construction, and fit diagnostics.

  • S3 and CloudFront serve the dashboard over HTTPS.
  • The websocket API publishes compact surface snapshots and patches.
  • Backend services keep exchange credentials and calibration logic server-side.
  • CloudWatch tracks freshness, fit latency, reconnects, and queue pressure.

2. Websocket API boundary

The browser connects to a websocket endpoint for snapshots and patches. In AWS, that boundary can sit behind API Gateway, Application Load Balancer, or a containerized service with TLS termination, depending on latency and connection-count needs.

3. Runtime services

Exchange connectors, normalization, forward calculation, SVI fitting, risk node generation, and broadcast fanout should run as independent services. ECS is a pragmatic first step; EKS becomes attractive when stream processors, calibration workers, and websocket gateways need finer deployment control.

How the MVP scales

The UI contract should stay stable as the backend grows: the browser still receives current-state snapshots and sparse patches. Scaling happens behind the API boundary by separating ingestion, calibration, diagnostics, and fanout. ECS is a good first step for service isolation; EKS and Kafka become attractive when replay, topic lag, worker autoscaling, and controlled rollouts matter.

4. State and observability

CloudWatch metrics, structured logs, alarms, and trace IDs are required for production operation. The important metrics are feed freshness, queue depth, fit time, websocket connection count, dropped messages, and per-expiry calibration quality.

5. Security shape

Public traffic should terminate over HTTPS or WSS. Secrets belong in Secrets Manager or SSM Parameter Store, exchange credentials should never reach the browser, and the websocket API should expose only normalized surface data needed by the UI.