Most web applications are composed of a few tightly coupled components. There is a user interface layer, usually composed of static files (AngularJS, Vue.js, React,...) or mobile applications already in the user device. This user interface talks to a few API endpoints to login or get information so the user can do something within the application, and those API endpoints get information from various datastores perhaps on a relational database or in an external service. Sometimes getting an existing application that was running in a server and trying to run the application in a distributed scale-out environment is too hard to do and too error prone without a full rewrite of the application. How can we scale our application if we don’t have time to rewrite the application?
The Bespoke Solution proposed was:
- Separate between read only (GET, HEAD, OPTIONS) and write (POST, PUT,...) methods.
- Replicate datastore from the lead server where we have writable endpoints to the read only nodes.
- Route traffic based on method, can be done using Nginx, HAProxy, Traefik and many others.
- Decide sizing of the servers, don’t be afraid to scale-up, a 256 threads machine with 2TB of RAM and a few TB of NVMe disk is able to process a good amount of requests per second.
- Deploy a CDN like Cloudflare to accelerate the delivery of static assets and if it’s like Cloudflare protect your properties from attacks and bots, so you’ll only need to process legitimate requests.
- Backup everything and create a Disaster Recovery Plan, perhaps using a Cloud provider where you only need to pay full server and bandwidth costs when in a disaster or replicating the setup to another of our data centers and use those servers for haltable workloads.
- In case of having the lead server impacted, you can always promote one of the read only servers to write and update configurations accordingly.
This way, you can scale-out your application to your write capacity where you can keep scaling-up to sizes that in another provider won’t be possible technically or cost prohibitive. Having a small number of read only instances reduces the management costs of the replication, so it’s wise to scale-up as soon as it makes sense. Noraina can help with the design and implementation of this kind of architecture. We found that this kind of solution is able to scale to several millions of users or requests while being low in complexity that lowers MTTR (tooltip with Mean Time To Repair) as it helps on diagnose and resolution of any and provides a great MTBF (tooltip with Mean Time Between Failures) as simple things are harder to break.