How We Built Globally Scalable SAAS Platform

About me

I run and manage Shipthis, we are a SAAS platform offering full stack of software services for Freight Forwarding and Logistics Companies. We are a very small company (2 developers).

Building Globally Scalable SAAS Platform

We had customer requirements coming in from various different parts of the world.
We had hosted our application in AWS South Asia region, a simple ping Round trip time from South Asia to North America is around 300 ms. One of the main concern people outside of South Asia region was that the application was slow to respond.
We knew we needed a global deployment of our application.

How we approached Scaling

The first step was to draft a plan on how to deploy the application in multiple regions with the following criteria

1. Deployment should be cheap (We are a small company).
2. Developer resources were limited, so we needed a least effort, best outcome strategy.
3. The database server should be locally present in the region of deployment.
4. Deployment process should be straight forward, for example, a simple 1 line command should deploy the application globally.
5. Changing configuration should be quick and simple.
6. Billing and Organisation should be managed from a single location.

This was our Final Setup.
We used mongoDB Atlas to offload most of the DB Management work.
There were 2 different options for MongoDB Atlas deployment

1. We could either have a globally redundant single DB Cluster.
2. Have different DB cluster deployment in each region.

After careful planning we decided we are going ahead with option 2. This may not be the best case for all companies, for us this was better both interms of cost and speed.
Our goal, deploy the application in 3 regions

1. South Asia
2. South East Asia
3. Us East

When would you pick option 1 ?
This is something you would pick if you are targeting customers who are accessing the same data throughout the world. In our case, each customer was present in specific region, and they accessed data only relevant to them, so picking option 2 was better for us.

Configuration Server + Config DB - South Asia
Endpoint Name: config.xyz.com

This is where we stored all of our customer specific configurations and billing data.
The first API call will be made to this server, and this in-turn returns the customer specific regional server.

Region Specific Server + Region Wise DB - South Asia, South East Asia & US East
Endpopint Name: region.data.xyz.com
This is where we stored the customer data, and cached copies of the configurations.

When customer loads the web app
We call the config.xyz.com, this returns the server the customer data resides in say south-east-asia.data.xyz.com
After this all API calls will be made to the south-east-asia server.

Deploying to the Servers
We used AWS code build to write a build and deployment pipeline and Elastic Beanstalk to manage the deploy application. There are tons of resources out there on how to deploy your application to the elastic beanstalk.

We can configure build triggers in the code build. As soon as we commit the code, the code build runs the test cases first, if all the test cases pass it will deploy the application into the different beanstalk regions.

Challenges we faced

1. As soon as you have multi-region deployment the cost of deployment adds up quite significantly.
2. We figured there are certain services which don't need servers to be locally present, we could optimize the response times using Caching and CDN's.
3. We had to build a centralized configuration module, to manage all of the deployment configurations from a single place.

We ended up rewriting most of our deployment logic, even the billing and organization management logic changed quite significantly too.

Key takeaways

1. Caching and CDN help a lot in terms of performance, especially when you are deploying application globally.
2. Experiment with various different approaches, there isn't one size fits all for everyone.
   For example, you could choose to have database servers deployed at different regions independently, or you could have a global multi replica deployment. It entirely depends on the use case.

Tips and advice

1. Use services like MongoDB Atlas, DocumentDB or any hosted Database service to offload most of the database server management workload.
2. Use Elastic Beanstalk / App Engine etc to do the application deployment. Deploying in a load balanced cluster would be as simple as gcloud deploy or eb deploy.
3. Plan for multi-region if you are a SAAS company as early in the development lifecycle as you can. Because sooner or later you will need this.
4. Use Serverless functions whenever you have repetitive tasks which don't take much time or tasks which are done occasionally.
   You need to be careful where you use the serverless function, in our case we use this for file upload. File uploads are rarely done in our platform and most of the time its sub 1 MB files. If you have too many file uploads this cost might add up. Serverless functions are billed on millisecond CPU & Memory usage basis, so avoid it if you are going to use it in excess.
5. Identify API calls which take a lot of time to load, try to CDNize / Cache them if possible.

Final thoughts and next steps

Our architecture is always evolving, and our focus is and will continue to be on improving the customer experience in our product.

Would love to help SAAS companies deploy the app globally. Ping me anytime.