Bybit Backtester

An event-driven backtesting engine in Go that replays real Bybit historical data and reports Sharpe ratio and maximum drawdown, with a single-page UI to run backtests and view equity curves, trade markers, and indicator overlays.

Requires PostgreSQL and Redis. Use Docker Compose:

docker compose up -d --build
# open http://localhost

Pick a product, timeframe, and strategy, set a lookback window, and hit Run backtest. First run for a window fetches from Bybit (a few seconds); identical bar windows are served from Redis; identical backtest requests return instantly from the result cache.

Run the tests:

go test ./...

docker compose up -d --build

Then open http://<server-ip> (port 80 mapped to the app).

Services: bybit-backtester, postgres, redis.

Environment variables (set in docker-compose.yml):

On a small Ubuntu EC2 instance with Docker and the Compose plugin installed:

git clone <your-repo-url>
cd bybit-backtester
docker compose up -d --build

On later deploys:

git pull
docker compose up -d --build

If you want the app reachable publicly, allow inbound TCP 80 in the EC2 security group (or place it behind a load balancer with TLS later).

1. Data Handler (internal/data) — fetches OHLCV bars from Bybit on cache miss, stores windows in Redis, streams bars one at a time, in order.
2. Strategy (internal/strategy) — receives each bar, holds its own indicator state (moving averages / RSI), and emits orders. Pluggable via one Go interface.
3. Broker (internal/broker) — simulates fills: applies slippage (always adverse) and a percentage fee. No real exchange, so it models reality.
4. Portfolio (internal/portfolio) — tracks cash, the open position, and the equity curve (account value at every bar). The equity curve is the source of truth for every metric.
5. Metrics (internal/metrics) — consumes the equity curve to produce Sharpe and Max Drawdown.

Everything flows through a min-heap event queue ordered by (timestamp, type). The engine pops the earliest event, routes it, and pushes any events the component emits:

MarketEvent → strategy.OnBar() → OrderEvent → broker.Execute() → FillEvent → portfolio.OnFill()

The anti-look-ahead rule: a strategy decides on bar T using data up to and including T's close (the close is only knowable once the bar is over). It therefore cannot trade at T's close. Orders decided on bar T are held as pending and filled at the open of bar T+1 — the earliest price a real trader could act on. This is enforced in the engine loop, and proven by TestNoLookAhead in internal/engine/engine_test.go, which asserts a buy decided on one bar fills at the next bar's open, not the decision bar's close.

/cmd/api              → main, server + worker pool wiring
/internal/engine      → event types, time-ordered queue, the run loop + interfaces
/internal/data        → Bybit fetch + Redis bar cache (DataHandler)
/internal/cache       → Redis client (bars + result cache)
/internal/store       → PostgreSQL job store + migrations
/internal/indicators/ → shared indicator math (SMA, EMA, RSI, Bollinger, Donchian)
/internal/strategy    → seven pluggable strategies (one file each)
/internal/broker      → execution simulation (fees, slippage)
/internal/portfolio   → cash, position, equity curve, trade log
/internal/metrics     → Sharpe + Max Drawdown (+ unit tests)
/internal/api         → Gin handlers, worker pool, persist layer
/web                  → single-page UI (chart + metrics)

Request body:

{ "symbol": "BTCUSDT", "interval": "5", "strategy": "rsi_reversion", "days": 30 }

• More metrics (win rate, profit factor, CAGR) and parameter sweeps.
• Configurable date ranges beyond rolling lookback days.
• External job queue (Redis Streams / NATS) for multi-instance workers.
• Golden-file tests pinning a known strategy/dataset for reproducibility.