Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.

Update your browser
CapTech Home Page

Articles April 16, 2025

How ScoreSight Uses AWS To Generate Real-Time, Event-Driven Data For TGL

Steven Byle
Author
Steven Byle

For the past decade, sports leagues have been looking for ways to increase pace of play, engage younger audiences, create more action, and add personalization that ultimately enhances the fan experience. Golf has traditionally held tournaments that span several days with over a hundred players. For fans who are just looking to tune in for a couple of hours, it can be a challenge to sync timing with the on-course action.

TMRW Sports, led by Tiger Woods and Rory McIlroy in partnership with the PGA TOUR, saw this as an opportunity to create a fast-paced, tech-infused golf league called TGL presented by SoFi. Rather than play multiple rounds over a weekend with every man for himself, TGL teams go head-to-head in match play inside a stadium with a live audience, completing 15 holes in just two hours with every shot shown live in primetime. Competing golfers hit long shots into a simulator on a virtual course and then transition to a physical green that spins and reshapes its slopes to make every hole truly unique. TGL also introduces new gameplay mechanics such as timeouts and hammers, allowing teams to challenge their opponents to increase the value of a hole or forfeit the points.

No Smoke, No Mirrors

From a technology perspective, TGL created a unique set of constraints to address. TMRW Sports needed a scoring and stats data platform which could ingest, process, and publish data in real time. This solution needed to be able to serve the in-arena graphics displays and live TV broadcast as well as consumer-facing web and mobile apps behind a broadcast delay. Not only did this platform need to be fast, but it also had to be resilient enough to detect issues within seconds and support failover capabilities within the timeframe of a commercial break. Lastly, TGL needed a system to manage the league, its teams, players, and matches along with standings and stats.

Going Cloud-First with ScoreSight

Traditionally, other sports leagues combine a series of systems for administration, scoring, and fan consumption across on-prem and remote data centers. Being a brand new league, TGL’s arena was just a blueprint, and there was no existing data center. TMRW Sports partnered with CapTech to architect and ultimately build this new platform. Instead of managing a dispersed set of applications hosted across multiple locations, the CapTech team recommended that the scalability, resilience, and speed of Amazon Web Services (AWS) could support the fan experience inside the arena and across the world from a single data platform. This cloud-first solution, named ScoreSight, was designed for time and cost savings while enabling development and testing at production scale without any server procurement or management.



Technical Keys to Success

ScoreSight was built natively by CapTech on AWS to deliver speed and resilience while simplifying development and ensuring the platform is extensible and maintainable. It aligns with a core set of technical principles:

Event-Driven Architecture

Ingest, process, and publish data in real time, asynchronously getting data to consumers as fast as possible.

Choreography Over Orchestration

Use decoupled microservices that respond to events in a decentralized manner and don’t rely on a monolithic, all-knowing orchestrator, all while promoting modularity for future use cases.

Ledgered Database Design

Create immutable, chronological, versioned records of every data point to enable concurrent writes to a single record while avoiding collisions and providing a clear audit trail.

Cache Early and Often

Use write-through caching on every scoring data change and cache-aside caching for any cache miss to keep response times as fast as possible.

Design for Errors

Plan for human operators to make mistakes and allow for corrections; automate event error handling and retries; and gracefully degrade when systems fail by limiting dependencies between components.

Protect the Game

Keep data producers and in-arena consumers on private networks with isolated infrastructure from the public.

Serverless or Bust

Take advantage of cost-effective serverless services to support the bursts of match day traffic while limiting costs during down times.

Active-Passive Disaster Recovery

Operate from a primary system while replicating data to a standby system with the ability to rapidly failover.

Automate Everything, Minimize Human Error

Use infrastructure as code, database schema as code, CI/CD pipelines, automated testing, real-time monitoring and alerting, automated error handling, and script all support tasks.

Choreographing Event-Driven Flows

Building an event-driven architecture using choreography requires each event be clearly defined where event handlers are only aware of the events but not each other. This keeps the system loosely coupled while allowing event handlers to be mutually exclusive.

The most important thing about each event is that it represents something that has already happened, and it contains all of the resulting metadata which can be processed in a stateless manner. In the context of a TGL match, scoring and gameplay metrics need to be ingested as they happen, processed, and then published to be visualized. These three common phases of the data processing flow became the set of event archetypes for TGL: 

Data-Modified Events

Occurs when any source data is created, updated, or deleted. Examples include a simulator shot, scored stroke, team action, match progress, or hole score entity being modified.

Data-Computed Events

Triggered after consuming modified events and then computed by joining source data to represent holistic views of data for consumption and presentation. Examples include a combined stroke with simulator data, match box score, and match timeline being computed.

Data Egress Events

Triggered after consuming computed events and then abstracted to match API schemas; ultimately published to external event streaming platforms to enable applications to subscribe. Examples mirror the computed events.

The events by themselves do nothing — they are just messages that require event handlers to produce and consume to flow the data through the process. Choreographed event handlers act completely in parallel, independently from each other while only knowing the events to consume, what to process, and subsequent events to produce.

Lifecycle of Shots, Strokes, and Reconciliation

When a player hits a shot in TGL, the ball tracking systems and simulator capture a myriad of shot metrics, including the flight path, ball speed, spin rate, curve, starting and ending lies, distance to pin, and ball position coordinates. The game simulator sends this data to ScoreSight by calling APIs that store and publish the simulator shot events.

In parallel, a scoring operator tracks the golfer and their club selection, as well as when that golfer addresses, hits, and concludes a stroke using the Match Admin Console (MAC). The MAC, a custom scoring web app built by CapTech, also sends this data to ScoreSight by calling APIs that store and publish stroke events.

The game simulator and the MAC operate mutually exclusively so the order of operations cannot be guaranteed. Every stroke and simulator event are processed by pairing simulator shots to scored strokes which are stored and published as reconciled shot events.

From there, processing starts to fan out by recomputing the stroke, match progress, stats, and the match timeline, which each produce their own events. Finally, these events are published to consumers of ScoreSight, including the arena displays and broadcast graphics, along with private and public applications.

If Event Processing Fails, Does It Make a Sound?

All event flows happen automatically with handlers processing and publishing events in parallel. But if an event handler errs, these asynchronous flows will stop without any consumer application being notified. ScoreSight is charged with ensuring no data loss, meaning every event must be processed successfully.

When event handlers fail to successfully process an event, they publish those events to an Amazon EventBridge error event bus. These failed events are consumed by the Event Error Handler AWS Step Function, which delays with exponential backoff before publishing it back to the original event bus from which it was processed. Extra metadata is attached to the event so only the original event handler that failed to process is triggered to reprocess. If an event’s retry limit is reached, the step function stores the event in a dead letter queue (DLQ) using an Amazon DynamoDB global table, which triggers Amazon CloudWatch alarms. This stops automatic retries until the source issue can be resolved. The events in the DLQ can be retried later using an AWS Lambda that publishes back to the original event bus, restarting the entire process. This error flow allows ScoreSight to be resilient to intermittent environmental failures while avoiding data loss.

Human Errors Are Happy Path

TGL has technology everywhere but still requires human inputs from the golfers, scoring operators, referee, and rules officials. Human error is inevitable; maybe the wrong club is selected, a hammer is thrown but disallowed by the referee, or the scorer enters the wrong score on a hole.

ScoreSight is designed for scoring and stat corrections during and post-match. Any scored element can be corrected at any point in time. Scorers can either edit the scored entity or void it entirely. Voided entities still exist in the database but are not counted when computing scores and game state. They are also hidden from public consumers to prevent accidental display. Once an edit or void is made, the same event flows update the scores, stats, and any other impacted game state. The stateless nature of the score processing using ledgered database records allows for corrections to be made at any point in time.

Technical Architecture



ScoreSight’s architecture can be simplified to show how the data flows from left to right, where the system can be broken down into three distinct parts:

1. Ingestion – Scoring actions are tracked using the MAC, a React web app privately served by Amazon Elastic Container Service and Amazon S3. All scoring and game state data is ingested through private APIs hosted by Amazon API Gateway in order to handle the size of the simulator data payloads, which can be several megabytes. Clients authorize with APIs using OAuth 2.0 backed by Amazon Cognito, federating user authentication with Microsoft Entra ID. From there, AWS Lambda API handlers write data to a PostgreSQL global database cluster running on Amazon Aurora. Every write is ledgered with timestamped, immutable copies of every version allowing for append-only writes of each entity. After data is modified in the database, API handlers publish events to an internal event bus on Amazon EventBridge.

2. Processing – AWS Lambda event handlers use Amazon EventBridge event rules to subscribe as targets for the events they consume. These handlers then process events using stateless, idempotent functions given processing order cannot be guaranteed. Event handlers then either terminate or publish subsequent events back to the internal event bus which continues processing. As a new scoring game state is computed, event handlers update a write-through Redis OSS cache managed by Amazon Elasticache to minimize load on the database cluster.

3. Consumption – Clients can pull league, scoring, and stats data through public and private APIs on Amazon API Gateway. Public AWS Lambda API handlers enforce broadcast time delays on database reads while sharing a cache-aside Redis OSS cache managed by Amazon Elasticache. Clients can also subscribe to updates through Amazon EventBridge egress event buses or AWS IoT Core MQTT topics.

      Throughout each match, ScoreSight handles 2,500 scoring actions triggering 2,000 stat calculations, summing to over 5,000 total events being published and consumed.

      Resilient to Failures

      While TGL has a heavy reliance on technology, the show must always go on. This requires redundancies at every level. Effectively every piece of hardware and system in the TGL arena has one or more backups. The TGL arena is equipped with redundant network and power along with AWS Direct Connect. The cloud infrastructure for ScoreSight is no different; it’s built on serverless tools such as AWS Lambda, Amazon API Gateway, and Amazon EventBridge, which provide high availability along with automatic scaling out of the box. Amazon Aurora provides a global database cluster which replicates data to instances across AWS regions and availability zones. The entire cloud infrastructure for ScoreSight is built in an active-passive stance, with a primary region that handles traffic while replicating to a fully redundant secondary region in seconds. Since AWS CDK is used to manage all infrastructure, deploying to the secondary region only requires a separate regional configuration.

      If the active region becomes unhealthy, the active and passive regions can be swapped: 

      • Trigger a switchover or failover with Amazon Aurora to promote the secondary region to the writer and reverse the data replication to the opposite region.
      • Place a failover file in the Amazon S3 failover bucket in the secondary region. This inverse health check will trigger failover records in Amazon Route 53 to switch network traffic to the secondary region. 
      • Poll the global DNS records and database clusters’ status until both report healthy and active in the secondary region.

      The CapTech team scripted this process using the AWS SDK for Python, which can be run locally or through pipelines in under three minutes.

      Having a failover process is just half the solution. ScoreSight platform issues must be identified and communicated within 30 seconds. To monitor during live matches, ScoreSight uses Amazon CloudWatch dashboards and alarms triggered by processing failures, database CPU thresholds, latency thresholds, API failures, and absence of data ingestion, among others.

      To test the disaster recovery process, chaos testing was done during TGL test matches using the AWS Fault Injection Service to simulate partial and total failures across AWS services. By practicing these fire drills, the team was able to identify and address inefficiencies and gaps along with becoming well-rehearsed in the process.

      Built For TGL's Future

      The ScoreSight platform proved that a sole cloud-based solution built on AWS is fast enough, scalable enough, and resilient enough to meet and even exceed the demands of TGL’s live, televised matches. It was able to do this while staying cost-effective with extensive use of serverless services. The event-driven architecture implemented with microservices has created an extensible platform with modular components that can be swapped, improved, and added to as the league evolves over time.

      Related Insights