Trading Platform Architecture —
Technical Guide for Brokers

The Five-Layer Architecture

A professional trading platform is not a monolithic application. It is a distributed system with five distinct layers, each with its own scaling profile and failure mode.

1. Client Layer — Web SPA (React/Vue), mobile apps (Android), and desktop terminal (Electron or native). Communicates via REST for commands and WebSocket for live data streaming.
2. API Gateway Layer — Authentication (JWT), rate limiting, request routing and protocol translation. Often built on NGINX or a service mesh.
3. Core Services Layer — Order Management System (OMS), Pricing Engine, Risk Engine, Account Service, Reporting Service and Notification Service. Each is a separate microservice.
4. Data Layer — PostgreSQL for transactional data (orders, accounts, trades), TimescaleDB or InfluxDB for tick data, Redis for live price cache and session management.
5. External Integration Layer — FIX/REST connections to liquidity providers, payment gateway APIs, KYC provider webhooks, and email/SMS delivery services.

Order Management System (OMS) Design

The OMS is the transaction backbone of the platform. Every order passes through it.

• Order State Machine — Each order follows a well-defined state graph: New → Pending → Accepted → Working → PartiallyFilled → Filled | Cancelled | Rejected. State transitions must be atomic and auditable.
• Execution Modes — Instant execution (broker fills immediately at displayed price), market execution (filled at best available price), and straight-through processing (STP, sent directly to LP).
• Aggregation — In STP mode, orders from multiple clients are aggregated into net positions before being hedged at the LP to minimise transaction costs.
• Persistence — All order state changes are written to the DB synchronously before confirmation is sent to the client. No in-memory-only state allowed.

Pricing Engine Architecture

The pricing engine receives raw ticks from LPs and publishes derived prices to clients.

• Inbound FIX or WebSocket tick feeds from one or more LPs
• Aggregation: best-bid/best-ask selection across LP feeds
• Spread markup applied (configured per instrument, per client group)
• Prices published via Redis pub/sub → WebSocket server → clients
• Historical OHLCV candle aggregation runs as an async job against the tick store

Risk Engine Design

The risk engine operates as a pre-trade check before every order is accepted.

• Margin sufficiency check (will this order breach margin requirements?)
• Position limit enforcement (per-instrument and per-account caps)
• Group exposure monitoring (net broker-level position per instrument)
• Real-time margin watcher (background thread calculating equity vs used margin every few seconds)
• Automated margin call issuance and stop-out trigger when margin level falls below threshold

Data Architecture & Storage Strategy

Data Type	Storage	Rationale
Orders & Trades	PostgreSQL	ACID guarantees, foreign key integrity
Account Balances	PostgreSQL	Strong consistency for financial data
Raw Tick Data	TimescaleDB	Time-series optimised, compresses well
OHLCV Candles	TimescaleDB	Pre-aggregated for chart speed
Live Prices	Redis	Sub-ms read latency, pub/sub distribution
Session State	Redis	TTL-managed, horizontally shared
Documents (KYC)	Object Storage (S3)	Cheap, durable blob storage

Scalability Patterns

• Stateless Services — OMS, pricing and risk services hold no in-memory client state. Any instance can serve any request, enabling horizontal pod scaling.
• Message Queue Decoupling — Non-critical downstream events (email notifications, trade reconciliation, copy trade distribution) are published to a queue (Kafka or RabbitMQ) and consumed asynchronously.
• Read Replicas — All reporting and analytics queries run against PostgreSQL read replicas to prevent them from competing with write-path latency.
• CDN for Client Assets — JavaScript bundles, charts and static assets are served from a CDN edge node — reducing origin server load and improving client load times globally.
• Connection Pooling — PgBouncer sits in front of PostgreSQL to prevent connection exhaustion during peak client session counts.

Security Architecture

• TLS 1.3 end-to-end encryption for all client and LP connections
• JWT tokens with short expiry (15 min) + refresh token rotation
• IP allow-list for LP and payment gateway webhooks
• Secrets management via Vault or cloud-native KMS (no plaintext credentials in config files)
• SOC2-aligned audit logging for all order, account and configuration changes
• DDoS mitigation at CDN layer (rate limiting, Layer 7 WAF)