Skip to content
Technology
Serverless Scaling With S3
June 13 2018

We here at Culture Foundry have some clients who see intense traffic spikes due to “real world” events. For this scenario, we’ve written a serverless solution that scales well at a reasonable cost (both in terms of dollars and developer time). The solution doesn’t use new serverless technologies like Lambda or the other FAAS offerings, but rather an older technology, Amazon S3. We leverage S3 and built a publishing system which handles large numbers of users and displays oft-updated information beautifully.

There are three components to the architecture.

The first is a data processing engine that pulls data from a variety of sources and builds a set of JSON files containing the displayed data. This engine can run anywhere and be written in any language. Our system happens to run on EC2 and be written in Go. In addition to pushing the data up to S3, the processing engine sets headers to have the data cached intelligently. For example, recent event data can be set to cache for seconds, whereas unchanging historic data can be cached for months.

The second component is AWS S3 and Cloudfront. An S3 bucket holds the JSON files, including updated files from the data processing engine. Cloudfront sits in front of S3 and caches the data as it is requested. Cloudfront helps with delivery speed, scaling, and decreased cost. You will want to make sure you set up CORS on S3 correctly to allow access for the display component (see below).

The final piece of the puzzle are the HTML and javascript that users’ browsers will access. The HTML page can be hosted anywhere, including S3, though we host it on our CMS so non technical users can inject configuration via the WYSIWYG interface. Such configuration and other information is consumed by the javascript component which also pulls the correct JSON files from S3 via Cloudfront to build what the user sees. We’ve used various frameworks to build this component, including Angular and Vue, but you can use any javascript component library.

What type of problems is this solution not a good fit for?

  • Real time updates. Pushing changes to S3 and through Cloudfront takes time, and don’t forget the eventual consistency model of S3. If milliseconds matter (you’re building a stock trading interface, for example), I’d look at a different solution.
  • An internal application. While you can lock down access using signed URLs and OAI and TLS, your data will still be traveling over the public internet. If that worries you, this may not be the right fit.
  • Interactivity. S3 is a great repository for read only data, and modern javascript can provide interactivity. But if you need to store results of user actions, you’re going to need additional components (probably an API running someplace).
  • Small numbers of users. This solution has a lot of moving parts that need to be maintained by expensive software developers. If you don’t expect to have tens of thousands (or more) concurrent users, you will want to stick with a plain old CMS.

This approach leverages the serverless technology of S3 along with a few other components to build a solution that you can still configure via your CMS, but use the power of the network to leverage both AWS S3 and your users’ browsers. Such scaling (both up and down) is transparent and doesn’t require building or managing infrastructure.

Culture Foundry is a digital experience agency that helps our clients elevate their impact with beautiful technology. We provide the expertise and insight at every layer that makes a great digital experience for websites and applications possible. If you're committed to elevating your digital experience, contact us and we'd be happy to schedule a chat to see if we're a fit.

(Psst! We also happen to be a great place to work.)

Back To Top
Search