Yesterday was the American tradition of eating much food and watching the New England Patriots play football, oh and of course, the commercials!
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.
Perhaps they had no idea how successful it would be, but when America flocked to their site, it was hugged to death almost immediately.
The site was built to handle 150,000 requests per minute 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 at the moment, but Cloudflare, Cloudfront and others will do the trick. I think Netlify 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 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
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.
Top comments (2)
Just as a minor point - I really hate it when people keep bringing up the database issue with the typical "yadi yadi yada MySQL can scale, you don't need X", and completely miss the point.
Everyone is 100% perfectly aware you CAN scale with MySQL, PostgreSQL, hell even with SQLite just as well. The issue isn't the ability to scale, it's the effort and limitations of scaling. With MySQL and similar after your basic caching layers stop being the only solution needed (and you need those in practically any large popular web application anyway) you end up trying to actually scale MySQL, a matter that is not by any means simple.
You've basically got the options of
a) vertical scaling (i.e. a bigger, faster server), that takes you a bit further
b) switching to a multi-master Galera Cluster, which comes with limitations you probably didn't take into account when you set up your site, and switching from your current MySQL setup means downtime and a lot of effort
c) adding read slaves, which ALSO has significant issues and limitations. Not the least is that the replication will just randomly break and you have to manually fix it at 3am on a Friday night after a giant celebration party and you're out of your mind drunk.
d) sharding, which you will have to do manually, in your application logic. You will no doubt do it wrong since there are no good guides out there, and you will spend significant amounts of effort trying to first get your data to shard at all, and then later lose most of your hair when you realize how bad your original design was and how much work it is going to be to change to a new way of sharding
e) buy one of those really expensive MySQL cluster products and hope it solves all of your problems, before realizing that they come with even more limitations and will break your application logic completely and require significant architectural redesign
For most small startups upfronting the cost and time of trying to figure out their possible scalability headaches in the far future, so unless you've got a guy who's intimately experienced with these things you will no doubt have a bad time when you realize you need to scale.
Now, for most people this SHOULD sound like an extremely bad idea, and no SQL database out there really solves this in an affordable way. Also if Galera was "the solution" it should be the default as well, but it's not.
Some alternatives exist, e.g. NoSQL databases.
Now a bunch of NoSQL databases have solved a lot of these growth pain issues in nice ways, and depending on your needs you can e.g. use Cassandra (or the ScyllaDB fork), Riak, MongoDB, or many of the other ones. Just try to understand that ALL databases come with downsides, and you should google for them in advance.
If your NoSQL database of choice doesn't provide you with the searching tools you need that's ok, you probably shouldn't be using SQL for search anyways, try something like ElasticSearch instead.
If you're lucky enough to be able to pick your tools 100%, maybe pick Google Cloud Platform and their Datastore, or if AWS is your poison maybe DynamoDB might be for you. Hell, maybe Azure Cosmos DB is your thing. Either way, any of these tools will significantly reduce the growth pains you will experience.
Yep, definitely agree with this.