Here at Soliant Consulting, my team and I work with a variety of clients to build custom software that achieves their unique goals. No two projects or intended outcomes are the same.
Despite these varying project goals, we adhere to specific and strict project standards. This ensures our clients are happy with our completed software every time. We focus on building software that overcomes challenges and serves as a critical component of their business for years to come.
That means we don’t just build something that works now or six months from now. We develop solutions that support the business for years to come. Our team delivers software that can scale and grow.
For our business analysts, this means considering how a business can expand over the next decade. Our technical teams, however, are more concerned with sustainable user growth, feature additions, and simplified functionality enhancements. As a result, we have put together eight best practices to ensure we build software to allow for growth and scalability, every time.
(Because most of the software we build and support is web-based, our best practices lean this way as well.)
1. Build Functionality with Growth in Mind
All software presents a variety of functionality and consumable services for its users. Some are internal and function for the organization’s staff. Others are external and meet their needs of customers or other key stakeholders.
Before you start development, work with all affected teams to analyze how his functionality should perform following spurts of business growth. How would they function if you staff doubled or if you added a completely new department to your business? If your customer base doubled, could your external consumable services function correctly and as quickly as they do on launch day?
You don’t have to build massive capabilities directly into the first version of the software. However, it should have elasticity to allow for expansion.
2. Focus on Database Infrastructure
Many issues that obstruct scaling exist in a solution’s database. To avoid this foundation-level challenge, you first need to determine how and when to store your data. You’ll have to choose between an object store database and a relational database, and there are performance tradeoffs for each.
The former works well if you intend to make many changes in a short period of time. It allows for scalability without increasing layers of complexity to the database. A relational database, on the other hand, allows you to access information in many different ways. Unfortunately, it presents row-level or table-level locking issues.
Database Clustering Considerations
Next, you’ve got to decide how to cluster your database servers. You’ll have to choose between a multi-write server and a one-write server with read-only replica servers.
A multi-write server allows you to make more frequent, concurrent record changes to your database. It also provides more flexibility for changes in functionality or feature additions. This lends to increased support for smaller applications within the larger software. For example, a registration system functions to take on more and more data as people add themselves to the database.
However, a one-write server is often simpler. It allows you to insert, updated, and delete data on all one server and then update these changes to other servers. It serves as your center of knowledge, and you don’t have to worry about multiple servers changing data simultaneously. For example, a reporting tool may not require many changes to data – just many queries. A one-write server is perfect for this kind of application as the bulk of the work will occur on read-only servers. The best one for your web application really depends on what it does, but consider how that could change over its lifetime when making your choice.
(Please note that I’ve barely scratched the surface of the differences between multi-write and one-write server strategies. My team and I often spend a considerable amount of time with our clients stressing the pros and cons of each before making a decision on one or the other.)
3. Load Balancing for Web Servers
Your web servers determine how you serve information to your software end users, which can be both internal (company employee) or external (customer or key stakeholder) audiences.
To give your current and future users the best experience possible, next you’ve got to determine how to manage incoming traffic for your servers, i.e. how to balance the load of traffic. To prepare for growth and scalability, consider planning for twice or even as many as ten times your current user base.
Ideally, you should route new requests to the server with the least load. This ensures each request receives a response as quickly as possible. If you ever remove the server or it fails, you can just move data to another server. I also recommend storing session data in a key value store service or use webtokens (as described below). Using the key value store requires adding another service that must maintain and scale with your application. While sending a given user to different servers for each request requires more setup, it is the best solution for uptime and performance.
Your less ideal route is to drive a given user to one web server for the life of their session. This is less expensive and complex for application administrators. However, when a server fails or is removed, you lose user session data, and all users on that server face downtime. This strategy doesn’t scale well and creates many issues during periods of growth. However, we see many companies take this route when under budget constraints or without the resources to maintain and monitor multiple web servers.
JSON Web Token Approach
My team and I have also worked with a relatively new method when tackling load balancing – JSON web tokens. Essentially, you encrypt contents of a user session and store them directly in a cookie. Using JSON, you then serialize your data, add an expiration date, and encrypt with a unique, secure key. Make it Base64 encoded, and send it off to the browser. Taking this path reduces the effort you need to put into load balancing and makes it much easier to scale.
4. Data Caching
Next, consider how your web application will cache data. Almost all software has some sort of caching system in place to minimize wait times for users. For example, your system may store monthly summary data, allowing users to make calculations with readily-available data.
In the early stages of most web-based software applications, caching isn’t a big concern; there’s less data to worry about. However, as your business and use of your application grows, caching becomes a major challenge. An inefficient caching strategy slows down the entire system and creates usability issues.
How you tackle this is completely application-dependent. What works for one system may not work for another. I recommend doing whatever you can to summarize your data and cache for optimal performance immediately out of the gate, though. Trying to solve this problem after experiencing growth is painful.
As a note, there’s also a downside to caching. You obviously can’t cache all your data. For example, if users are purchasing something through on online store, your inventory numbers always need to be up to date. You can’t ever cache data that changes this quickly. You must be strategic.
5. Make Adding Features Simple
Of course, for your software to scale at the rate of your business, you’ve got to ensure your development team can add features to meet users’ growing needs.
Build your software to allow for automated testing across functionality. This illuminates bugs with little effort and makes adding new features more manageable – you don’t have to undergo multiple system-wide test every time you add a bit of code here or there. The automated testing takes care of this for you.
Instead, you can rely on unit and integration tests for these additions. Unit tests review very small functions, like as an individual function, while integration tests ensure larger components, such as a whole page. A combination of both works best.
6. Comprehensive Documentation
This is a major issue we see across the board of industries and company sizes. A business will hire a few developers to build out a new system, and over time, the knowledge of an entire critical system sits in the hands of the few. Worst case scenario, someone holds your application hostage. Best base scenario, knowledge transfer suffers as employees come and go, and pretty soon, there are holes in functionality and a list of questions raised.
You can avoid all of this with better documentation. Write down all relevant information and all technical decisions made. Your internal development team should be able to find the critical information they need without digging for it. Go into significant detail when explaining architecture and server configuration details. Your team probably had in-depth discussions before taking a specific route, and your documentation should include explanations and reasoning to avoid the rehashing of old debates.
Remember the point of good documentation – a new member of your development team should be able to add, update, and maintain the software with little training.
This documentation will make it easier to identify challenge areas when adding new features or scaling the application as a whole.
7. Undergo an Annual Review
For most companies, growth happens slowly enough that small pain points in a web application are ignored or easily-handled until, well, they aren’t. We’ve seen many systems in which patches and ad hoc changes were made in the attempt of a band-aid instead of fixing the symptom underneath. By the time a business decides to deal with an issue in its software, it’s a monster of a challenge, and a solution is much more difficult to build.
To avoid these kinds of issues from sneaking up on you, my team and I recommend an annual review of how users leverage your application’s functionality. Do they need new features? Your software should still be meeting their needs and empowering them to accomplish their tasks.
Are they running into UX issues? These problems could indicate you need a new server strategy or database management process.
Unless you experience a huge amount of growth in less than a year, an annual review of your software ensures you scale it appropriately.
8. Use Amazon Web Services
If you’re going to build a web-driven application, you need to do so on a trusted and efficient powerhouse of a platform. Its tools allow software teams to scale their services – up and down for times of feast or famine. In other words, when a company grows quickly, their servers can also do so, and during times of struggle, they can scale down to cost-effective options.
I saved this tip for last, as it always comes off as a pitch for AWS, but my team and I just enjoy the flexibility gained when solutions are deployed to a public cloud. AWS provides everything we need at an affordable cost and the support of a global technical team.
Building for Software Scalability
Every company’s goal is to grow, and your critical systems play a major role. Don’t start a new software project without first taking some time to consider how its architecture and configurations will impact your ability to scale.
Our team has spent the last decade helping companies drive success and growth through scalable software development. We’re happy to support you on your next project. Contact our team for a complimentary estimate and insights into how we would build your next business solution.
