Building a Scalable API in the AWS Cloud

We've been running our Node.js based API in the AWS cloud for a couple of years but have been wanting to scale way up. Rather than trying to beef up our existing VPC (vertically scale) I made the decision to architect a new solution and rebuild it from the ground up. In this post I will talk about some of the technologies we leveraged, challenges we ran into, and benefits we have seen already.

As you probably guessed from the image above I saw this as a great opportunity to try Elastic Beanstalk. Elastic Beanstalk is what is known as a PaaS (platform as a service) and it acts a container for your applications and their respective environments. After creating an "application" you define a set of parameters corresponding to AWS services like EC2, RDS, ELB, etc and boom EB takes care of creating compute instances, database servers, load balancers, and more! And yes, I know what you are thinking and it is just as magical as it sounds. As a part of this configuration you can setup autoscaling triggers which will scale your fleet of applications up/down based on the metrics you set. It was an absolute joy doing load testing and watching the fleet respond like an accordion based on the amount of CPU being used.

The reason I went with this approach is because I know that we have a very steady load that will only grow based on the number of machines we have connected but on top of that we have a number of highly variable customers which could cause huge spikes for short to medium durations. In the "olden days" we were forced to pay for servers which could not only handle the peak load but also the forecasted load based on our growth. Today with solutions like Elastic Beanstalk and autoscaling you are only paying for the fleet needed to support the current load and not the worst case scenario load. Clearly this is huge for the bottom line.

For this particular application we are leveraging the following AWS services:

  • Elastic Beanstalk
  • CloudFront
  • CloudWatch
  • EC2
  • ElastiCache
  • ELB
  • RDS
  • Route 53
  • S3
  • Trusted Advisor
  • VPC

A really neat aspect of using Elastic Beanstalk is the not only the ability to monitor any component of your environment (via CloudWatch) but to also see a summary of things like CPU utilization and network I/O across your entire fleet.

The only major issue I had with this architecture was with WebSockets. Our mobile application uses Socket.IO for all communication between the client/server and we kept seeing 400 errors on the socket connection. After a lot reading and chatting with AWS engineers we came to find that the proxying being handled by the ELB + Nginx was causing the handshaking to fail on the socket connection. The fix (take note, it could save you a major headache) was to change the ELB configuration (from the EB settings) from HTTP/HTTPS listeners to TCP on port 80 and SSL on 443. The combination of that along with removing Nginx from the stack solved all of the socket issues and even with hundreds of devices connected to dozens of servers in the fleet everything stays in sync.

In closing, we couldn't have landed on a better method for keeping our API scalable, even if we spent a lot more dough. The peace of mind that comes from knowing that the environment will scale up when it needs to without any human intervention is near priceless.


Crowdsourcing is a word that many of us have heard but not everybody understands. Google defines it as [to] "obtain (information or input into a particular task or project) by enlisting the services of a number of people, either paid or unpaid, typically via the Internet." This happens all over the place but one of the most successful examples of crowdsourcing that I have seen is Foursquare.

Up until somewhat recently we all knew Foursquare as that app everybody used to checkin places and let their friends know where they were at. Beyond that it allowed users to provide comments/ratings about the places they checked in. As adoption of the service grew so did their database of locations and even more important, information about those locations.

Recently Foursquare (as we knew it) has spun off into two apps, Foursquare and Swarm. The original checkin app, Foursquare launched in March of 2009 while the new checkin app, Swarm launched in May of 2014. You may be wondering, why the name change, or even more appropriately, what does this have to do with crowdsourcing? The way I see it, Foursquare conducted one of the most successful crowdsourcing experiments by posing as just an app to "check in" and share your location with friends while behind the scenes building an enormous database of detailed information about locations all over the world. I truly believe if they had gone about this in almost any other way it would have failed. The fact that they made it dead simple to create/share locations and provide comments about them was huge, and equally important, they gamified the heck out of it. From their point system to badges to mayorships, they played all their cards right. Anybody notice how nearly all of those things are gone now that they aren't relying on us to seed their database any more?

So now we have two apps, Swarm which is purely for "checking in" (sharing location) and organizing groups for public outings as well as Foursquare which is now one of the most populated and informative directories of public venues. The vast majority of people I followed on Foursquare stopped checking in once the split happened and now all reviews/discovery must be done through the Foursquare app. I can imagine there are numerous business decisions for going this route and I definitely applaud the company for proving that crowdsourcing definitely works and when done correctly it can be immensely effective.


The World In Links [May, 2012] -- Coffee, JavaScript, PHP

The World In Links by Nicholas Kreidberg Coffee - 40 creative mugs, cups and glasses.
Diff - Online tools for comparing code.
Excel - 30 geeky artworks creating with Excel.
Facebook - 5 privacy settings you should know.
Fonts - Super clean, high quality free fonts.
Google - How To Download Your Data.
htaccess - Case-insensitive RedirectMatch.
Humor - 40 Ridiculously Oversized Every Day Objects.
JavaScript - Prototypes in JS.
jQuery - Why nobody used your plugin.
Maps - Some of the coolest uses of the Google Maps API.
MongoDB - Getting started with Mongo and PHP.
PHP - The Fat-Free framework.
Ruby - RubyMotion, the Ruby toolchain for iOS development.
Sublime Text - BracketHighlighter plugin.