mika godts

For most fans, Mika Godts is a name on a start list or a result sheet. For engineers building sports technology, riders like him are mobile endpoints in one of the most interesting distributed systems on earth.

The next time you watch a rider cross the finish line, remember that the real race was won-or lost-in the data pipeline long before the cameras started rolling.

Every season, a professional cyclist produces millions of telemetry events: power output, cadence, heart rate, GPS traces - environmental readings, and biometric recovery markers. The platforms that store, transform and display those events face the same challenges as any high-scale SaaS product: schema drift, device fragmentation, unreliable networks, real-time fan expectations, and strict compliance rules. In this post, we will use the career data footprint of Mika Godts as a lens for discussing the architecture, observability. And engineering ethics behind modern endurance sports platforms.

From Race Results to Distributed Systems Architecture

Mika Godts's race results on sites such as ProCyclingStats and FirstCycling look like simple rows in a table. But they're actually materialized views of a complex event-driven architecture. At the source, timing transponders on the bike send radio-frequency identifiers to loop antennas buried in the road. These events hit a message broker, are enriched with UCI rider identifiers, then flow into ranking APIs, broadcaster graphics engines, and fan-facing mobile apps.

From an engineering standpoint, a rider is a long-lived entity with a unique identity, a history of state changes. And a stream of time-ordered events. The system has to handle idempotency carefully: the same finish-line crossing must not create duplicate stage results if a transponder bounces. Exactly-once semantics, or at least idempotent consumers, are non-negotiable when prize money - UCI points. And sponsorship contracts depend on the outcome.

When the timing system records mika godts crossing the line, that single event fans out to dozens of downstream consumers. If any one of them fails, the athlete's public ranking becomes inconsistent that's why the most successful sports data platforms treat race results like financial transactions: durable, auditable. And replayable from a source-of-truth log. Read our guide to event sourcing for competitive rankings

Edge Devices That Capture Every Pedal Stroke

Before a result ever reaches the cloud, it starts at the edge. Riders such as mika godts train with power meters, heart-rate straps, cadence sensors, and a GPS head unit from manufacturers such as Garmin, Wahoo, or SRM. These devices talk to each other over ANT+ and Bluetooth Low Energy (BLE), both of which publish standardized device profiles so a Garmin Edge can read a Stages power meter without custom pairing logic.

The dominant file format is FIT, the Flexible and Interoperable Data Transfer protocol originally developed by Dynastream and now maintained by Garmin. A FIT file is a compact binary format that records messages, fields. And developer extensions. In production environments, we found that parsing FIT files at scale is surprisingly tricky: manufacturer-specific fields change between firmware versions, timestamps can drift across devices. And corrupt files from a crashed head unit must be recovered without losing an entire training camp's data. We solved this by buffering raw uploads to object storage, parsing defensively with the Garmin FIT SDK. And versioning our message schemas the same way we version API contracts.

For constrained sensors that don't use ANT+, the Constrained Application Protocol (CoAP) defined in RFC 7252 can be a lighter alternative to MQTT over TCP it's rarely seen on consumer bike computers today. But it's worth knowing if you're building custom environmental or load-cell sensors for a team. Read our teardown of edge protocols in endurance sports

Building Telemetry Pipelines for Endurance Athletes

Once an activity file leaves the edge, it enters a telemetry pipeline that would be familiar to any data engineer working with IoT fleets. The typical path is: head unit upload via Bluetooth or Wi-Fi to a mobile app, mobile app upload to an API gateway, gateway writes to object storage. And an event triggers an ETL job. We have orchestrated these jobs with Apache Airflow and Dagster; others use AWS Step Functions or GitHub Actions for smaller teams.

The normalization layer converts FIT, TCX, and GPX into a common schema. We store the cleaned data as Parquet in a data lake and register it in a table format such as Apache Iceberg or Delta Lake so that downstream queries can time-travel. For mika godts, each race or training file becomes a partition keyed by athlete ID, activity type. And start timestamp. This design lets coaches query Chronic Training Load over the last six weeks while analysts can rebuild historical fitness curves without reprocessing raw files.

A hidden complexity is privacy and consent, and heart-rate variability - sleep scores,And power profiles are sensitive health data under GDPR. The pipeline must tag each record with consent status, retention policy, and jurisdiction. We learned to enforce these tags at ingestion rather than at query time; retrofitting privacy controls onto a data lake is expensive and error-prone. Explore our GDPR-by-design data lake checklist

Real-Time Analytics During a Cycling Season

A cycling season is a long-running time-series problem. Coaches manage fitness using Training Stress Score, Chronic Training Load, Acute Training Load, and Training Stress Balance. These metrics are cumulative rolling averages, which makes them a natural fit for time-series databases such as InfluxDB, TimescaleDB, or Prometheus paired with a long-term store.

We have instrumented athlete dashboards with Grafana and Alertmanager. One rule we found valuable: flag any week-over-week Chronic Training Load ramp greater than five to eight points, because research and practical experience show that faster ramps correlate with illness and injury. For a rider such as mika godts, these alerts are analogous to SRE burn-rate alerts; they don't tell the coach what to do. But they signal that the system's error budget is being consumed faster than planned.

Real-time analytics also extends to race day. Live power and GPS feeds from riders are ingested via mobile networks or race moto receivers and visualized in second-screen apps. Latency here is measured in seconds. And fan expectations rival those of financial trading dashboards. Caching partial aggregates in Redis and using WebSockets for push updates keeps the experience responsive even when cellular coverage on a mountain pass is spotty. See our guide to low-latency sports dashboards

Observability and Reliability in Sports Platforms

Observability for sports platforms mirrors observability for any SaaS product, except the stakes include an athlete's career. You need traces for request latency, metrics for pipeline throughput, and logs for debugging why a file failed to parse. We use OpenTelemetry across our ingestion services and export to Jaeger for traces and Prometheus for metrics.

Race-day reliability deserves its own runbook. During a major stage race, we once saw a streaming API collapse under a 40x traffic spike because a popular rider attacked on a climb. The fix wasn't more CPU; it was a circuit breaker, aggressive CDN caching. And a fallback to precomputed leaderboards. Live leaderboards for riders such as mika godts can't afford to stall during a decisive moment, so the engineering plan must assume viral traffic spikes.

Service-level objectives matter here too. A reasonable SLO for activity upload might be 99. 9% success with a p99 parse latency under two seconds during business hours. For live telemetry, the SLO might be end-to-end latency under five seconds for 99% of messages. These numbers give teams a common language when tradeoffs arise, such as accepting a small data delay to preserve correctness. Download our SLO template for sports technology teams

Machine Learning Models for Performance Forecasting

Machine learning enters the picture when coaches and analysts ask predictive questions: Can this rider finish in the top ten on a hilly course? What is the probability of overtraining in the next two weeks? The features are rich: normalized power, variability index, time in power zones, weather, course elevation, fatigue metrics. And historical results. We have trained gradient-boosted models with XGBoost and LightGBM, validating with time-series cross-validation to avoid lookahead bias.

The challenge with a single athlete such as mika godts is data sparsity. Even a full season might only contain fifty to eighty meaningful race or training observations. A model trained only on individual history will overfit. The practical fix is hierarchical modeling: share population-level parameters across similar riders while allowing individual random effects. Tools such as PyMC or Stan make this feasible. But the engineering cost is higher than a simple tabular model.

There is also an interpretability requirement. Coaches won't trust a black-box prediction if it contradicts their experience. SHAP values and partial dependence plots help explain why the model thinks a taper week should be shorter. In our experience, the best ML deployment in sports is one that augments human judgment, not replaces it. Read our case study on hierarchical models for athlete performance

Identity Verification and Anti-Doping Data Integrity

Professional cycling has some of the strictest data integrity requirements in sport. Athletes must keep whereabouts updated in ADAMS, biological passports track longitudinal biomarkers. And test results must have an unbroken chain of custody. Engineering teams building compliance automation for this domain need identity verification, immutable audit logs, and cryptographic proofs.

The architectural pattern is familiar: a user identity from an OAuth provider links to an Athlete Biological Passport record; each sample is signed at collection; results are written to a tamper-evident log. We have implemented similar flows using OpenID Connect, HashiCorp Vault for key management. And Merkle-tree-based audit logs. The WADA technical documents and the International Testing Agency guidelines define the business rules. But the implementation is pure software engineering.

Data minimization is also critical. A platform shouldn't store raw location history longer than necessary for anti-doping purposes. And access must be role-based with just-in-time approvals. When an athlete profile such as mika godts appears across results sites - training platforms. And federation portals, each system must reconcile the same person without over-collecting data. Check our guide to identity architecture for regulated sports platforms

Media Delivery and Global Race Broadcasting

Fan-facing sports technology is ultimately a media delivery problem. Whether mika godts is racing a cyclo-cross World Cup or a spring classic, broadcasters deliver video through camera bikes, helicopters, fixed cameras. And drones. The feeds traverse RF links to production trucks, then hit the internet via CDNs using HLS or DASH. Latency, geofencing, and digital rights management become first-class engineering concerns.

Second-screen experiences add another layer. Apps want live power, speed, position, and heart rate synchronized with video. That synchronization requires timecode alignment between telemetry streams and broadcast feeds, often using NTP or PTP, plus buffering strategies to smooth network jitter. The W3C Geolocation API provides browser and mobile access to position data, but for pro racing the authoritative source is usually a dedicated GPS tracker rather than the viewer's device.

Geographic restrictions add compliance complexity. A broadcast rights holder may allow live video in Belgium but only highlights in another region. Implementing these rules at the CDN edge using Varnish or Cloudflare Workers reduces origin load and improves user experience. Engineers must also handle cache invalidation when rights change mid-race. Which is one of those problems that sounds simple until you're doing it under load.

Engineering Lessons from Elite Cycling Data

Stepping back, what does a rider like mika godts teach us about building better software? The lessons are concrete and reusable:

• Design for offline-first edge behavior. A training ride in the mountains has no guarantee of connectivity; the device must store data locally and sync when possible.
• Version your schemas. Fitness file formats evolve, and downstream dashboards break when a firmware update adds a new field.
• Separate raw ingestion from normalized analytics. Keeping the raw FIT file means you can reprocess history without asking the athlete to re-ride a training camp.
• Embed privacy and consent in the data model. Retrofitting GDPR controls onto a data lake is expensive and risky.
• Treat observability as a product feature. Coaches, fans, and anti-doping authorities all need timely, accurate, and explainable data.

Mika godts's public data footprint is small compared with the telemetry generated behind the scenes. But it's a reminder that the engineering team that ships reliable infrastructure enables every other role in the sport. The same patterns apply to logistics, healthcare, field service, and any other domain where humans generate data while moving through the physical world.

Frequently Asked Questions About Cycling Telemetry

What file format do cycling computers use?

Most use FIT, which stands for Flexible and Interoperable Data Transfer it's a compact binary format originally developed by Dynastream and now maintained by Garmin. FIT supports activity records - lap markers, events, and developer-specific fields. The Garmin FIT SDK provides official parsers and message definitions.

How do professional teams calculate training load?

They use power-based metrics such as Training Stress Score, Chronic Training Load, Acute Training Load. And Training Stress Balance. These are rolling averages computed from normalized power, ride duration,, and and intensity factorCoaches track them in tools like TrainingPeaks, WKO5. Or custom dashboards backed by time-series databases.

Which wireless protocols connect sensors to bike computers?

ANT+ and Bluetooth Low Energy are the two dominant protocols. ANT+ has long dominated dedicated cycling sensors because of its low power and standardized device profiles. BLE is common on newer devices and smartphones. Both rely on profiles for power, cadence, speed, and heart rate.

How is live race data transmitted to fans?

GPS and telemetry trackers on riders or motos send data via RF or cellular links to race operations. The data is then distributed to broadcasters and second-screen platforms over CDN-backed HLS or DASH streams. Time synchronization and low latency are the main engineering challenges.

Why does anti-doping software need immutable audit logs?

Test results, sample custody records, and whereabouts updates must be tamper-evident. Immutable logs provide cryptographic proof that records weren't altered after creation, which is essential for fair hearings, regulatory compliance. And public trust in the anti-doping system.

Closing the Loop on Sports Technology

Mika Godts may be the public face of his results, but behind every finish-line photo is a stack of edge sensors, data pipelines, analytics platforms, and compliance systems. Engineers who build this infrastructure aren't supporting the sport from the sidelines; they are part of the competitive fabric that makes modern professional cycling possible.

If you're designing telemetry platforms, start with reliability at the edge, schema flexibility in the pipeline. And observability end-to-end. Audit your consent model, test your race-day failover runbooks. And treat every athlete's data with the care you would expect for your own production database. Want a practical next step? Review your current architecture against the patterns above and identify one data flow that would break under a viral race moment. Subscribe to our engineering newsletter for more sports technology deep dives

What do you think?

Should professional athletes own their raw telemetry data,? Or should teams and platforms retain control for competitive and commercial reasons?

Which infrastructure layer in professional cycling is most under-invested today: edge device reliability, real-time analytics, or anti-doping data integrity?

Can machine learning models trained on population-level cycling data ever make reliable career predictions for an individual rider, given the sparsity of personal observations?