Lesson 7 — Risk, hedging & deployment
Final lesson: implement green-up hedges and risk controls, ensure idempotent and observable order flows, and deploy your bot safely using Docker or a VPS with proper monitoring and runbooks.
Prerequisites
- Lessons 1–6 completed (env, auth, market lookup, orders, webhooks, backtesting)
- Basic Linux command line, Docker basics (optional), and a small VPS or cloud instance for deployment
- Logging/monitoring basics (Prometheus/Grafana or cloud provider metrics are helpful)
Overview
We’ll cover:
- Green‑up hedging patterns to limit directional exposure
- Risk limits, circuit breakers and kill switches
- Idempotency, logging, and order reconciliation
- Packaging with Docker and simple VPS deployment steps
- Monitoring, alerts, and runbooks
1) Green‑up hedging basics
Green‑up hedging reduces exposure by placing offsetting orders so that your combined position is roughly neutral. For a BACK position on one runner, you may LAY other runners or place opposing orders to lock profit/loss.
# simple green-up calculation (conceptual)
# position: dict {selectionId: {size, avg_price}}
# To green-up a target P&L, compute hedge size/price using current market book.
def compute_greenup(position, market_book, target_pnl=0.0):
# position: {selectionId: {'size': s, 'avg_price': p}}
# market_book: runners with availableToLay/availableToBack arrays
# Very simplified: compute required lay size on other runners to reduce exposure
# Replace with full liability calculations in production
pass
Practical guidance: start with small hedges in sandbox. Hedging may require multiple orders across runners and can be affected by commission. Record all hedge orders and results for reconciliation.
2) Risk limits, circuit breakers & kill switches
Implement the following controls:
- Per-trade max stake and max exposure limits
- Daily P&L stop: pause trading if cumulative P&L exceeds a threshold
- Rate limits: max orders per minute and bursts throttling
- Emergency kill switch: an immediate stop that cancels open orders and suspends further trading
# example check before placing any order
def pre_trade_checks(account_state, trade_request):
if trade_request['size'] > account_state['max_trade_size']:
raise Exception('Trade size exceeds limit')
if account_state['daily_pnl'] < -account_state['max_daily_loss']:
raise Exception('Daily loss limit reached')
# add additional checks (market open, liquidity, allowed hours)
return True
Ensure these checks run synchronously before order placement (or in the queuing layer) so dangerous trades are blocked early.
3) Idempotency, logging & reconciliation
Idempotency tokens (customerRef) prevent duplicate orders on retries. Maintain a persistent order store and reconcile server states with Betfair using a scheduled job.
# reconciliation job pseudocode
# periodically fetch settled transactions / order history and reconcile local store
def reconcile_orders():
local = load_local_orders()
remote = fetch_remote_orders_from_api(since=last_sync)
for r in remote:
match = find_local_by_customer_ref(r['customerRef'])
if match:
update_local_with_remote(match, r)
else:
log_unmatched_remote(r)
Logging: log request bodies, responses, errors, timestamps and idempotency tokens. Use structured JSON logs and ship them to a log aggregator (ELK / Loki / cloud logs).
4) Packaging and deployment (Docker + VPS)
Example Dockerfile and simple steps to deploy to a VPS. Use a process manager (systemd) or container orchestrator for production.
# Dockerfile (example)
FROM python:3.11-slim
WORKDIR /app
COPY pyproject.toml poetry.lock* /app/
RUN pip install --upgrade pip && pip install -r requirements.txt
COPY . /app
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "webhook:app"]
VPS deploy (simple):
# on VPS (Ubuntu)
# install docker & docker-compose
sudo apt update && sudo apt install -y docker.io docker-compose
# copy image or docker-compose.yml and run
docker-compose up -d --build
Prefer managed services (digital ocean apps, AWS ECS, Heroku) for easier maintenance if you don't want to manage infra. Keep secrets in environment variables or a vault (HashiCorp Vault, AWS Secrets Manager).
5) Monitoring, alerts & runbooks
Essential monitoring:
- Order success/failure rates and retries
- Latency histograms for critical endpoints (market book fetch, place order)
- Daily and per-trade P&L metrics
- Error rates and abnormal spikes
Alerting recommendations:
- High failure rate (e.g., >5% failed orders in 10 minutes)
- Daily loss threshold breached
- Webhook verification failures spike
Runbooks: document steps for common incidents: disable trading, cancel open orders, rotate API keys, recover from partial-match reconciliation.
6) Operational tips & checklist
- Use feature flags to toggle strategies on/off without deploys
- Automate backups of persistent stores and logs
- Test upgrades in a staging environment with sandbox keys
- Rotate API keys and maintain a secure secrets policy
- Run a simulated "chaos" test periodically to verify kill switch behavior
Wrap up and next steps
You've completed the Betfair track. Recommended next steps:
- Review all logs and reconciliation outputs after a full sandbox run.
- Start a staging deployment with tiny stakes (or continue using sandbox).
- Consider adding export/import progress or email restore for users if you expand training across devices.
