System architecture

Shape

Spreadr is a modular system split into a control tier and a fleet of per-trade workers, backed by durable storage. Each active spread runs in its own worker with its own runtime and its own network egress.

              Users (web terminal / API)
                       │
                       ▼  TLS
                 API Edge (auth, rate limits)
                       │
                       ▼
                Control Tier  ────────────────┐
                       │                       │
                       ▼  durable queue        │
        ┌──────────────┼──────────────┐        │
        ▼              ▼              ▼        ▼
    Worker A       Worker B       Worker N   (durable ledger,
    Trade 1        Trade 2        Trade N     metrics, audit)
    own runtime    own runtime    own runtime
    own egress     own egress     own egress
        │              │              │
        ▼              ▼              ▼
    Exchange 1     Exchange 2     Exchange 3

Control tier

The control tier authenticates requests, validates spread configurations against the user's limits, and dispatches each accepted spread onto a durable queue for a worker to pick up. It owns no execution state of its own beyond what is persisted; the durable store is the source of truth. State is held in DynamoDB, which gives the control plane and workers a consistent, horizontally scalable view without a separate database tier to operate.

Per-trade workers

Each spread is executed by a dedicated worker process. Isolation is a deliberate design choice with two payoffs:

• Rate-limit isolation. A worker has its own egress, so two spreads never compete for the same per-IP or per-key rate-limit budget. One user's heavy trade cannot throttle another's.
• Blast-radius containment. A fault in one trade — a bad exchange response, a stuck order — is contained to its worker and reconciled independently, without affecting other trades.

Workers connect directly to the venue endpoints they need, streaming order books and account state and placing orders on the shortest path.

Colocation

The worker fleet runs in AWS ap-northeast-1 (Tokyo), close to the major venue endpoints, which keeps round-trip latency to the low single-digit milliseconds for the most latency-sensitive venues. Because spread opportunities decay quickly, physical proximity to the matching engines is a functional requirement, not an optimization.