I built Tradex, a real-time crypto trading platform for assets like BTC, ETH, and SOL.
The UI looks simple.
The backend isn't.
Every trade needs to be validated, executed, and reflected across balances, positions, P&L, and margin in real time. At the same time, the system needs to process a constant stream of market data.
This is how I built it.
From order to execution
A trade starts when a user places a buy or sell order.
The backend first validates the order and checks the user's available balance. It then evaluates the account's risk and leverage before allowing the trade to execute.
Once approved, the trade is executed at the current market price.
The system then updates the user's position, P&L, available margin, and balance.
These updates need to happen together. Otherwise, different parts of the system can end up with different views of the same account.
Streaming market data
Market prices are constantly changing.
Tradex receives live price data from external exchanges and distributes those updates across the system using Redis Pub/Sub and Redis Streams.
Different services can consume the same events without blocking the trading engine.
The final updates are pushed to users through WebSockets.
This powers the real-time parts of the application:
- Price charts
- Position updates
- P&L changes
- Order execution updates
The goal is simple: when something changes in the backend, the user should see it immediately.
Storing what matters
Not every piece of data needs the same storage strategy.
Frequently changing data such as open positions, balances, and margin needs fast access. I kept this data in memory where possible.
Historical data is different.
Trade history and user information need durable storage, so I used databases such as PostgreSQL and MongoDB.
The system also creates periodic snapshots of important state.
If something fails, the system can recover from the latest snapshot instead of rebuilding everything from scratch.
Risk management
Leverage makes trading more interesting.
It also makes mistakes more expensive.
Tradex continuously checks account margin and position risk. Stop-loss and take-profit rules can automatically close positions when predefined price levels are reached.
The system also prevents trades from pushing accounts into invalid states, such as negative balances.
These checks happen as part of the order pipeline rather than after the trade has already been executed.
The architecture
The system uses an event-driven architecture.
The trading engine, risk checks, market data services, and user-facing services communicate through events instead of relying entirely on synchronous requests.
Redis handles the fast-moving data and event distribution.
WebSocket nodes handle connections with users.
Stateless APIs and load balancing allow the system to scale horizontally.
The important part is that each component has a clear responsibility.
The trading engine doesn't need to know how a WebSocket connection works. The WebSocket layer doesn't need to know how an order is executed.
They communicate through events.
What I learned
Building Tradex taught me that real-time systems are less about individual technologies and more about how those technologies work together.
I got hands-on experience with order execution, leverage, margin, slippage, P&L, Redis Streams, WebSockets, and event-driven architecture.
The hardest part wasn't displaying a live price.
It was keeping the entire system consistent while everything was changing at the same time.
That was the interesting part of building Tradex.