arockiadassdev/ai-crypto-trading-bot

Purpose and entry points

This is a Python crypto-trading research and paper-trading system combining Binance market data, technical indicators, ML/DL predictions, strategy signals, risk controls, and historical backtests. FastAPI is the service boundary at backend/app/main.py; REST routes are in backend/app/api/trading.py and backend/app/api/health.py. The operator-facing dashboard starts at streamlit_app/app.py.

Runtime and deployment topology

The intended runtime is Python 3.13+, with FastAPI/Uvicorn for the API and a separate Streamlit process. Containers are defined by Dockerfile, Dockerfile.streamlit, and docker-compose.yml. Material external dependencies are PostgreSQL 16, Redis 7, Binance through CCXT and its WebSocket API, and MLflow. Docker database initialization is at docker/postgres/init.sql.

API orchestration boundary

Trading endpoints accept API schemas, invoke domain services, and return operational state such as prices, signals, portfolio data, model predictions, backtests, and paper orders. The route layer should remain the boundary between HTTP concerns and trading behavior:

• backend/app/api/trading.py

• backend/app/schemas/trading.py

• backend/app/main.py

Health, readiness, and liveness checks are isolated from trading operations in backend/app/api/health.py and backend/app/schemas/health.py.

Market-data and feature pipeline

Historical acquisition and live streaming feed the system’s market-data path. Binance integration is encapsulated rather than exposed directly to strategies; data is processed into indicator/feature-bearing datasets before signal or model use. Local persistence directories distinguish raw, processed, and feature datasets.

• backend/app/services/exchange.py

• backend/app/websocket/client.py

• backend/app/services/data_pipeline.py

• backend/app/services/historical_data.py

• backend/app/indicators/compute.py

• data/raw, data/processed, data/features

Strategy, risk, and paper execution flow

The primary decision flow is market data/features → strategy engine and signal generator → risk validation/sizing → simulated execution → portfolio/trade state. Risk is a hard control boundary before execution; paper trading is the available execution implementation, not evidence of live-order placement.

• backend/app/strategy/engine.py

• backend/app/strategy/signal_generator.py

• backend/app/risk/manager.py

• backend/app/trading/paper_trading.py

• backend/app/portfolio/manager.py

Domain records for orders, trades, signals, portfolios, and market data are modeled under backend/app/models/order.py, backend/app/models/trade.py, backend/app/models/portfolio.py, backend/app/models/trading_signal.py, and backend/app/models/market_data.py.

ML and model lifecycle

The ML subsystem supports tree-based and LSTM models, preprocessing, and a registry layer. Training/inference is exposed through the API orchestration path and consumes prepared market features; trained artifacts are stored separately from source. MLflow is the experiment/model-tracking integration.

• backend/app/ml/xgboost_model.py

• backend/app/ml/lstm_model.py

• backend/app/ml/model_registry.py

• backend/app/utils/preprocessing.py

• models, mlflow

Backtesting and persistence

Historical strategy evaluation is separated from live/paper decisioning in backend/app/backtesting/engine.py, producing persisted backtest results via backend/app/models/backtest_result.py. PostgreSQL access uses async SQLAlchemy session/base modules, with schema evolution managed by Alembic:

• backend/app/database/session.py

• backend/app/database/base.py

• backend/alembic/versions/001_initial_schema.py

Operational outputs and generated pipeline results belong in artifacts; configuration and structured logging are centralized at backend/app/config/settings.py and backend/app/core/logging.py.