CASE 01
One season, built in phases
Real-time F1 analytics platform with predictive ML.
Formula 1 produces more telemetry per session than most companies produce in a year, and almost all of it is unreadable without tooling. QuantPrix ingests timing and telemetry feeds, models them into comparable stints and laps, and serves live race analysis with predictive strategy calls — under traffic that goes from nothing to peak in the ninety seconds before lights out.
THE PROBLEM
Race analysis worth reading requires joining timing data, telemetry, tyre state and weather in real time — and the raw feeds arrive as neither of those things.
The public data ecosystem gives you sessions, laps and car telemetry in separate shapes with separate cadences. Nothing in the raw feeds tells you that lap 34 was on used softs in traffic, which is the only version of a lap time that means anything.
Existing tools split into two camps: dashboards that show what already happened, and forums that argue about what might. Nothing that ran during a session and produced an actual prediction with a number attached.
Traffic is the shape of a race calendar. A platform that is comfortable on a Tuesday must survive a Sunday afternoon where every user arrives inside a two-minute window.
CONSTRAINTS WE WORKED UNDER
WHAT WE DID
Built an ingestion layer over timing and telemetry feeds that normalizes sessions, laps, stints and car channels into one comparable model.
Derived the context that makes a lap time meaningful — compound, tyre age, fuel-corrected pace, traffic — as first-class computed fields.
Trained predictive models for stint degradation and strategy outcomes, with confidence intervals on every projection.
Shipped a ⌘K-first interface so a driver, session or comparison is two keystrokes away, and cached aggressively so race-day traffic hits Redis, not Postgres.
ARCHITECTURE
01
Session, lap and telemetry feeds pulled on independent schedules and normalized into a common model — event, session, driver, stint, lap, channel sample. Each source has its own backfill path, so a feed that stalls catches up rather than leaving a permanent gap.
02
Fuel-corrected pace, tyre-age-adjusted degradation, traffic exposure and clean-air lap classification computed as materialized fields rather than at query time. This layer is the product: raw lap times are a commodity, comparable lap times are not.
03
Stint degradation and strategy-outcome models trained on historical sessions, retrained between race weekends, and served behind an inference API that always returns an interval alongside a point estimate.
04
During a session, updates flow through a short-TTL cache layer to the client on a fixed cadence. The frontend renders from a consistent snapshot rather than a stream of partial updates, so the picture is never half-updated mid-corner.
05
⌘K as the primary navigation, indexing drivers, sessions, circuits and comparison views. For an audience that already knows what it wants to look at, search beat menus decisively.
KEY DECISIONS
WHY
Fuel correction and degradation maths across a full session are expensive, and on a race Sunday thousands of people request the same numbers within the same minute.
TRADE-OFF
A recomputation pipeline to maintain, and corrections require a rebuild rather than a code change taking effect instantly.
WHY
Strategy is probabilistic. A single number invites the reader to treat a model as an oracle, which is exactly the failure mode that discredits analytics products.
TRADE-OFF
A busier interface and a harder explanation than a confident number would need. It is the difference between analysis and a horoscope.
WHY
The load curve is known in advance. Serving race-day reads from Redis makes the spike a cache problem instead of a database problem.
TRADE-OFF
Data is seconds behind rather than instantaneous, and cache invalidation became the most carefully written part of the system.
THE HARD PARTS
Sessions with red flags, aborted laps and timing corrections produce data that is internally inconsistent until it is revised. The ingestion layer treats every record as provisional until the session closes, then reconciles — which prevented a category of analysis that was confidently wrong.
Early versions compared raw times and produced nonsense: a lap in dirty air on old tyres against a fresh-tyre lap in clean air. Encoding tyre age, fuel load and traffic as explicit fields is what turned the data into analysis.
Load testing against average traffic proved nothing. Testing against a synthetic lights-out spike exposed a cold-cache stampede on session start, fixed with pre-warming ahead of scheduled session times.
HOW IT RAN
01
Normalized sessions, laps, stints and telemetry into one model, with backfill and reconciliation before any UI work.
02
Fuel correction, degradation, traffic classification — the layer that makes lap times comparable — validated against known races.
03
Degradation and strategy models trained on historical sessions, back-tested race by race, and served with confidence intervals.
04
⌘K interface, live session views, cache pre-warming, and load testing shaped like an actual race start.
OUTCOME
100×
Traffic swing between weekday and race day, absorbed
Interval
Every prediction served with confidence bounds
2 keystrokes
To any driver, session or comparison
Session-close
Reconciliation pass
Provisional data is never presented as final.
A live analytics platform that holds up during a race, not just after one — with predictions that state how sure they are.
The derived-metrics layer turned out to be the durable asset. Models change and interfaces get rebuilt; comparable laps stay valuable regardless of what sits on top of them.
Cache pre-warming against the published session calendar removed the single largest operational risk. Race starts stopped being an event for the infrastructure.
STACK
APPLICATION
DATA
MODELLING
OPS
HANDOVER
