Live Sports Betting — Naive (Polling + Monolith)

Live sports betting is a deceptively challenging real-time system design problem. At its core, the requirement seems simple: show users current odds for sporting events, let them place bets, and settle those bets when games end. But the combination of real-time data delivery, financial transaction integrity, and regulatory compliance creates a system that is far more complex than a typical web application.

The naive approach uses the simplest possible architecture: a monolithic backend with a single PostgreSQL database. Clients poll for odds updates every 3 seconds via GET /odds, and bet placement is a synchronous POST /bets with an odds_version check to prevent bets at stale prices. This optimistic locking pattern is the key correctness mechanism — without it, users could place bets at odds that no longer exist, creating financial risk for the operator.

The fundamental problem with polling is the N-users multiplier effect. Each connected user generates 0.33 read queries per second (one poll every 3 seconds), regardless of whether odds have actually changed. At 1,000 concurrent users, that is 333 QPS of identical queries returning the same data. At 3,000 users, it is 1,000 QPS — and this is just for odds reading, before a single bet is placed. The database becomes the bottleneck not from the write-heavy bet placement path, but from the read-heavy polling path.

The 3-second polling interval also creates an inherent staleness problem. Odds in live sports can change multiple times per second during volatile moments (goals, penalties, injury timeouts). A user viewing odds that are up to 3 seconds old will frequently attempt to place bets at prices that have already moved. The odds_version check catches this and rejects the bet, but from the user's perspective, this feels like a broken system — they see odds, tap to bet, and get an error. During peak volatility, the bet rejection rate can exceed 20%, creating a terrible user experience.

This template exists to make these failure modes visible and measurable. By running the simulation at increasing user counts, you can observe exactly when polling overwhelms the database, how the bet rejection rate correlates with odds volatility, and why the synchronous write path creates a hard ceiling on throughput. The comparison with the WebSocket streaming variant quantifies the dramatic improvement that push-based odds delivery provides.

Live betting system design appears in interviews at DraftKings, FanDuel, Bet365, and other sportsbook companies. Interviewers expect candidates to identify the polling bottleneck, propose WebSocket streaming as the solution, discuss odds versioning for consistency, and reason about settlement timing and regulatory requirements.

The naive live sports betting system is a five-component architecture: Bettor Client, Load Balancer, Betting Monolith, PostgreSQL Database, and Redis Session Cache. There is no WebSocket gateway, no message queue, no event stream, and no separation between the odds delivery path and the bet acceptance path.

All traffic arrives at the Load Balancer, which distributes requests across Betting Monolith pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and can handle up to 6,000 RPS — well above the system's actual limits, which are constrained by the database. The Load Balancer is never the bottleneck; the database is.

The Betting Monolith handles three types of requests. Odds polling (70% of traffic) queries PostgreSQL for the current odds and odds_version for a given market. Bet placement (20% of traffic) validates the bet against current odds using optimistic locking, checks the user's balance in Redis, and performs a synchronous INSERT into the bets table. Account balance queries (10% of traffic) read from the Redis session cache.

PostgreSQL stores two primary tables. The odds table holds current market prices with an odds_version counter that increments every time odds change. The bets table records every placed bet with the odds and odds_version at the time of placement. The database handles both reads (odds polling) and writes (bet placement) on a single primary instance with no read replicas. At 1,000 concurrent users, the odds polling path generates 333 read QPS while the bet placement path generates approximately 67 write QPS — the reads dominate and create the bottleneck.

Redis serves as a session cache for user balances and authentication tokens. It is not used for odds caching, which is the key architectural limitation of the naive approach. If odds were cached in Redis, the polling reads would bypass PostgreSQL entirely, but this adds cache invalidation complexity that the naive approach deliberately avoids.

Settlement is synchronous and single-threaded. When a sporting event ends, a cron job or manual trigger causes the Betting Monolith to query all open bets for that event, apply the outcome (win/loss), calculate payouts, and update each bet's status. This settlement loop processes bets sequentially — a popular event with 50,000 open bets takes minutes to settle, during which the monolith is partially occupied and has reduced capacity for live traffic.

The architecture has zero redundancy at the data layer. If PostgreSQL fails, both odds delivery and bet placement are unavailable. There is no deduplication mechanism for bet submissions — if a user's app retries a bet request (network timeout), two bets may be placed for one intended wager.

Vertical scaling only for PostgreSQL (upgrade instance size). Horizontal scaling for the Betting Monolith via pod count increase (3 → 6 → 12 pods). Auto-scaling trigger: CPU utilization > 70% for 3 consecutive minutes. Scale-down trigger: CPU < 30% for 10 minutes. The ceiling is approximately 3,000-5,000 concurrent users regardless of monolith pod count, because the database is the bottleneck. Beyond this ceiling, architectural changes are required (caching, streaming, or the V1 variant).

Key metrics to monitor: (1) PostgreSQL connection count and utilization — alert at 70% of max_connections, critical at 85%. (2) Odds polling QPS — track as N_users * 0.33 to predict database load. (3) Bet rejection rate by reason (ODDS_CHANGED, INSUFFICIENT_BALANCE, MARKET_SUSPENDED) — alert if ODDS_CHANGED exceeds 15% sustained. (4) Settlement duration per event — alert if settlement takes longer than 5 minutes. (5) Redis hit rate for session cache — should be >95%. Dashboard: Grafana with panels for live user count, odds polling QPS, bet placement QPS, rejection rate breakdown, DB connection pool usage, and settlement progress. SLIs: odds polling p99 < 200ms, bet placement p99 < 500ms, settlement completion within 10 minutes of event end.

At 1,000 concurrent users: PostgreSQL db.r7g.xlarge (~$350/month), Redis cache.r7g.large (~$150/month), ECS Fargate 3 pods (~$200/month), ALB (~$30/month). Total: ~$730/month. This is the cheapest variant but breaks down at 2-3K users. Scaling vertically to db.r7g.2xlarge ($700/month) extends the ceiling to ~5K users but does not solve the fundamental polling problem. The V1 Stream variant at 10K users costs approximately $2,500/month but handles 10x the load — the per-user cost actually decreases as you scale beyond the naive approach's ceiling.

Authentication: JWT tokens validated by the monolith on every request (~3ms overhead). Rate limiting: per-user bet rate limiting to prevent automated betting bots (max 10 bets/minute per user). Anti-fraud: basic velocity checks — flag accounts placing bets faster than humanly possible. Responsible gambling: deposit limits checked against Redis session data before bet placement. Self-exclusion: checked during login, not on every bet (optimization, but means a user who self-excludes mid-session can still bet until their session expires). Data privacy: PII (user_id, IP address) stored in PostgreSQL — compliance with GDPR/CCPA requires data retention policies and right-to-deletion support.

Rolling deployment for the Betting Monolith — replace one pod at a time while the LB routes traffic to remaining pods. Database migrations run during low-traffic windows (typically 4-6 AM local time) with a brief maintenance window. Redis cache is warmed after deployment by pre-loading active user sessions. Zero-downtime deployment is achievable for service updates but not for schema migrations that require table locks.