How Do You Increase The Scalability Of An App That Contains A Database?
Scalability is a term central to modern web development, and one of the central focuses of any development team. In simple terms, it’s the ability for an app to rise to meet increases in demand (either technically from the various devices users are using, or in the numbers of users themselves). Since modern web and mobile device users have grown accustomed to nearly instantaneous response times from websites and apps (a far cry from the early days of the Internet), ensuring scalability in an application is an essential step.
Often, scalability is either helped or hindered by the database powering a particular app or software program. Since databases do the dirty work behind the scenes (in terms of responding to user queries and returning information or results accurately and successfully), they often serve as “choke points” that can hinder user experience and app run time. That’s why ensuring your front-end coding works efficiently with your database ensures that your software can scale to meet demands.
But how do you increase the scalability of an app that contains a database, especially if you are noticing long load times or seeing user complaints? Since improving this process is one of the most important factors to ensuring your app or software stands out from competing options for users, let’s dive into some tips to increase scalability here.
Tip #1: Make Sure You Figure Out Where The “Choke Point” Is Occurring — It May Not Be The Database
Any web-based app is composed of three key elements — network connectivity (the Internet itself), the application server, and the database server. These elements leave you with four key areas where scalability can actually occur:
- Disk I/O
- Network I/O
- Memory
- CPU
Before worrying about your database, you (and your fellow devs) should rule out other potential bottlenecks to make sure it’s actually the database that’s causing runtime issues.
Tip #2: Choose The Right Database And Hosting Before Building Your Application
Not all databases or server hosting offerings are created equal. Obviously, if you are working with a limited budget, you may be restricted in this sense. However, given how critical ideal user experience and decreased runtimes are for keeping users coming back to your app or software, this is one area where you may want to go a little over budget to prevent nagging load time problems down the road (especially if your app experiences a dramatic increase in user adoption). Here are a couple specific things to consider as you make your choice:
- Which DB engine do you use, and what benefits does it offer?
- Put thought into the schema you design, with an eye towards handling large amounts of traffic in the future, even if you don’t expect to right away
- Proper server infrastructure and configuration can play just as big of a role in how your database performs, so do some research into what your hosting company (say, Amazon or Docker) offers in terms of features and benefits
Tip #3: Offload The Database Whenever You Can
As a general principle, you want to try and keep away from the database whenever you can, to reduce the amount of work it is performing at a given time. For example, try not to open connections with the database or or start transactions with it unless absolutely necessary.
Another example of conserving database resources and reducing volume can be done through optimizing the process in which requests are handled by the database. For example, if multiple requests access the same resource and perform the same calculation, it’s preferable to proceed with the first, while letting the others wait until the job is finished to just use the final results. Letting all the threads access the resource can only slow down the process, and we know that’s the main thing we’re trying to avoid.
Tip #4: Caches Are A Great Tool
Caches can significantly offload the database, particularly for applications accessing the database in read-only mode. In terms of which type of cache is best, in-memory cache is preferable to an on-disk one, which is itself better than using a remote or a relational database.
Likewise, caching coarse-grained objects can save both CPU and time required to interrogate a variable number of cache zones, as opposed to a single cache zone. Similarly, retrieving a full object graph saves time assembling the object graph.
Tip #5: Don’t Store Transient Data Permanently
Whenever possible, avoid storing transient data (such as login session data) in the database. A general scalability guideline to follow is to try to only store actual, necessary, critical and actionable business data in permanent storage (whether the database or disk) and nothing else. This follows the same principle as tip #2 — by freeing up the database to focus on processing requests and conserve its resources, you can help avoid it being overloaded by increases in volume from users.
Tip #6: Move As Much Code From The Back-End To The Front End
Any computations that can be tackled on the front-end only decreases the load and responsibilities of the server-side of your app and software. While this isn’t a complete solution (as we’ll note in our next tip), try to do it whenever you think it’s possible.
Tip #7: A Note Of Caution On Database Offloading
Now that we’ve told you all of the benefits of database offloading, we’d be remiss if we didn’t also offer a word of warning in going too far in the opposite direction. While removing elements of database load can obviously allow it to perform better and work more efficiently with your front-end code, putting everything into the app layer can also cause a host of different problems and negatively affect runtime. This is obviously counterproductive to the whole idea of helping to scale and offer the same user experience regardless of demand.
