Skip to content

ADR 010: Deployment Architecture

Status

Accepted

Context

The trading system's performance depends heavily on network latency to exchange APIs. Cross-platform arbitrage opportunities may exist for only milliseconds, making deployment location critical.

Key latency targets: - Polymarket CLOB API: Hosted infrastructure (unknown exact location) - Polygon RPC: Multiple providers, us-east-1 optimal - Kalshi API: NYC-based infrastructure

Decision

Deploy the trading core in AWS us-east-1 (N. Virginia) for optimal latency to both platforms.

Location Analysis

Location Polymarket Latency Kalshi Latency Verdict
AWS us-east-1 ~5ms (Polygon RPC) ~2ms (NYC) Chosen
Hetzner Ashburn ~3ms ~5ms Alternative
GCP us-east4 ~10ms ~8ms Acceptable
AWS us-west-2 ~50ms ~70ms Rejected

Deployment Model

┌──────────────────────────────────────────────────────────────┐
│                    AWS us-east-1                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │                     VPC                                 │  │
│  │  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐   │  │
│  │  │ Trading Core │ │  Telegram    │ │   Web API    │   │  │
│  │  │ (ECS/Fargate)│ │  Bot (ECS)   │ │  (ECS)       │   │  │
│  │  │  c6i.xlarge  │ │  t3.small    │ │  t3.medium   │   │  │
│  │  └──────┬───────┘ └──────────────┘ └──────────────┘   │  │
│  │         │                                               │  │
│  │  ┌──────▼───────────────────────────────────────────┐  │  │
│  │  │          Aurora PostgreSQL + ElastiCache          │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Instance Sizing

Component Instance Type Rationale
Trading Core c6i.xlarge Compute-optimized for low-latency processing
Telegram Bot t3.small Light workload, burstable
Web API t3.medium Moderate traffic expected
PostgreSQL Aurora Serverless v2 Auto-scaling, managed
Redis ElastiCache r6g.large In-memory orderbook cache

Alternatives Considered

Approach Pros Cons Verdict
AWS us-east-1 Best latency, mature ecosystem Higher cost Chosen
Hetzner Ashburn Cost-effective Less managed services Alternative
Multi-region Redundancy Complexity, consistency issues Future
On-premise colocation Lowest latency High upfront cost Future (scale)

Consequences

Positive

  • Optimal latency to both Kalshi (NYC) and Polygon RPC nodes
  • Mature AWS ecosystem for managed services
  • Easy scaling with ECS/Fargate
  • Aurora provides automatic failover

Negative

  • AWS costs higher than bare metal
  • Single-region deployment (no geographic redundancy initially)
  • Vendor lock-in to AWS services

Neutral

  • Can migrate to colocation if latency requirements tighten

References

Linked Requirements

  • NFR-ARCH-006: Deploy core in AWS us-east-1 for low latency