BaaS at Scale

A client-side app backed by a backend as a service (BaaS) like Alphabet's Firebase can be a terrific architecture for scalability. But what exactly are the limits of your BaaS? Do you know how it will scale? How much will it cost you each month to operate at your intended scale?

If you don't know the answer to these questions, you could be in for trouble. BaaSes are convenient and powerful, but they aren't a magic bullet. You must approach their use thoughtfully to avoid serious and expensive issues when you eventually operate at scale. Here are our tips for approaching the high-scale use of a BaaS.

Know Your Flow

Since many BaaS plans have usage limits or charge by the byte, it's critically important to be mindful of how data flows between your app and your BaaS. Taking a few hours to make diagrams, calculate average expected payload sizes, and project total data usage for several different payload schema options can pay for itself in literally hours of high-scale operation.

On a recent project, we reduced data usage by 90% simply by subscribing clients to data updates more granularly. Can you spot the difference in data flow?

Load Test at Scale

Your personal computer is great for building and testing load test processes (and occasionally even for some running some lower-scale tests), but it can't simulate the modem-smokingly-large traffic volume you really should be testing at.

High-end cloud computing instances like those provided by Amazon Web Services' Elastic Compute Cloud (EC2) service are more powerful than any physical computer you likely have access to, their network performance is awe-inspiring, and you can rent them inexpensively by the hour for the duration of your tests. They're perfect for high-scale load testing.

C3.8xlarge instances in particular are perfect for load testing:

• 32 CPUs
• 60 GB RAM
• SSD storage
• 10 Gigabit network performance

All this added up to the capacity for ~1,250 concurrent connections to Firebase (our BaaS of choice) per instance. And for only $1.68 per hour.

Load testing can take many forms, but I find it particular useful to run at least one set of tests directly and exclusively against your BaaS, cutting out all other aspects of your app. This will provide you with the clearest understanding of how your BaaS interaction operates at scale.

Testing scripts of this variety can easily be written as a Node.js script. Our scripts usually consist of two files: one for spawning a large number of isolated test processes, and another that is the actual test that will execute in said processes. The latter is application specific, but the former is generic, so I've included it below:

Know How You Scale

You should be able to determine how your application's resource consumption scales as a function of increasing traffic. But it's never a bad idea to confirm your hypothesis with some actual test results.

To do this, run a series of load tests with an increasingly large load. For a recent app, we started of running our load test on a single C3.8xlarge instance (~1,250 concurrent connections). Then we moved to 5 instances (~6,250 concurrent connections). Then finally 10 instances (~12,500 concurrent connections). Plotting the results confirmed our understanding that our app scaled linearly, and we could use that knowledge to project capacity usage for much higher production loads. If, however, our 10-instance test consumed 4 times as much capacity as the 5-instance test, we would know that we either need to update our app to scale more linearly, or plan accordingly for quadratic scaling.

If your app must scale quadratically, you should probably start thinking about adopting a sharding) strategy immediately. BaaSes aren't immune from database technology limitations; you'll have to do some work if you need to support particularly heavy or complex data use at extreme scales.

Talk to Smart Humans

Nobody knows more about your BaaS than the engineers who built and operate it. If you have questions about your BaaS's limitations, your app's scalability, recommended sharding strategies, etc., reach out to the ones who know that world best. (Special shout-out to the engineers over at Firebase who have been an incredibly helpful resource for us.)

---

Working with a backend as a service can save you the time and the headaches associated with building and maintaining your own scalable infrastructure, but you can't just turn on autopilot when you choose to go BaaS. At extreme scale, scalability can remain a challenge even after you choose to work with a BaaS. Thoughtful planning and careful testing, however, can ensure that your BaaS experience remains a smooth one, even as your traffic volume skyrockets.