7.7 KiB
7.7 KiB
Architecture Overview
This document provides a high-level overview of the Crypto Trader architecture.
System Architecture
Crypto Trader follows a modular architecture with clear separation of concerns:
┌─────────────────────────────────────────────────────────┐
│ Frontend (React + Vite) │
│ Dashboard | Strategies | Portfolio | Backtest | Settings│
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Backend API (FastAPI) │
│ Autopilot | Trading | Market Data | WebSocket │
└─────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Redis │ │ Celery │ │ PostgreSQL │
│ State/Cache │←───│ Workers │ │ Database │
└──────────────┘ └──────────────┘ └──────────────────┘
▲ │
│ ▼
┌─────────────────────────────────────────────────────────┐
│ Trading Engine │
│ Order Management | Position Tracking | Risk Management │
└─────────────────────────────────────────────────────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Strategies │ │ Exchanges │ │ Portfolio │
│ Framework │ │ Adapters │ │ Tracker │
└──────────────┘ └──────────────┘ └──────────────┘
Core Components
1. Frontend Layer
- Framework: React with TypeScript
- Build Tool: Vite
- Components: Dashboard, Strategy Manager, Portfolio View, Backtest View, Settings
- State Management: React Query, Context API
- Styling: Material-UI (MUI)
2. Backend API
- Framework: FastAPI (async Python)
- Features: RESTful API, WebSocket support, auto-docs (Swagger/OpenAPI)
- Authentication: JWT tokens (planned)
- Responsibilities: Orchestrates all business logic
3. Redis (State Management)
- Purpose: Distributed state management and caching
- Use Cases:
- Autopilot registry (prevents multiple instances)
- Daily trade count persistence (survives restarts)
- Session caching (planned)
- Real-time data caching (planned)
- Configuration:
src/core/config.py→redissection
4. Celery (Background Tasks)
- Purpose: Offload CPU-intensive tasks from the API
- Use Cases:
- ML model training (
train_model_task) - Data bootstrapping (
bootstrap_task) - Report generation (
generate_report_task)
- ML model training (
- Broker: Redis
- Worker Command:
celery -A src.worker.app worker --loglevel=info
5. Trading Engine
- Responsibilities: Order execution, position management, risk checks
- Components: Trading engine, order manager, paper trading simulator
- Integration: Connects strategies to exchanges
6. Strategy Framework
- Base Class:
BaseStrategyprovides common interface - Registry: Manages available strategies (RSI, MACD, Bollinger, etc.)
- ML Selection:
IntelligentAutopilotuses ML to select optimal strategies - Features: Multi-timeframe support, scheduling, parameter management
7. Exchange Adapters
- Pattern: Adapter pattern for unified interface
- Factory: Dynamic exchange instantiation
- Current: Coinbase Advanced Trade API, Binance Public
- Data Providers: CCXT-based providers with automatic failover
8. Risk Management
- Components: Risk manager, stop-loss, position sizing, limits
- Integration: Pre-trade checks, real-time monitoring
- Features: Drawdown limits, daily loss limits, position limits
9. Backtesting Engine
- Features: Historical data replay, realistic simulation
- Components: Engine, metrics, slippage model, fee model
- Optimization: Parameter optimization support
10. Portfolio Management
- Tracking: Real-time position tracking
- Analytics: Performance metrics, risk analysis
- Rebalancing: Automatic portfolio rebalancing (planned)
Data Flow
Trading Flow
- User starts autopilot → API receives request
- Redis lock checked/set → Prevents duplicate instances
- Strategy generates signal
- Risk manager validates trade
- Order manager creates order
- Exchange adapter executes order
- Position tracker updates positions
- Redis updates trade count
ML Training Flow (Background)
- User triggers
/retrainAPI - API queues
train_model_taskto Celery - API returns task ID immediately (non-blocking)
- Celery worker picks up task
- Worker bootstraps data if needed
- Worker trains model
- User polls
/tasks/{task_id}for status
Technology Stack
- Language: Python 3.11+
- Frontend: React 18, TypeScript, Vite
- Backend: FastAPI, Uvicorn
- Database: PostgreSQL with SQLAlchemy
- Cache/State: Redis
- Task Queue: Celery
- Exchange Library: CCXT
- Data Analysis: Pandas, NumPy
- Machine Learning: LightGBM, scikit-learn
- Technical Analysis: pandas-ta, TA-Lib
- Async: asyncio
- Testing: pytest, React Testing Library
Design Patterns
- Adapter Pattern: Exchange adapters
- Factory Pattern: Exchange and strategy creation
- Strategy Pattern: Trading strategies
- Observer Pattern: Data updates to strategies
- Singleton Pattern: Configuration, database connections, Redis client
Security Architecture
- API Key Encryption: Fernet encryption
- Secure Storage: Keyring integration
- Audit Logging: All security events logged
- Permission Management: Read-only vs trading modes
Scalability Considerations
- Async Operations: Non-blocking I/O throughout
- Redis State: Enables horizontal scaling of API workers
- Celery Workers: Can scale independently for heavy workloads
- Database Optimization: Indexed queries, connection pooling
- Data Retention: Configurable retention policies
Extension Points
- Exchange Adapters: Add new exchanges via adapter interface
- Strategies: Create custom strategies via base class
- Indicators: Add custom indicators
- Order Types: Extend advanced order types
- Risk Rules: Add custom risk management rules
- Celery Tasks: Add new background tasks in
src/worker/tasks.py