Betcloud

Problem

Betcloud wanted to license bookmaking as a platform: one backend running many white-label bookie brands, each with its own punters, odds margins, and admin panel, plus a regulator-facing view for Australian compliance.

Wagering is an unforgiving domain. Odds change constantly and every change must be auditable, money movements need a real ledger, and a bet is a financial transaction that has to be priced, exposure-checked, and settled atomically. We built the backend for all of it in about nine months.

What I built

I worked on the core backend as part of a four-person backend team at our agency.

• A FastAPI service on Cloud Run over Postgres, with a domain model of roughly 60 tables: platforms, punters, wallets, races, runners, sports, markets, propositions, bets, and the exposure tables that feed the bookmaker’s trading desk.
• Multi-tenancy from day one. Nearly every table is scoped to a platform, so one deployment serves every white-label brand.
• An ingestion layer of Pub/Sub-triggered Cloud Functions that pulls fixtures, odds, and results from the TAB feed, with retry and concurrency limits tuned around an API that regularly fails its first request.
• A cascading margin engine: platform margin, then race-type, venue, race, and runner modifiers summed down the chain, so traders can adjust odds at whatever level of granularity the moment demands.
• KYC through GreenID, card payments through Fat Zebra, Elasticsearch for event search, and deposit limits for responsible gambling controls.

Decisions worth explaining

Every mutable table has a history twin. Odds and statuses change by the second, and a punter disputing a settled bet needs the platform to prove what the odds were at the moment of placement. A temporal mixin pattern paired each live table (races, runners, markets, propositions) with a history table, giving point-in-time answers for any regulatory question without bolting on an audit system later.

Bet placement is raw SQL on purpose. Placing a bet has to compute live odds, check per-level exposure limits, debit the wallet, and write ledger rows, all atomically. We wrote it as one composed chain of CTEs rather than ORM calls, using a small in-house builder that lets the SQL stay testable and readable. The ORM is fine for the other 95% of the codebase. The money path earned different rules.

A ledger, not a balance column. Every transaction records its direction, type, and a running balance snapshot. When a settlement question comes up, the answer is in the rows, not reconstructed from application logs.

Quality gates sized for the risk. Codecov enforced 80% coverage on every diff and 90% overall, with SonarCloud gating merges. On a betting platform, that rigour is table stakes rather than ceremony.

Outcome

The platform shipped through dev, UAT, and production environments with around 1,300 pull requests merged in nine months. Betcloud went on to secure funding on the strength of the product.

Stack

FastAPI and SQLAlchemy on Cloud Run, Postgres, Elasticsearch, Pub/Sub-driven Cloud Functions for feed ingestion, Firebase auth, GreenID, and Fat Zebra, all on GCP.