This repository contains a high performance centralized exchange backend implemented in Rust. The system is designed for low latency order execution, strong consistency in financial operations, and horizontal scalability across services. The architecture follows an event driven model using a distributed log to ensure durability, replayability, and fault tolerance.
The system is built around deterministic processing, minimal latency in the matching path, and clear separation of responsibilities between services. Critical trading logic is kept in memory for speed, while persistence and downstream processing are handled asynchronously through event streams.
A web user interface built with Next.js interacts with the backend through a secured API gateway. All requests pass through authentication and rate limiting before entering internal services.
The API gateway handles TLS termination, routing, and rate limiting. The authentication service manages JSON Web Tokens, API keys, and optional two factor authentication. This layer ensures that only authorized requests reach internal systems.
A Kafka cluster acts as the backbone of the system. All state changes are emitted as events including new orders, fills, executed trades, and balance updates. Topics are durable and replayable, allowing services to recover state or scale independently.
Implemented in Rust and running fully in memory, the matching engine is responsible for order book management and trade execution. It consumes order events and produces execution results with minimal latency.
Validates incoming orders and persists them for auditability. It ensures correctness before forwarding orders to the matching engine.
Enforces trading limits and monitors exposure. It evaluates orders before execution to prevent invalid or risky trades.
Manages deposits and withdrawals. It updates balances and emits balance events that propagate through the system.
Handles outbound communication such as email, push notifications, and websocket updates to clients.
Used for fast access to order book snapshots, session tokens, and balance caching. It also provides publish and subscribe capabilities for websocket fanout.
Stores users, orders, trades, balances, and audit logs. It serves as the primary source of truth for transactional data.
Stores OHLCV candle data and tick level market history for analytics and charting.
Used for trade reports, account statements, and compliance exports.
Horizontally scalable websocket pods subscribe to Redis channels and push real time updates such as order book depth, trades, and fills to connected clients. Sticky sessions ensure consistent routing for active connections.
Balance updates are published to Redis and broadcast to websocket nodes, enabling near real time account state visibility with sub millisecond read performance.
Local development is supported via Docker Compose. Production workloads run on Kubernetes with horizontal pod autoscaling for API and websocket services. Stateful components such as Kafka are deployed using StatefulSets.
External traffic is routed through an ingress controller and load balancer, distributing requests across API gateway pods, websocket pods, and other services.
Monitoring is handled using Prometheus and Grafana. Logging is centralized with Loki, and distributed tracing is implemented using Jaeger. This provides full visibility into request flows and system performance.
Build and deployment pipelines are managed using GitHub Actions. Continuous delivery is implemented with Argo CD and Helm charts to ensure reproducible and controlled releases.
- A client submits an order through the API gateway.
- The order is authenticated and validated by the order service.
- The order event is published to Kafka.
- The matching engine consumes the event and executes trades.
- Execution results are emitted back into Kafka.
- Wallet and balance services update account states.
- Redis propagates updates to websocket gateways.
- Clients receive real time updates through persistent connections.
Stateless services scale horizontally behind the load balancer.
Stateful components rely on replication and partitioning.
Kafka ensures durability and replay capability for all critical events.
Redis enables low latency data access and pub sub messaging.
Services can recover state by replaying event streams.
All external communication is secured with TLS.
Authentication uses token based mechanisms with optional two factor support.
Rate limiting protects against abuse and denial of service attacks.
Audit logs are maintained for all financial operations.
This architecture is designed to meet the demands of a modern centralized exchange, balancing performance, reliability, and scalability. Rust provides the necessary performance guarantees for latency sensitive components, while the event driven design ensures resilience and extensibility across the platform.