125M Price Changes a Day: Inside FairPlay's Data Engine

The Scale That Separates Market Leaders From Everyone Else

"125M price changes a day" sounds like a marketing number. It's not. It's the difference between:

An odds feed that shows you 5 major leagues and updates every 10 seconds
An odds feed that shows you 50+ sports, 300+ leagues, and updates multiple times per second

It's the difference between:

A sportsbook that can offer basic markets (winner, over/under)
A sportsbook that can offer 200+ markets per event (player props, team props, live markets)

It's the difference between:

An odds feed with <5 sources (single-point-of-failure risk)
An odds feed with 50+ sources (built-in redundancy)

This isn't just throughput. It's the competitive moat that premium US sports publishers, La Gazzetta, and MARCA rely on.

This guide reveals what's inside the 125M number and why it matters.

What Exactly Is a "Price Change"?

First, let's define the metric precisely.

One "price change" = one market outcome's odds updated at a specific timestamp.

Example:

15:30:00.001 UTC: Manchester City's odds change from 1.95 to 1.94 = 1 price change
15:30:00.001 UTC: Draw's odds stay at 3.50 = 0 price changes
15:30:00.001 UTC: Liverpool's odds change from 3.25 to 3.26 = 1 price change
Total for that moment: 2 price changes

125M price changes per day = 1,450 updates per second on average.

But this metric hides the distribution. Let's break it down:

Distribution by Sport

Soccer (pre-match + in-play): 65% of volume = 81.25M
Soccer has the highest liquidity. Every match has dozens of
markets (winner, over/under, player props, in-play corners, etc.)

Basketball: 12% = 15M
Hockey: 8% = 10M
American Football: 7% = 8.75M (primarily Sunday + Monday nights)
Tennis: 3% = 3.75M
Other sports (cricket, rugby, volleyball, etc.): 5% = 6.25M

Distribution by Event Type

Pre-match (odds set 2-7 days before event): 20% = 25M
Steady updates as event approaches, slowly converging to fair odds

In-play (odds update during event): 70% = 87.5M
Rapid updates as match progresses, player gets injured, etc.

Post-match (odds after result known, settling): 10% = 12.5M
Updates as bets are settled, any delays resolved

Distribution by Time of Day (UTC)

00:00-06:00 UTC (Asia-Pacific peak): 25% = 31.25M
(Tokyo, Singapore, Sydney are awake)

06:00-12:00 UTC (Europe peak): 35% = 43.75M
(London, Germany, France peak betting hours)

12:00-18:00 UTC (Afternoon): 25% = 31.25M
(Overlaps US, Europe, and Asia morning)

18:00-00:00 UTC (US peak): 15% = 18.75M
(US evening, but Asia daytime not as liquid)

This distribution matters. Peak load is 3-5x average load. If average is 1,450 ups/sec, peak is 5,000+ ups/sec.

The Architecture Behind 125M Daily Changes

To process 125M price changes, you need to think about:

Ingestion: How do you consume data from 50+ bookmakers simultaneously?
Processing: How do you validate, aggregate, and enrich 125M pieces of data?
Storage: How do you store this volume without your database collapsing?
Distribution: How do you serve this to 100+ customers simultaneously?

Tier 1: The Ingestion Layer

FairPlay maintains live connections to 50+ bookmakers:

Tier-1 Bookmakers (respond < 100ms, continuous updates):
  Bet365, Betfair, DraftKings, FanDuel, Pointsbet,
  BetMGM, Caesars, DraftKings, BetRivers, Draftkings Sportsbook,
  etc. (15 bookmakers)

Tier-2 Bookmakers (respond 100-500ms, regular updates):
  Regional operators in Europe, Asia-Pacific, Latin America
  (25 bookmakers)

Tier-3 Bookmakers (respond 500ms-2s, pulled from webhooks or API):
  Smaller operators, niche markets
  (10 bookmakers)

Each connection streams odds asynchronously:

// Simplified pseudo-code showing parallel ingestion
func ingestOdds(ctx context.Context) {
  // 50 parallel goroutines, one per bookmaker
  for _, bookmaker := range bookmakers {
    go func(bm BookmakerConnector) {
      for {
        update := bm.GetNextOddsUpdate() // Blocks until update available
        ingestChannel <- update
      }
    }(bookmaker)
  }

  // Single aggregation loop processing all incoming updates
  for {
    select {
    case update := <-ingestChannel:
      processUpdate(update)
    }
  }
}

At peak (5,000 ups/sec), this ingestion layer maintains:

50 parallel connections
Each bookmaker sending 20-150 updates per second
Memory usage: ~500MB for buffer (with batching)
CPU usage: 1-2 cores (mostly I/O waiting)

Tier 2: The Processing Pipeline

Raw data from 50 bookmakers arrives out-of-order, sometimes duplicated, sometimes corrupted.

FairPlay's processing pipeline:

[Raw Bookmaker Updates]
    ↓ (Deduplication)
    └─ Remove duplicate updates from same source in last 50ms

[Normalized Format]
    ↓ (Validation)
    └─ Check: implied probs sum to ~100%
    └─ Check: odds movement is physical possible
    └─ Check: market state is valid
    └─ Check: timestamp is recent (not stale)

[Enhanced Odds]
    ↓ (Enrichment)
    └─ Add metadata: which bookmakers offer this?
    └─ Add derived data: implied probability
    └─ Add risk data: market exposure
    └─ Add compliance data: data provenance

[Aggregated Odds]
    ↓ (Quality Assurance)
    └─ Check: are we serving quality data?
    └─ Check: are latency SLAs met?
    └─ Check: is redundancy working?

[Published to Subscribers]

This pipeline processes 1,450 updates/second on average, peaks at 5,000/second.

Latency through pipeline:

Ingestion: 10-50ms
Deduplication: 1-5ms
Validation: 5-15ms
Enrichment: 2-8ms
Aggregation: 3-10ms
Publishing: 5-20ms
Total: 30-100ms

This means when a bookmaker changes odds, a subscriber receives the update within 30-100ms (plus network transit time to the subscriber).

Tier 3: The Storage Layer

125M price changes per day = 1,450 per second = 125 GB per day of raw data.

But historical data needs to be kept for 7 years (regulatory compliance):

125 GB/day × 365 days/year × 7 years = 320 TB of historical odds data

This can't all fit in a traditional relational database. FairPlay uses a hybrid approach:

Hot Storage (Redis)

Current odds for all active events
Size: 100-500 MB (depends on number of active sports)
Latency: <10ms
TTL: 1 hour (event closes, odds expire)
Cost: $5-10K/month

Warm Storage (TimescaleDB)

Recent odds history (last 30 days)
Size: 4 TB
Latency: 100-500ms
Queries: "What were the odds at 3pm yesterday?"
Cost: $10-20K/month

Cold Storage (ClickHouse + S3)

Historical data (30 days old to 7 years)
Size: 320 TB
Latency: 1-10 seconds (acceptable for historical queries)
Queries: "What was the closing line on this event 2 years ago?"
Cost: $2-5K/month (S3 is cheap for archival)

[Incoming Updates]
    ↓ (write to Redis)
    ↓ (async write to TimescaleDB)
    ↓ (batch write to ClickHouse every 1 hour)
    ↓ (archive to S3 every 24 hours)

When user queries:
  "Give me current odds" → Redis (10ms)
  "Give me odds from yesterday" → TimescaleDB (100ms)
  "Give me odds from 2 years ago" → ClickHouse (5 seconds)

Tier 4: The Distribution Layer

Now you have 125M price changes to distribute to subscribers.

Subscribers include:

Internal sportsbooks (owned by FairPlay)
Partner sportsbooks (premium US sports publishers, La Gazzetta)
Publishers (MARCA, sports news sites)
Risk management teams
Analytics teams
Regulatory bodies (in some jurisdictions)

Distribution happens via multiple channels:

Channel 1: WebSocket (Real-time subscribers)

~10,000 concurrent WebSocket connections
Each connection gets updates <200ms after they're published
Bandwidth: ~50MB/sec during peak (lots of small messages)
Cost: High (persistent connections require memory)

Channel 2: REST API (Polling subscribers)

~1,000,000 API requests per day
Latency: 5-30 seconds (depends on poll frequency)
Bandwidth: ~10MB/sec during peak
Cost: Low (stateless, scales easily)

Channel 3: Message Queue (Backend subscribers)

Kafka topics for each sport/league/market
100+ subscribers
Latency: 100-300ms
Bandwidth: ~20MB/sec
Cost: Medium

Channel 4: Batch Export (Compliance/Archive)

Daily exports to S3 for auditors and compliance
Files are gzip-compressed, reduce volume by 90%
Cost: ~$100-200/month storage

Peak distribution load: ~80MB/sec across all channels.

Why 50+ Sources Matters

"But couldn't you just use 3-5 major bookmakers?" people ask.

Technically yes. Practically, no. Here's why:

Reason 1: Coverage

Not all bookmakers cover all sports. For example:

Bet365 covers 50+ sports
DraftKings covers 15 sports (US-focused)
Betfair covers soccer, tennis, racing (niche focus)

Using only one bookmaker means your coverage is limited.

With 50 sources:

Soccer: 50 bookmakers offer it
Esports: 8 bookmakers offer it
Cricket: 5 bookmakers offer it
You can offer any sport where even one bookmaker offers odds

Reason 2: Geographic Reach

Bookmakers are licensed in different jurisdictions:

Bet365: UK, Germany, Italy, Malta (European)
FanDuel: United States, Canada
Betfair: Global but strong in UK/Australia
Regional Asian bookmakers: China, Japan, Singapore, India

Using only global bookmakers means missing regional markets.

Reason 3: Redundancy

If one bookmaker's feed goes offline:

With 5 sources: 20% of your coverage is gone
With 50 sources: 2% of your coverage is gone

This is the difference between:

99.9% uptime (acceptable)
99.99% uptime (enterprise-grade)

Reason 4: Liquidity

Some bookmakers specialize in specific markets:

Betfair: Best odds on horse racing
FanDuel: Best odds on US sports
Asian bookmakers: Best odds on cricket

Aggregating across all of them gives your users:

Better odds on average
Better odds on niche markets
Competitive advantage

The math:

1 bookmaker: Coverage = 40 sports, 100 leagues, 50 market types
5 bookmakers: Coverage = 60 sports, 200 leagues, 100 market types (some redundancy)
50 bookmakers: Coverage = 80 sports, 300 leagues, 200 market types, built-in redundancy

The more sources you aggregate, the more you can offer users.

Competitive Advantage: What 125M Daily Price Changes Actually Means

The 125M number isn't just scale. It's competitive advantage:

For Sportsbooks:

Offer 200+ markets per event (vs. competitors offering 50)
Have access to 50+ bookmakers' odds simultaneously
Know in real-time if your odds are out of line with the market
Can hedge your positions by seeing what competitors are offering

For Publishers:

Show the best odds available across 50 bookmakers
Update odds in real-time, not every 5-10 seconds
Display odds for niche sports (esports, cricket) that other publishers can't cover
Build credibility with users who see accurate, current odds

For Risk Management:

See market-wide trends immediately
Detect when you're over-exposed to an outcome
React to breaking news (player injury) faster than competitors
Model your position vs. the broader market

For Investors:

Understand the scale requirement: 125M changes/day requires industrial infrastructure
Recognize that competitors using "basic" data feeds (5-10M changes/day) are not competitive
See that FairPlay's infrastructure investment is the moat, not something easy to replicate

The Cost Structure

This scale requires serious infrastructure investment:

Engineering (R&D):

15-20 engineers dedicated to data infrastructure
Cost: $2M-3M/year

Infrastructure & Hosting:

4 data centers globally
High-performance compute, bandwidth, storage
Cost: $1.5M-2.5M/year

Data Partnerships:

Licensing odds from bookmakers
Payment for API access, bandwidth, support
Cost: $1M-2M/year

Operations & Support:

24/7 monitoring and on-call team
Customer support, integration help
Cost: $500K-1M/year

Total annual investment: $5M-8.5M per year

This is why:

FairPlay can charge $15K-50K/month to operators
Partners like premium US sports publishers and La Gazzetta trust FairPlay with their odds
Competitors struggle to match this scale

You can't build this with a 5-person startup. You need sustained capital and commitment.

The Engineering Reality: What It Takes

Building 125M daily updates isn't just about smart architecture. It's about sustained engineering commitment:

Daily Operations

On any given day at FairPlay:
  - 125M updates processed
  - 50+ live provider connections monitored
  - 4 data centers coordinated
  - 100+ operator customers served
  - 0 critical incidents (target)

If just one thing breaks:
  - Provider feed fails: Automatically switch to 49 others
  - Network latency spikes: Route through alternative paths
  - Database fails: Automatic failover to replica
  - One data center goes down: Traffic reroutes to 3 others

The system is designed so no single failure impacts operators.

Incident Response Speed

T=0: Monitoring detects anomaly (automated)
  - P99 latency jumped from 200ms to 1000ms
  - Error rate jumped from 0.1% to 1%

T=60s: On-call engineer paged (automated)
  - Alert goes to Slack, PagerDuty, phone

T=120s: Engineer starts investigation
  - Checks dashboards
  - Identifies: Bet365 feed is slow

T=180s: Mitigation deployed
  - Failover to secondary Bet365 connection
  - Or use aggregated odds from other sources
  - Monitoring confirms latency back to normal

T=300s: Root cause analysis begins
  - Why was Bet365 slow?
  - Network issue? Bet365 server issues?
  - What prevented this?

Result: Operators saw <30 second degradation (if anything)

The Roadmap: What's Next

The industry is moving toward even higher scale and lower latency:

In-Play Streaming

Today: 125M pre/match + in-play combined
Tomorrow: 500M+ mostly in-play (as more events are live-wagered)
Requires: Lower latency, faster updates, better real-time aggregation
FairPlay roadmap: Targeting 250M+ updates/day by 2027

Regional Disaggregation

Today: Global odds feed (one version for all regions)
Tomorrow: Region-specific odds (UK odds optimised for UK market, US odds for US, etc.)
Requires: Edge computing in each region, regional compliance handling
FairPlay roadmap: Regional customization layer in development

Predictive Odds

Today: Historical and current odds
Tomorrow: AI-predicted odds (forecast where odds will be in 5-10 seconds)
Requires: ML pipeline, real-time model serving, backtesting infrastructure
FairPlay roadmap: Experimental AI odds predictions for premium customers

Compliance Automation

Today: Audit logs for compliance review (manual)
Tomorrow: Automated compliance checking (odds flagged if they violate regulatory rules in real-time)
Requires: Regulatory database, automated rule checking, jurisdiction-specific logic
FairPlay roadmap: Compliance rule engine in beta (2026)

AI-Powered Arbitrage Detection

Today: Operators manually find arbitrage opportunities
Tomorrow: Automated detection and alerts when bookmakers are out of line
Requires: Real-time odds comparison, statistical analysis
FairPlay roadmap: Arbitrage detection tool launching Q3 2026

Vertical Breakdown: What 125M Means Across Sports

The 125M number breaks down differently by sport, revealing coverage depth:

Soccer (65M changes/day)

Data per day:
  - Pre-match matches: 5,000 events
  - In-play matches: 2,000 concurrent
  - Markets per match: 50-200 (winner, over/under, player props)
  - Updates per minute per match: 10-100 (depends on play)

Example timeline (single match):
  13:00 - Match starts: winner odds update every 5-10 seconds
  13:15 - First goal: 50 odds updates in 10 seconds (all markets repricing)
  13:30 - Player injured: 30 odds updates (affected markets repricing)
  14:00 - Goal disallowed (VAR): 100+ updates (goal removed from markets)
  44:45 - Half-time: Odds locked
  45:00 - Second half starts: Odds resume updating

One match generates 500-2,000 updates/day

Basketball (15M changes/day)

Lower update frequency than soccer (no continuous play like soccer)
- Updates happen when: score changes, timeout, substitution, injury
- Games have natural pauses (timeouts)
- Each update is more significant (fewer updates, more material changes)
- More prop markets (NBA is prop-heavy)

One game generates 100-300 updates

American Football (8.75M changes/day)

Very concentrated volume (games only happen certain times)
- Games Sunday 1pm-11pm ET, Monday evening, Thursday evening
- When games are live: very high update frequency
- When no games: almost zero updates

Sunday games: 10,000+ updates/second during afternoon window
Weekday: Almost zero updates

Tennis (3.75M changes/day)

Multiple matches in parallel but spread globally
- Matches last 1-3 hours
- Updates every 10-30 seconds (less volatile than soccer)
- Points are discrete events
- Challenge periods create volatility

One match generates 100-200 updates

Niche Sports (Other 6.25M changes/day)

Cricket, rugby, esports, volleyball, table tennis, etc.
- Each is 100K-1M updates/day
- Lower volume but expanding
- More coverage = more reasons for users to bet

The diversity is key: operators can offer 50+ sports because FairPlay aggregates 125M updates across all of them.

Moving Forward: Why Scale Matters

The sportsbooks and publishers winning in 2026 aren't winning because they have better UX or better marketing. They're winning because they have better data.

Better data means more markets to offer
More markets means more reasons for users to stay
More users means better position to negotiate with bookmakers
Better bookmaker relationships mean access to odds you can't get elsewhere

FairPlay's 125M daily price changes and 1.1B predictions are the infrastructure layer that makes this possible.

If you're evaluating a data provider, the question isn't "do they have odds data?" The question is "what's their scale? How many sources? What's their latency? Can they actually deliver what they claim?"

125M price changes daily—and the commitment required to maintain that—is a marker of serious infrastructure.

Related Articles: