So your boutique dev shop needs to handle Super Bowl ad traffic?
Tags: webdev, webperf
Published: 2018-02-05 17:47:13

---
title: So your boutique dev shop needs to handle Super Bowl ad traffic?
published: true
description: You may remember the Lumber 84 debacle from last year.
tags: webdev, webperf
cover_image: https://static01.nyt.com/images/2018/02/04/sports/football/SUPERLIVE-clement3/superbowl-ben-solomon-228-superJumbo.jpg
---

Yesterday was the American tradition of eating much food and watching the New England Patriots play football, oh and of course, the commercials!

{% tweet 960266710820540418 %}

Super Bowl commercials are known for their entertainment value. They get a lot more attention than your typical ad. And in the dev world, mass consumer attention goes hand-in-hand with scaling up for a lot of traffic!

You may remember the Lumber 84 debacle from last year. The company created a touching video with a call-to-action to visit the website for more. It has been a year and I don't want to bring up old wounds for those involved, but it's a good case study.

{% youtube J0Uk6ctu7nI %}

Perhaps they had no idea how successful it would be, but when America flocked to their site, it was hugged to death almost immediately.

![](https://thepracticaldev.s3.amazonaws.com/i/dn6q145hlsh0pd5wu7js.png)

The site was built to handle [150,000 requests per minute](http://adage.com/article/super-bowl/84-lumber-made-a-statement-website-crashed/307870/) and was not even close to being able the traffic. Needless to say that this was a less-than-ideal outcome for those involved.

We know in hindsight that mistakes were made, but getting this right is easier said than done because of the types of expertise involved does not always line up properly. The organization tasked with creating this ad experience was not a scaling-specialized company like Google, Amazon or Netflix. It was agency. Their specialty is pop-up experiences. Usually a Wordpress site that goes along with a video and social media campaign. They simply are not an engineering-driven organization.

An easy answer for an agency like this is to modify the type of expertise they have in-house or to hire out for bring in specialists for projects like this. But those answers are easy to dole-out in hindsight. I'll offer some tips for thinking scale as a shop that might not have the lead time or budget for that approach.

## Know the services that will help

An agency like this would deal with scale not by raw engineering, but by understanding which services to plug into. There is no reason that the landing page needs to be served directly by servers that have any kind of capacity limit. Knowing how to plug in and serve an entire page via Content delivery network (CDN) is essential here.

There are a lot of great CDN services. We use [Fastly](https://www.fastly.com/) at the moment, but [Cloudflare](https://www.cloudflare.com/), [Cloudfront](https://aws.amazon.com/cloudfront/) and others will do the trick. I think [Netlify](https://www.netlify.com/) is a service shops should absolutely have awareness of as well. Use these services well and almost all scaling concerns will be outsourced to the wonderful engineering by these specialists. 

In addition to the CDN, there continue to be emerging services that handle massive scale when necessary. [AWS Lambda](https://aws.amazon.com/lambda/) and other cloud services rolling out every day give specialized opportunities to avoid the need to worry about big scale. Keep an eye on what is available, but don't use what you don't need (more on that later).

## Accept constraints

It's usually a few little things that make scaling these kinds of pages hard. Serving all of your HTML and assets from a CDN will inherenyly come with design constraints. You may want to serve but accepting them is a great way to go. Chances are you don't _need_ that super specialized feature on your heavily-trafficked landing as much as you need to avoid downtime. Explaining what a client can and cannot have in their ideal vision should already be a core-competency of agencies and consultants. Understanding your scaling-imposed designed constraints and being able to explain it well will go a a long way.

## Avoid imaginary scaling issues

{% tweet 800752571497545729 %}

I want to mention that scaling issues are not as common as we sometimes imagine they are. Usually our default approach will suffice. If you do not over-engineer problems when they are not present in the first place, it will be easier to justify the time when they are the real deal. Don't be the dev shop that cries wolf on scaling problems!

Happy coding.