Content delivery: from 30–60 seconds to 30–60 milliseconds.
At Fanatics Betting and Gaming, an eight-engineer team I led replaced the service that carries most of the sportsbook’s client data traffic. The old GraphQL service had regular outages and took 30 to 60 seconds to respond. The new REST-based service responds in 30 to 60 milliseconds, roughly a thousand times faster.
- Role
- Senior Engineering Manager, Fanatics Betting and Gaming (March 2023 – September 2026)
- Team
- Eight distributed-systems engineers: one senior staff, two staff, and five engineers, working in step with the mobile client team
- The service
- The layer between the sportsbook’s data services and its clients, which carries most client data traffic
- Before
- A GraphQL service with regular outages and latency of 30 to 60 seconds
- After
- A REST-based service that runs at 30 to 60 milliseconds
- Design
- REST with heavy caching and preloading, deployed as several copies of the same service, one for each section of the mobile app
- Result
- No production incident in more than six months, and no issues on Super Bowl traffic
- Technology
- Java, Kotlin, PostgreSQL, AWS, Datadog, Terraform, and FireHydrant, across the role
Most client traffic ran through a slow, unreliable service.
The content delivery service sits between the sportsbook’s data services and its clients, so most client data traffic passes through it. The GraphQL service that filled that role had regular outages and latency of 30 to 60 seconds. It offered clients too much data, it connected directly to the upstream services with no caching and no failsafe, and its overall performance had been neglected.
The content management system that feeds it was also slow and error-prone, and it had little validation.
Replace it one endpoint at a time.
The replacement was a REST-based service. REST was the easiest protocol for the mobile engineers to consume, and its structured, predefined data and queries let the service rely heavily on caching and preload data in anticipation of load. The GraphQL service had no caching.
The service was also deployed as several copies of the same code, so that each section of the mobile app talks to its own dedicated service. That spreads the load, and it keeps any problem to a single page or function of the app.
The team moved the service over one endpoint at a time, in step with the mobile client team, who updated the app as each endpoint moved, so there was never a single high-risk cutover. It is the working principle from my home page applied to a migration: reliability and release confidence are engineering products in their own right.
About 30 endpoints moved over roughly nine months, and upgrades and feature enhancements were part of that effort. Every endpoint was behind a feature flag, so any of them could be rolled back with a toggle.
Eight distributed-systems engineers, each with a defined part.
All eight engineers were distributed-systems engineers. One senior staff engineer proposed most of the design and the proofs of concept. Two staff engineers implemented and refined the designs and structures. Five engineers specialized in segments of the service, and typically partnered with upstream services and teams.
I led the team and worked with the mobile client team, whose app updates had to land in step with each endpoint. I also built the monitoring and quality systems around the service and the content management system that feeds it, and I met regularly with product and program partners to align on priorities and report progress.
Across my time at Fanatics, four people on my team were promoted, including one who moved into engineering management, and only one left the company by choice.
The mobile client team and the distributed-systems team had a close and friendly working relationship.
Every endpoint gets standard monitoring.
I built more than 200 monitors programmatically with Terraform. A templating framework gives every new endpoint and service a standard set covering latency, error rate, memory, CPU, and SLOs with minimal configuration. Alerts go to Slack, and P1 incidents page automatically through FireHydrant. Because coverage comes from the template, every new endpoint starts with the same monitors.
The content management system that feeds the service was replaced as well. It was built with guardrails and validation from the first day, so the content that editors add is accurate and usable by the client.
Faster, and steadier.
faster responses: latency fell from 30–60 seconds to 30–60 milliseconds.
without a production incident on the new service.
traffic, one of the year’s highest-traffic days, handled without issues.
Terraform-generated monitors covering latency, errors, memory, CPU, and SLOs.
Looking back, I would push back harder on including major enhancements and new features in the migration. In some cases a feature reached production sooner, but the extra change added risk and made rollbacks more complicated.
More from the same role.
- ExperienceThe full role at Fanatics Betting and Gaming, and the roles before it.
- Bug ManagerThe agentic bug-management workflow I built at the same company.
- Sprint LedgerThe engineering-management dashboard behind the team-outcome numbers.