Persistent state over process memory
Recorded position data and database transactions provide a clearer recovery path than keeping critical state only in a running process.
Engineering project
Bybit Trading System Refactor with Real-Time State
A trading-system refactor centred on persistent position state, real-time Bybit data, webhook signal handling, and a React operational dashboard.
- 1Webhook signal
- 2Trading service
- 3Persistent position state
- 4Bybit REST and WebSockets
- 5Dashboard updates
Implementation scope
What this project implements
The refactor replaced in-memory position handling with PostgreSQL-backed state so active positions and protective order details could survive a process restart and be reviewed through a more reliable operational model.
The backend uses FastAPI services for authentication, settings, signal intake, and position handling. A dedicated WebSocket client consumes market and private execution updates, while the exchange REST API supports order actions.
The front end was reorganized around React, TypeScript, Zustand, TanStack Query, and a component system for settings, state visibility, and dashboard updates.
Engineering choices
Clear boundaries in the application design
Separate real-time streams
Public market and private account or execution streams are handled as explicit sources for different parts of the trading workflow.
Defined data-flow contracts
Clear API and WebSocket message boundaries make dashboard updates and trading-service responsibilities easier to maintain.
Current boundaries
Important limitations
- Broker connection behaviour, account permissions, and order states require deployment-specific validation.
- The work demonstrates trading-system engineering only. It does not make a claim about financial performance or investment outcomes.