How to Scale Your Applications: 5 min read
Illustrated Guide on How to Scale Mobile and Web Applications
I remember writing my first application. Back then, I was overthinking the design & architecture of the application, in part because I lacked trivial knowledge of the app lifecycle: how to write the minimum viable product and then scale it out as users grow. When limited in knowledge, I needed some basic illustrations on how a regular web/mobile app can be scaled out.
Inspired by Ian Gorton’s book "Concurrency and Scalability for Distributed Systems," I want to share one simple example of scaling your application design in a few illustrations and notes. I hope it gives you a nice intro and helps your journey to the software system design. For more, I recommend you read the mentioned book or any relevant source. If you are interested in a quick intro to basic architecture designs, then read my previous article, Software Architecture Patterns: 5 minutes read
1. Basic design for a Web app
Say you have an application where your client sends and receives some data from it. It can be a basic "to do" or "wallet" app. At this point, you only need 1 app server and 1 instance of DB working together.
2. Scaling the app servers
As requests to the application server grow (i.e., due to the increasing number of users), there is a need to level up the CPU capacity of the hosting machine. However, upgrading CPU capacity is expensive and not sustainable as it can also grow to a certain level; a smart solution would be to increase the number of instances of your app. Load Balancers are needed, as they distribute the load of the requests between the app instances, thus enabling horizontal scaling of the application logic.
As some solutions require session storage, extra storage capacity in the form of Memcached or Redis would be needed, as Load Balancers are not supposed to remember sessions.
3. Scaling the database with caching
As application nodes have increased in numbers, our database may face problems because of increased requests. To relieve it from such a high volume of requests, we can store the most requested data in the distributed cache system available in cloud services providers like Amazon and Azure.
4. Distributing the database
If caching is not enough to reduce the volume of work on your database, one can switch from using a single database to horizontal scaling, where the application data is stored across multiple DB instances. While it is challenging manual work, cloud services provide many solutions to achieve distributed database systems just by a few clicks (read Amazon Aurora Global Database).
5. Increasing RESPONSIVENESS
Even though our application is scaled enough to meet the increased requests, we may still need additional improvements in our design. For example, if our users submit something to our TODO app or submit a new Expense list, we don't want them to wait until this new request is processed and stored in our database. To achieve this goal, many app designs include queuing system, where certain tasks or requests are queued for later processing and storage. Thus, as soon as a user submits a request, they immediately respond to the successful request submission. However, at the same time, the latter is waiting in the queue to be processed and later persisted to the DB.
So far, so good! I hope those illustrations briefly introduced you to a trivial case of how the scaling of a product may happen as it grows. Let's wrap up what we've covered:
- we started from the design of a simple Web app
- we increased the compute capacity by adding more instances and a load balancer
- we relieved our DB from the extra load by leveraging the caching system
- we scaled out DB, turning it into a distributed database system
- we improved the responsiveness of our application using a queuing system
For the next reading, I recommend you Caching as a part Software Architecture: 5 min read, which is a closer look at the performance tuning via caching.
