Application Architecture Evolution
Exness is a highly responsive, institutional-grade cryptocurrency leveraged trading platform. Below is a full retrospective outlining our architectural migration from an agile, single-instance architecture (v0) to a scalable, microservices-driven, low-latency execution framework (v1).
Legacy Architecture (Version 0)
Our initial implementation was built as a single, centralized monolithic server. All critical components (web framework, HTTP routing, real-time matching, order books, and position margins) were kept completely in memory inside a single Node.js thread.
Major Version 0 Bottlenecks:
- State Volatility: Because matching state and ledger were inside server memory, restarting or crashing the process resulted in 100% loss of active order books and balances.
- Unscalable Matching: Single-threaded CPU execution meant complex balance calculations and limit margin matches blocked the HTTP thread, resulting in high latency spikes under trade spikes.
- Inefficient DB Writes: Writing every raw tick directly into a traditional PostgreSQL instance created heavy write lock bounds, causing massive CPU bottlenecks.
Distributed Architecture (Version 1)
The active system decouples state and scaling vectors into an event-driven core. The **Matching Engine** is extracted into an independent microservice (**Engine**), communicated through ultra-high-speed **Redis Streams** for thread-safe asynchronous order dispatching.
Version 1 Architectural Upgrades:
- Decoupled Trading Engine: The Backend handles API requests and mounts user tokens, while the dedicated Engine microservice processes limits and liquidations in isolated processes with maximum safety.
- Redis Stream Broker: Redis streams act as message brokers. The Backend streams order events onto `stream:exness` and polls `stream:exnessReceive`. This creates an asynchronous, robust thread model capable of handling thousands of requests concurrently.
- TimescaleDB Integration: Rather than querying simple Postgres models, high-frequency candlesticks are aggregate-chunked and written directly to a TimescaleDB hypertable for optimized, sub-millisecond query indices.
- Asynchronous Worker Queues: Non-critical paths like SMS/Email notifications, transaction journaling, and ledger snapshots are outsourced to background queue workers, eliminating API thread blocking.
Engine Decoupling
Moving the order-matching engine to a separate microservice ensures the Backend is entirely stateless. The API gateway can horizontally auto-scale behind standard routing loads, keeping the platform immune to HTTP floods.
TimescaleDB Hypertable
Market candles require specialized time-series indexes. TimescaleDB hypertables handle automatic data partitioning on temporal indexes, allowing the platform to store and query millions of candles at negligible cost.
State Snapshotting
For maximum safety against reboots, the Engine creates hourly encrypted snapshots of active user balances and order inventories. Upon cold restart, the Engine re-loads the latest snapshot, bringing recovery time under 500 milliseconds.
Interactive API Explorer
Explore, test, and integrate with the Exness backend services directly from our interactive documentation. Powered by Scalar.