In this post, we'll walk through the architecture and key design decisions behind a real-time trading analytics platform that processes tick-level market data for multi-asset operations.
Architecture Overview
The platform is built around an event-driven architecture with three main layers:
- Ingestion Layer — Streams market data from cTrader and OANDA APIs into a message queue
- Processing Layer — Computes cycle-based trading signals and maintains state
- Serving Layer — Surfaces analytics via REST API and a web dashboard
Key Design Decisions
Python + FastAPI
FastAPI provides async request handling, automatic OpenAPI documentation, and great performance for I/O-bound workloads. Combined with Pydantic models for validation, it's an excellent choice for building data-intensive APIs.
PostgreSQL as State Store
Rather than introducing a separate database for time-series data, we use PostgreSQL with carefully designed table structures. Cycle data has natural temporal boundaries that map well to relational models. Indexing on asset_id and timestamp gives us sub-millisecond query times for recent data.
Docker for Consistency
Everything runs in Docker containers orchestrated via Docker Compose. This gives us reproducible environments across development, staging, and production — critical when dealing with time-sensitive trading infrastructure.
Cycle Detection Algorithms
The core of the system is a cycle detection engine that identifies weekly and daily trading cycles from price data. The algorithm:
- Ingests OHLCV data from broker APIs
- Applies a multi-resolution peak/trough detection algorithm
- Classifies cycles by type (RT, LT, IN) based on their structural characteristics
- Generates trading plans with entry, target, and stop levels
We've augmented this with LLM-based analysis that adds context-aware classification and handles edge cases that purely algorithmic approaches struggle with.
Interested in the technical details? Get in touch →