AWS for M&E Blog
Real-time storytelling: The AWS architecture behind Formula 1® Track Pulse
On a FORMULA 1® (F1) race day, broadcasts face a significant challenge: identifying the most impactful stories for fans amidst the complex, fast-paced action on the track. F1 cars generate 1.1 million telemetry data points every second, from 300 sensors on each of the 20 race cars. Helping production teams quickly pinpoint and narrate the most interesting events unfolding during a race is a key issue.
To address this challenge, F1 and Amazon Web Services (AWS) developed Track Pulse, a serverless architecture solution that transforms raw racing data into real-time, actionable broadcast insights. The system monitors critical race developments including sudden pace changes, new fastest laps or sectors, extended tire stints, and weather shifts. Track Pulse consolidates multiple data feeds into a single interface, automatically detecting and highlighting significant racing moments. The F1 production team can then quickly identify and present key storylines to their global audience of more than 820 million fans.
Figure 1: User interface view of the Track Pulse application.
The screenshot of the application (Figure 1) shows how Track Pulse provides the F1 production team (and in the future, broadcasters) a data-rich view of the race. The interface displays real-time driver gaps, timing data, tire strategies, leaderboards, and driver communications. Producers and broadcasters can spot emerging battles and key radio communication instantly. By combining vast amounts of data, Track Pulse helps transform complex race data into compelling narratives for viewers.
Figure 2: Detailed view of a big catch story.
Figure 2 shows the Track Pulse driver comparison view, showcasing side-by-side performance data. It highlights each driver’s position changes, fastest lap times, tires over time, and live team radio transcripts, giving the production team rich context to tell the story of their on-track battle.
How Track Pulse works
The data is gathered at the race location and sent to the F1 Media & Technology Centre (M&TC), which hosts a data center, and is passed through to the F1 data hub. From there, a data stream is forwarded to AWS for further processing, making use of AWS analytics, storage, databases, compute, application and security capabilities.
The core components of Track Pulse, hosted on AWS, are a web application with authentication and federated single sign on (SSO). It uses container-based serverless compute for the data provider and story generator logic. It contains a message queue for communication between the data provider and the story generator, with a database for storing data with low latency data serving. There is also a real-time data synchronization service for efficient querying and subscription to database changes, as well as Apache Velocity Template Language (VTL) resolvers to send real-time updates to the frontend web application.
As shown in the architecture (Figure 3), the data provider listens to raw data feeds, parses and saves the raw data to a database, and sends processed data in the expected format through the message queue to the story generator. The data is forwarded and used in the story generator. This includes timing and sensor data, as well as radio and race control messages. The story generator then processes, aggregates, and analyses the data to provide meaningful insights to users in the form of stories.
The stories are determined by specified criteria and thresholds. They are subsequently prepared and stored in a database, which then is used to serve the frontend, where users receive the stories in real time. Users can also set filters, including story type or a focus on specific drivers.
An example of how the story generator works can be explained by the catching story type, which is released when drivers are catching up to each other during a race. The story generator continuously monitors the gaps between cars and identifies two main stories:
- Catch stories: When one driver is steadily gaining on another, but at a moderate pace
- Big Catch stories: When one driver is rapidly closing the gap to the car ahead at a significant rate
The story generator updates the gap values between drivers on the track continuously—calculating and assessing whether situations are intensifying or changing. The generator can highlight when a new battle is emerging or when an existing battle enters a new phase.
Figure 3: High-level functional view of data flow.
Implementation
Track Pulse implements an event-driven architecture with clear separation between data ingest, processing and delivery layers. The architecture follows various microservice patterns to enable independent scaling and deployment of components. This setup is illustrated in Figure 4, which provides an overview of the AWS architecture.
Figure 4: AWS Architecture overview.
Data provider pipeline
F1 data flows through a websocket connection to the data provider service running on Amazon Elastic Container Service (Amazon ECS). This service handles the high-velocity stream of racing data and transforms it for downstream processing. The data provider publishes processed messages to Amazon DynamoDB and to the Amazon Simple Queue Service (Amazon SQS) queue. This messaging layer decouples data ingestion from story processing, allowing each component to scale independently based on race weekend workload demands.
Story generator architecture
The story generator represents the core intelligence of the system, implemented as a Python application with asynchronous processing capabilities. The application architecture divides into three distinct subsystems:
- Input system: Manages Amazon SQS queue subscriptions and message routing. Each message type triggers specific story processors based on data content and event classification.
- Rule engine: Contains F1-specific business logic for story generation, including threshold-based rules for lap time improvements and contextual analysis algorithms for championship implications. It also includes priority scoring mechanisms that consider race position, driver standings, and strategic significance. Rules determine whether racing events meet the criteria for story creation and assigns importance levels based on their impact on potential race outcomes.
- Output system: Handles story persistence to Amazon DynamoDB and triggers real-time notifications through AWS AppSync mutations, confirming generated content reaches client applications with minimal latency.
Real-time delivery mechanism
AWS AppSync provides the real-time delivery layer using GraphQL subscriptions. Client applications subscribe to story updates and receive new content immediately upon generation. VTL resolvers handle data transformations and trigger subscription notifications when stories are created or updated in DynamoDB.
Implementation details
Both the data provider and story generator run as containerized applications on Amazon ECS using an AWS Fargate launch type. Amazon ECS service definitions include health checks, automatic restart policies, and integration with Amazon CloudWatch for monitoring and logging. Blue-green deployment strategies provide zero-downtime updates during application releases.
Amazon SQS First-In-First-Out (FIFO) queues provide ordered and deduplicated message delivery between system components, enabling consistent communication in story generation workflows. Queue configuration includes dead letter queues for handling processing failures and visibility timeout settings optimized for story processing latency requirements. Message attributes enable routing logic within the story generator for directing different data types to appropriate processors.
The story generator features a modular architecture that dynamically registers story processors at startup based on naming conventions. Each processor independently handles specific racing events, enabling parallel and asynchronous processing of multiple story types.
Amazon DynamoDB stores generated stories and historical statistics with single-digit millisecond latency. The data model accommodates varying story, timing and metadata structures while maintaining consistent query performance. DynamoDB Streams integration triggers AWS AppSync mutations when stories are created or updated, enabling real-time delivery to subscribed clients without additional polling mechanisms.
Conclusion
We discussed how F1 and AWS engineered Track Pulse, an innovative real-time broadcast insights system that transforms complex racing data into compelling narratives. By processing data in real time, Track Pulse helps production teams identify and present key storylines to the F1 global audience of more than 820 million fans.
The solution implements a serverless architecture that seamlessly connects data to AWS cloud infrastructure. Through its core components (including the data provider, story generator, and real-time delivery mechanism) Track Pulse automatically detects and highlights significant racing moments. These moments include emerging battles, pace changes, strategic developments, and critical radio communications.
Looking ahead, Track Pulse represents a foundation for even more advanced production and broadcasting innovations. The system’s modular architecture and integration with AWS services positions it well for future enhancements. This includes potential applications of generative AI to create even richer narrative insights and automated commentary assistance.
To learn more about the partnership between AWS and FORMULA 1, and how we’re transforming the future of racing entertainment through technology, visit F1 on AWS. Or contact an AWS Representative to know how we can help accelerate your business.