Carling Pay Per Inch

Listen to article

Using a serverless architecture to respond to huge traffic peaks for the UK’s number one lager brand

Carling is the UK’s leading lager brand in the United Kingdom, owned by Molson Coors Brewing Company.

Initial Brief

A key part of Carling’s ambitious marketing strategy is ensuring that the brand contributes to the most current events taking place, and the 2016 European Football Championships were considered one of those key moments. The brand actioned an activity called Pay Per Inch that enabled customers to purchase a television for the cost of its screen size (for example, a 48-inch TV was available to purchase for only £48.00). As this activity was likely to be very popular, Fast Web Media was tasked with creating a durable website that could handle thousands of visits in a very short period of time without crashing.

It was Fast Web Media’s responsibility to develop, test and manage a bespoke web page suited to Carling’s needs, ensuring there was absolutely no room for error, especially for such a time-critical and highly anticipated campaign. We were also asked to amplify the site at key times, and so Fast Web Media’s Search team enforced a tactical and timely paid search strategy aimed at funneling consumers to the Carling website in the run-up to and during the sales. Read more about Fast Web Media’s paid search strategy for Carling Pay Per Inch here.

Challenges & Solutions

During the initial briefing stage, it became clear that a standard application architecture would not be scalable for this particular promotion, due to the volume of traffic expected to flood the site and the limited stock available to purchase. As this was such a large promotion, it was important for the Fast Web Media team to identify the main areas for concern, in order to ensure that the execution of the promotion ran as smoothly as possible. The risk assessment identified three key areas that required serious scrutiny:

Ensuring the application could handle huge traffic spikes in a very short period of time (the actual campaign was only live for around 20 minutes per week, with an information site available for the rest of the week);Making sure the website only displayed the “buy” button when stock was available, in order to make sure stocks were not oversold;Locking down any redemption routes so that only genuine winners could redeem the television through a third party payment provider.

Preparation for this project was key, so various scenarios and sample load tests were committed by the development team. This attention to planning ensured that Carling would be provided with the most cost-effective, robust and scalable solution for the promotion.

Last year Amazon Web Services (AWS) released a new service called Lambda that allows users to run code without the costly and time-consuming need to provision and manage web servers. It runs code in response to an external event (for example, an API call) meaning users only pay for the time their code is running, while at the same time scaling instantly to meet the demands of the application. For Fast Web Media and Carling, this was a win-win.

Fast Web Media has been using AWS Lambda for some time internally and found it excellent at running small jobs on an event-driven basis. As such, the team decided to use it to power the infrastructure behind the campaign. In order to route website traffic to Lambda, Amazon API Gateway fit the bill. While both these services are extremely powerful and customisable, setup can be quite complex. Thankfully, this is a problem that Serverless had already solved.

Serverless allows you to build auto-scaling, pay-per-execution, event-driven apps on AWS Lambda.

Using Serverless

Serverless is an application framework that allows you to “build applications comprised of micro-services that run in response to events, auto-scale for you, and only charge when they run.”’

Essentially, Serverless is an application framework written for node.js that simplifies creation of the stacks needed to support your application. This allows the user to focus on the application itself. One key feature that Fast Web Media found extremely helpful was the ability to deploy code and infrastructure to a new clean environment in a matter of minutes. Each developer had their own environment, which was recreated from scratch whenever a change was made.

For data storage DynamoDB was selected, a managed NoSQL service. Given the data that Fast Web Media was to hold and its write/access pattern, the team felt that a relational database (such as MySQL) was not suitable for this particular promotion. Dynamo gave Fast Web Media a number of features that really helped mitigate areas identified as risks. Firstly, there is the ability to provision read and write resource on a per table basis, allowing Fast Web Media to operate more efficiently than a RDS cluster could. The development team was able to set high write limits on signup tables, and high read limits on the prizes tables.

Secondly, DynamoDB allows you to insert documents with what is known as a “Conditional Write”. In this instance, the development team only wanted to be able to write users into the document, when a prize URL was still available. As the read of the prize URL was in the same query execution, it meant there were no race conditions where two users were given the same code, fulfilling the risk areas. Once the table was full, the query fails and throws an exception, stopping any subsequent attempts to write to it.

Frontend Development

The front-end of the application was written using React, a javascript library created by Facebook which is now used to render a large amount of its front-end. By writing the front-end in pure javascript, it allowed the development team to deploy the website statically to Amazon S3, again not requiring web servers to host the site. This was fronted with CloudFront to deliver the application to end users. As a result, response times from the front-end were consistently low, even during the minutes the campaign was active where there were *20,000 concurrent sessions.

In order to further reduce load on the serverless back-end, the application took advantage of a reasonably new feature available to web browsers: WebSockets. WebSockets allow you to push a message to a user’s browser, without them having to ask for it first. In the case of Pay Per Inch, the Fast Web Media team used this functionality for two main goals:

To inform all connected users of current stock availability in real-time

To activate the rounds of the promotion for everyone at the same time

To put this in context, during the promotion, there were 5 ‘rounds’ each Sunday evening for different sized TVs. There might be seventy 40-inch TVs available, but only five 65-inch TVs. As there were upwards of 13,000 people connected during the peak of the campaign, Fast Web Media needed to ensure the campaign started at the same time for everyone, without a user being able to gain an unfair advantage, or take down the servers through automation.

To activate a round, a message was distributed to all connected browsers, enabling the game to them. Once enabled, the remaining stock level would display along with a ‘buy’ button. Once the stock hit 0, the button was automatically disabled, thus avoiding over-selling stock.

In order to reduce the risk of anyone trying to ‘guess’ how to claim a prize before a round started, none of the functionality to actually claim a TV, or the API endpoints to post to, existed in the codebase. At the start of each round, a unique payload was pushed to all the clients through the WebSocket to allow those specific TVs to be claimed. The endpoints automatically expired as soon as all of the stock for that round was claimed, locking down any potential attack vectors. In 5 x 30 second periods, the system sent out over 1.4 million WebSocket messages to everyone connected to the game - if they had been API calls and responses, a very large server cluster would have been needed to deal with the load.

"We’re extremely pleased with the results from the Pay Per Inch campaign, having received a record number of entrants and overall exposure. The time Fast Web Media dedicated and the routes they went down to ensure our campaign ran consistently, meant that we could have every confidence in executing a successful and seamless campaign."

~

Outcome

After running for six successful sales days, in which the application never stuttered or suffered from the adverse load, Fast Web Media is extremely pleased and confident with running applications using serverless architecture. From looking at the metrics post-promotion, it is estimated that it would have cost upwards of 12x more to run using a more traditional server-based architecture.

The reliability of the site and its ability to remain un-wavered when faced with mass amounts of traffic, coupled with a strategic PPC campaign, meant that Carling received a total of 37,968 entries to the competition, becoming one of the most successful campaigns the brand has run to date. With Fast Web Media’s careful consideration for preventing unfair competition entries, 900 prizes were fairly distributed to the competition winners, receiving an overall positive feedback from Carling’s audience.