> Markdown version of [/videos/100356-super-scaling-for-the-super-bowl-how-to-survive-30-million-users-hitting-your-backend-in-30-minutes?t=489](https://www.wearedevelopers.com/videos/100356-super-scaling-for-the-super-bowl-how-to-survive-30-million-users-hitting-your-backend-in-30-minutes?t=489). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Super scaling for the Super Bowl: How to survive 30 million users hitting your backend in 30 minutes

A Super Bowl ad triggered 100,000 requests per second. Auto-scaling was too slow. Discover how aggressive graceful degradation and load balancer sharding kept this Go backend alive.

- **Speakers:** [Irina Branovic](https://www.wearedevelopers.com/@irina-branovic)
- **Event:** World Congress 2026 Europe
- **Published:** July 10, 2026
- **Duration:** 35:13
- **URL:** https://www.wearedevelopers.com/videos/100356-super-scaling-for-the-super-bowl-how-to-survive-30-million-users-hitting-your-backend-in-30-minutes

## Summary

Ad tech platform adjoe faced a massive "thundering herd" problem when a partner secured a Super Bowl ad slot featuring a QR code. The event required their Go-based backend to instantly handle an influx of 100,000 requests per second (RPS), equivalent to processing one million users every 10 seconds. Standard AWS auto-scaling requires roughly five minutes to adjust to load—far too slow for a sudden, immediate broadcast impact—which forced the engineering team to architect a comprehensive pre-scaling strategy across their event-driven microservices.

Preparing for the surge required an exhaustive three-month testing phase, utilizing recorded production traffic patterns and the k6 Kubernetes operator to hammer test environments with instantaneous, un-ramped RPS spikes. The team utilized pprof for continuous Go application profiling and continuously monitored Grafana and CloudWatch to isolate breaking points. Surviving the traffic spike ultimately necessitated an aggressive philosophy of graceful degradation: the system designers entirely disabled third-party APIs, turned off secondary Redis click-deduplication logic, and completely detached their TensorFlow machine learning models just to guarantee core network survivability and deliver baseline responses.

Simulating extreme duress also brought several hidden infrastructure limits to light. DynamoDB throttled under massive load despite being switched to on-demand capacity and being actively pre-warmed; the volume of requests heavily targeted a single publisher ID, creating a "hot partition" that could only be circumvented by routing requests through a localized in-memory cache. Furthermore, standard AWS load balancers failed to process the raw inbound traffic volume, forcing the team to "shard" their load balancers across three separate IP addresses queried via Route 53. By prioritizing AWS quota increases, batching and compressing SNS and SQS messages, and temporarily paying the premium to move ECS instances from Spot to On-Demand blocks, the backend safely absorbed the global broadcasting wave without incurring downtime.

**Keywords:** golang backend scaling, thundering herd problem, aws auto-scaling limitations, k6 kubernetes load testing, dynamodb on-demand provisioning, dynamodb hot partition throttling, load balancer sharding, graceful service degradation, sns sqs event-based architecture, go continuous profiling pprof, super bowl traffic surge, in-memory caching strategies, aws quota limit management, ec2 spot to on-demand transition, instantaneous load spike testing

## Chapters

1. **Introduction to rewarded ad tech and platform business model** (00:07) — How the platform connects publishers and advertisers through an offer wall system.
1. **Baseline traffic scale and daily backend load** (05:27) — Handling six billion daily API requests and maintaining high throughput operations.
1. **Super Bowl traffic surge challenge and autoscaling limits** (06:30) — Preparing for an unprecedented spike of 100,000 requests per second driven by a live television QR code.
1. **Event-driven Golang backend architecture and cloud deployment** (08:09) — Examining the microservices stack utilizing Go, AWS spot instances, and event buses.
1. **Load testing production traffic with Kubernetes operators** (14:25) — Isolating external dependencies and hammering test environments to simulate sudden load spikes.
1. **Mitigating DynamoDB throttling with on-demand capacity mode** (20:20) — Switching to flexible capacity limits to handle abrupt database traffic bursts.
1. **Resolving DynamoDB hot keys using in-memory caching** (23:14) — Using CloudWatch insights to identify overloaded partitions and implementing local application caches.
1. **Sharding domain traffic across multiple AWS load balancers** (24:09) — Routing DNS through multiple IP addresses to prevent load balancer exhaustion.
1. **Profiling application performance to avoid out-of-memory errors** (25:20) — Identifying TLS handshake bottlenecks and disabling non-essential network dependencies to prevent crashes.
1. **Negotiating AWS concurrent service quotas to unblock scaling** (27:21) — Working with cloud providers to incrementally raise infrastructure limit caps during testing.
1. **Implementing graceful degradation and turning off machine learning** (28:03) — Batching queue messages and disabling real-time recommendation models to preserve core functionality.
1. **Switching to on-demand instances to guarantee resource availability** (30:32) — Abandoning spot instances before the event to ensure stable cloud compute capacity.
1. **Replicating production environments and utilizing comprehensive observability tooling** (32:42) — Leveraging observability metrics and production-like test environments to survive massive traffic events.

## Related Moments

- [Handling unexpected traffic spikes without proper load testing](https://www.wearedevelopers.com/videos/937-sleek-swift-and-sustainable-optimizations-every-web-developer-should-consider) (from "Sleek, Swift, and Sustainable: Optimizations every web developer should consider")
- [Overcoming traffic burst challenges in hyperscale web applications](https://www.wearedevelopers.com/videos/793-from-0-to-1-000-000-how-to-build-a-serverless-raffle-service-for-hyperscale) (from "From 0 to 1.000.000: How to build a serverless raffle service for hyperscale")
- [Managing high-traffic infrastructure without chasing technology hype](https://www.wearedevelopers.com/videos/1817-how-to-avoid-tech-hype-traps-josip-stuhli) (from "How to Avoid Tech Hype Traps - Josip Stuhli")
- [Best practices for implementing durable hyperscale serverless systems](https://www.wearedevelopers.com/videos/793-from-0-to-1-000-000-how-to-build-a-serverless-raffle-service-for-hyperscale) (from "From 0 to 1.000.000: How to build a serverless raffle service for hyperscale")
- [Surviving sudden scale events and malicious traffic](https://www.wearedevelopers.com/videos/1801-api-first-how-twilio-designs-for-developers-justin-kitagawa-twilio) (from "API‑First: How Twilio Designs for Developers - Justin Kitagawa (Twilio)")
- [Managing peak traffic via scalable content delivery networks](https://www.wearedevelopers.com/videos/97-headless-and-jamstack-the-state-of-commerce-today) (from "Headless and JAMstack - The State of Commerce Today")

## Related Articles

- [Dev Digest 103 - Superb Owl Trafficking](https://www.wearedevelopers.com/magazine/388-dev-digest-103-superb-owl-trafficking)
- [Making Data Warehouses Fast: A Developer’s Story](https://www.wearedevelopers.com/magazine/107-making-data-warehouses-fast-a-developer-s-story)
- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [Dev Digest 120 - Apple and peers](https://www.wearedevelopers.com/magazine/455-dev-digest-120-apple-and-peers)

## Related Jobs

- [Artificial Intelligence (AI)](https://www.wearedevelopers.com/jobs/ext/1952055-artificial-intelligence-ai) at **Twilio**
- [Staff Software Engineer](https://www.wearedevelopers.com/jobs/ext/1425755-staff-software-engineer) at **GitHub**
- [Software Engineer (L2) Segment Team](https://www.wearedevelopers.com/jobs/ext/238794-software-engineer-l2-segment-team) at **Twilio**
- [Software Engineer (L2) Segment Team](https://www.wearedevelopers.com/jobs/ext/209570-software-engineer-l2-segment-team) at **Twilio**
- [Senior Software Engineer, Data](https://www.wearedevelopers.com/jobs/48273-senior-software-engineer-data) at **Sportradar Media Services GmbH**
- [Principal Machine Learning Engineer](https://www.wearedevelopers.com/jobs/ext/1706410-principal-machine-learning-engineer) at **Almedia**