Problem
Telemetry and race data are high-volume, session-dependent, and difficult to use consistently without a clean data backbone. The goal was to move from ad-hoc analysis toward reusable storage, processing, and API access.
Project case study
F1 Telemetry API & Data Platform
A structured data backbone for processing, storing, and exposing Formula 1 telemetry, lap, weather, and session data for analysis, modelling, and dashboards.
Why it matters
Predictive modelling and dashboards need reliable underlying data systems. This project focuses on the engineering layer that makes later ML and analysis work easier to reproduce, extend, and integrate.
Project flow
A simplified view of how the project moves from data and domain logic to usable outputs.
1. Fetch data
— sessions, laps, telemetry, weather, drivers, and contextual race data
2. Process data
— clean, normalize, and structure data across seasons, events, and sessions
3. Store data
— PostgreSQL-ready schema and structured tables for later analysis
4. Expose data
— API-oriented design for models, dashboards, and analysis tools
5. Analyse data
— driver behaviour, telemetry trends, tyre degradation, and strategy inputs
Data handled
- Lap-level data
- Car telemetry
- Weather data
- Session metadata
- Driver and stint information
Technical focus
- Python data pipelines
- PostgreSQL storage
- API-oriented architecture
- Reusable modules
- Extensible project structure
What it demonstrates
- Data engineering mindset
- Backend/API thinking
- Working with time-series data
- Modelling-ready data design
- Production-minded structure
What I learned
This project helped me move from analysis scripts toward reusable data infrastructure. It made it clear that good ML work depends heavily on clean, accessible, well-structured data.
Next steps
Useful improvements would include API documentation, automated tests, Dockerized deployment, stronger validation checks, dashboards, and model-serving endpoints for predictions and strategy simulations.