Application Scalability — How To Do Efficient Scaling

Application scalability is the ability of an application to manage a growing user base. When you build a great product or application, sooner or later, it will be drawing attention more and more users who will expect a flawless, perfect application as the demand grows in the time it handles more and more requests per minute. If we are not prepared for this, the application performance will start degrading, and you will lose your audience and business. In this article, we explain why you should pay attention to when building a scalable application.

What Is Application Scalability?

Application scalability is the potential of an application to grow in time, being able to efficiently handle more and more requests per minute (RPM). It’s not just a simple tweak you can turn on/off; it’s a long-time process that touches almost every single item in your stack, including both hardware and software sides of the system.

In case of problems, you can keep adding new CPUs or increase memory limits, but by doing so, you’re just increasing the throughput, not the application performance. It’s not the way you should stick to when you see your application is starting to have efficiency problems. Scaling the application is not an easy thing, and thus you should know your application very well before starting to think about how and when to scale it.

The Problems With Application Scaling

Quite often, you see a lot of scalability issues when your application grows too large, but the application capacity to scale is more about the whole system architecture. Building the project using The Rails Way is certainly not the best approach when your application is evolving rapidly, but it doesn’t mean that scaling a Rails app is always a pain. Of course, Twitter moved from Rails to Scala, but on the other hand, Shopify is constantly growing with Rails at the backend for about ten years, with over 50,000 requests per minute and 45ms response time. Again, many frameworks are highly specialized but selecting a framework depends on application needs, framework popularity, cost, support, and other factors, etc.

Source: https://trends.builtwith.com/framework

Even if you don’t have performance or scalability problems like Twitter or Shopify, planning and developing the application in a proper way is priceless. You may face dozens of different issues when it comes to scaling. A few general sources of your problems may be related to:

• Limited physical resources like memory, CPUs, etc.,
• Wrong memory management
• Inefficient database engine
• The complicated database schema, bad indexing
• Poorly performed database queries
• Wrong server configuration
• App server limitations
• Overall spaghetti code
• Inefficient caching
• Lack of monitoring tools
• Too many external dependencies
• Improper background jobs design
• More, and more, and more.

Regardless of all the beliefs, Rails is a great framework with an incredibly huge community, and millions of already answered questions online. It has hundreds of great open-source tools you may instantly build into your stack and a lot of profiling and analyzing tools that help you to identify the bottlenecks of your system.

How To Do Efficient Scaling?

Keep Your Code Clean

It seems to be obvious, but we just can't neglect to point it out here. Writing the right and productive code is the key to your application scalability. When your application is full of spaghetti code, it becomes a big ball of mud, and it's tough to maintain and scale it.

Leverage 12factor (https://12factor.net/)

It’s an excellent methodology that focuses on the best practices of developing a scalable application. It’s language-independent, so implementing each of these 12 factors depends on the developers. You really should follow these rules if you want your app to scale flexibly over time.

Take Care Of Your Database

To let the system grow smoothly, you must take care of the database. Choosing a proper DB engine and designing robust possible schema you’re able to handle increasing transactions per second efficiently.

Prevent Problems With Queries

Every single web application performs vast amounts of database queries, even if you have awesomely designed relations with proper indexing, running on the best engine on the market, remember to ask your database for the information efficiently, avoiding N+1 queries, unnecessary eager loading, etc.,

Choose The Right Hosting

We have to keep in mind that scalability is not only about your code. It’s essential to have proper server infrastructure and configuration. You can save a lot of time just by selecting appropriate tools and providers. For example, Amazon EC2 provides auto-scaling features, Docker offers docker-compose scale, etc.

Track Caching

We don’t need a dedicated machine to handle your caching when you start your project, but it’s definitely a good practice to implement, track, and modify your caching needs over time.

Prepare For Load Balancing

If we are not using a `ready to go` infrastructure like AWS, remember that one day you have to prepare yourself to switch from a single-server architecture to a multi-server one with load balancing and reverse proxying.

Relieve The Backend

If we get a chance to move some code to the front-end, do it. Your backend will become less overloaded, as more and more things will be computed on the client-side.

Test and Monitor

Even if our codebase is clean and perfectly maintainable, we need some tools to monitor it and identify the problems as soon as possible.

Optimize

Identifying the problems is one thing, but we have to take advantage of the tools we have and optimize our code and configuration to minimize the bottlenecks of your application.

Separate Code

It’s also a part of code cleanliness — try not to mix too many parts of your system in one place. Separate frontend and backend layers, detach background jobs from the main system, use design patterns wisely.

Update On Regular Basis

Keep all the stuff up to date to avoid blocking moments due to outdated parts of your system (e.g., old ruby version).