We are often asked about how the ShareInInvest platform will perform in response to a massive increase in user traffic. This is one of those so called 'good problems' and we've certainly faced this scenario. We've also given a lot of consideration to the challenge and addressed it in both the architecture of our applications and the configuration of our deployed environment.
The ShareIn application suite is deployed to Microsoft Azure App Service and we’ve made use of the tools available in Azure to manage rapid scaling of the web application.
We have our own dedicated content delivery network in place to host static assets. This serves flat files and removes load from the web application itself. In the response to a spike in traffic some of the demand will be offloaded to the CDN. The CDN hosted on Azure is a distributed global service that can respond to traffic spikes.
Separately we use a high availability cache service to store data objects with varying expiry times. When a requests hitting the web application it looks to serve a response from the redis cache when possible and where appropriate. The cache handles most data objects in the application. Redis cache is faster than retrieving the data directly from the db and so it reduces the load on the web application. It’s also independently scalable to the web application and we can scale up resources dedicated to this in response to a demand increase.
On the production web application itself we have autoscale configuration in place. This will automatically scale up the application by adding additional site instances. The autoscale kicks in as soon as the application is using more than a reasonable amount of the available CPU resources and the application can spin up additional instances before any manual intervention is required.
In addition to this we can manually scale up the resources available to the application. This action would be taken in response to a sustained increase in traffic to the web application.
Most requests to the web application are handled by the CDN or Redis cache but for the direct to db requests and responses we rely on a SQL Azure database instance. This can be scaled independently of the other resources serving the application. Database scaling is manual rather than automatic but can be updated quickly via the Azure administration portal. Average CPU utilisation of the database is low and any spikes beyond substantial CPU utilisation generates alert notifications that we can respond to immediately.
In addition to the deployed environment configuration we have also focused on application performance from the very beginning. For example we use a lightweight ORM for performant database queries. We serve http requests over http/2 (h2) for faster and more secure packet delivery. Rendered pages are regularly tested for speed and best practice to ensure that we are following the latest standards.
Taken together this setup means we can be very responsive to changes in demand placed on our applications and we are able to deliver fast end user experiences to your customers at scale.