A system that has an ability to easily scale resources to meet the increasing workload without affecting the performance is known as a scalable system. The workload could refer to anything from an increase in users, usage, storage or number of transactions.
To make an easy to scale system, it is crucial to have an evolutionary way of thinking about software development cycle. This means the software architect should focus on designing a scalable software architecture from the early phase of the product life cycle.
Why? Because it will impact the Total Cost of Ownership (TCO) of your software in a big way. A late-stage consideration of improving scalability requires rewriting a big chunk of application code. And with that there is a big possibility of regression issues creeping in.
This blog provides vantage points to understand the best practices in achieving ease of scalability. We present a checklist on scalability that architects can maintain. You will find it handy and useful in business meetings where requirements & efforts get discussed.
Before you look at the checklist (which you can do by scrolling down), you must understand the kind of scalability that we are talking about. Let’s peep into client requirements that you will be required to scale for.
Understanding requirements for scalability
First, let’s talk about the popular version of scalability — dynamic scalability. A dynamically scalable system has the ability to handle an extra load by scaling within a minute or no notice.
Think of Uber. If your app shows some error during peak booking hours, you expect that if you close the app and open it again, the problem should be gone. A dynamically scalable system should be able to handle loads at that speed.
Or, think of Netflix. The load on their servers increases substantially during weekends. So, their systems should be able to distribute and respond to the extra load during weekends dynamically.
On the other hand, in Enterprise Applications the scalability requirements might not be so desperate or fast-changing. Yet you might be required to design dynamically scalable modules of the application. For example, think of a CRM or a salary processing system during a month-end scenario. In these systems, usage or the number of transactions can increase drastically during month-ends. Sometimes up to 10x the average load. In this case you will need to design these systems for a sudden rise in usage over month-ends.
Typically, in enterprise applications, scalability becomes a concern after quite some time when the number of users, transactions or the memory records increase considerably, and the performance bottlenecks start appearing in the usage of the application regularly. Whether you will hit these bottlenecks in 6 months or 3 years depends on how fast the business grows.
This means Enterprise Applications architects must pay close attention to coding standards and design patterns which will impact the ease of scaling of the application in the future.
To understand how you can do that, you should understand two types of scaling — Vertical and Horizontal.
Design for Horizontal Scaling
What is Vertical Scaling? The other term used is “scaling up”. When you scale a system vertically you increase the power of the current hardware. This can mean greater memory, faster storage or more advanced processors. It is more convenient among the two methods since change in hardware capcity requires very little change at the software level if any.
For handling a month-end load consider a vertically scaled set up.
What is Horizontal Scaling? It is also known as “scaling out”, where you increase the number of servers to balance the load. In this one, software adopts to scalability not by adding powerful hardware but by spreading the workload across new set-ups. Nevertheless, scaling-out comes with the price where it adds more complexity to the system. Moreover, having multiple servers require general administrative tasks such as security, monitoring, data, and backups.
Consider horizontal scaling when current average performance hits a dead-end.
Best practices to build a scalable system
One last hop before we craft the checklist. Let’s first look at some of the best practices that architects use for designing easy to scale systems.
Loose coupling: Building loosely coupled code enables an application to scale much faster at less cost. In such a design, the bottlenecks can be easily recognized. You can increase the capacity of one component without disturbing the overall application. In addition, you are not haunted by regression issues when you undertake to scale.
Asynchronous components: It is important to carefully analyze the application design to determine whether to keep components synchronous or asynchronous. Building asynchronous components make scaling easy.
Cacheing: While designing scalable system it is important to offload the database as much as possible. Cacheing helps to achieve this objective especially for retrieving information from the database in read-only mode. It is advisable to use in-memory cache rather than on-disk cache or relational database.
High Cohesion: A strong cohesion amid subsystems result in less round excursions since classes are logically grouped and reside in the same tiers. This can greatly reduce local and remote calls to complete a logical operation. This makes scaling easy.
Decentralization: a Distributed system is a group of subsystems operating on independent servers. This ensures ease of high availability by increasing the number of servers.
Position: Important components should be kept as close as together. For instance, it is less cumbersome to go through the content delivery network than to go through a load balancer, web server, and database for content retrieval.
Lesser network chatter: Design network as untalkative as possible since network communications tend to be slower as compared to in-memory ones.
One resource one function: Make sure one resource caters to one function in case of multiple requests for the same resource. If you don’t do this, then, despite scaling the system, you will be bogged down by the slow performance.
The Checklist
Finally, now, what are the points you must keep in mind when undertaking a new application development project? We have prepared this short checklist for architects when they are designing for scalability.
It will help you put good emphasis on scalability during business requirement gathering.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Business requirements checklist
→ Have you considered month-end scenarios?
→ How much will the load increase during month-ends or any other periodic business cycle?
→ Are there any directly stated scalability requirements from the client?
→ What is the estimated increase in the number of users or transactions in the next 6 months, 1 year, 2 years?
Architecture design checklist
→ Have you calculated the increase in usage, storage & transactions requirement in the next 6 months, 1 year, 2 years?
→ Have you figured out processes which should be made asynchronous?
→ Have you considered all options to increase software performance?
→ Is your design optimized for frequent and crucial tasks?
→ Have you figured how often the system should use a cache?
→ Do you have a distributed system in place?
→ Do you have load balancing software in place?
→ Is the database scalable?
→ Does your architecture design enforce decoupling?
Coding checklist
→ Are you making sure the developers are strictly following the single responsibility principle?
→ Does your code review guideline include the single responsibility principle as an important check?
→ Are you developers following decoupling standards and design patterns?
→ Have you taken care of asynchronous processing?
Testing checklist
→ Can you simulate peak loads in test cases? Has the testing team considered test-cases with 5X or 10X increase in transaction/user load?
— — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Have we missed anything? Are there any more critical points which should be included in this checklist? Write to us in the comments below.
