Taking Prophets — Multi-Broker Order Routing with Sub-Second Latency

Results

• Latency: <1s (p50), ~2s (p95); Uptime: 99%+
• Users: 16 connected accounts

Stack

Python, Flask, PostgreSQL, React, HTML5

TL;DR

I built a production API that routes orders across multiple broker integrations with sub-second p50 latency and resilient failover. It handles concurrent position updates, account metadata, and order lifecycle events with low latency and sustained high throughput.

Context

I co-run Taking Prophets, a project focused on making systematic trading execution simple for indie quants and small funds. Users connect their brokerage, define strategies, and place/monitor orders programmatically.

Problem

• Slow, sequential order processing during market open spikes.
• Fragile error handling when a single broker API throttled or hiccupped.

What I Built

• Flask REST API exposing endpoints for auth, account sync, order create/cancel, and position introspection.
• Parallelized orchestration using Python multiprocessing + async I/O to fan out broker requests.
• Circuit-breaker + retry policies per broker to survive rate limits and transient 5xxs.
• Idempotency keys to make order creation safe on retries.
• Structured logging with correlation IDs → trace a single order across services.

Architecture (high level)

• API (Flask) → Task queue → Worker pool
• Broker adapters (uniform interface) implementing auth, order placement, and status polling
• PostgreSQL for durable state + Redis for fast coordination

Key Decisions

• Adapters over conditionals: broker quirks isolated behind a clean interface.
• Idempotency by default: prevents double-fills on retries.
• SLOs: design by p95, not averages.

What I’d Do Next

• Move polling to webhooks/websockets where supported; cut latency + cost, if supported.
• Canary deploys for adapter changes; shadow traffic to detect drift.
• Batch margin checks to reduce pre-trade round-trips.