Software design is a balancing act where developers work to create the best product within a client’s time and budget constraints.

There’s no avoiding the necessity of compromise. Tradeoffs must be made in order to meet a project’s requirements, whether those are technical or financial.

Too often, though, companies prioritize cost over scalability or even dismiss its importance entirely. This is unfortunately common in big data initiatives, where scalability issues can sink a promising project.

Scalability isn’t a “bonus feature.” It’s the quality that determines the lifetime value of software, and building with scalability in mind saves both time and money in the long run.

What is Scalability?

A system is considered scalable when it doesn’t need to be redesigned to maintain effective performance during or after a steep increase in workload.

“Workload” could refer to simultaneous users, storage capacity, the maximum number of transactions handled, or anything else that pushes the system past its original capacity.

Scalability isn’t a basic requirement of a program in that unscalable software can run well with limited capacity.

However, it does reflect the ability of the software to grow or change with the user’s demands.

Any software that may expand past its base functions- especially if the business model depends on its growth- should be configured for scalability.

The Benefits of Scalable Software

Scalability has both long- and short-term benefits.

At the outset it lets a company purchase only what they immediately need, not every feature that might be useful down the road.

For example, a company launching a data intelligence pilot program could choose a massive enterprise analytics bundle, or they could start with a solution that just handles the functions they need at first.

A popular choice is a dashboard that pulls in results from their primary data sources and existing enterprise software.

When they grow large enough to use more analytics programs, those data streams can be added into the dashboard instead of forcing the company to juggle multiple visualization programs or build an entirely new system.

Building this way prepares for future growth while creating a leaner product that suits current needs without extra complexity.

It requires a lower up-front financial outlay, too, which is a major consideration for executives worried about the size of big data investments.

Scalability also leaves room for changing priorities. That off-the-shelf analytics bundle could lose relevance as a company shifts to meet the demands of an evolving marketplace.

Choosing scalable solutions protects the initial technology investment. Businesses can continue using the same software for longer because it was designed to be grow along with them.

When it comes time to change, building onto solid, scalable software is considerably less expensive than trying to adapt less agile programs.

There’s also a shorter “ramp up” time to bring new features online than to implement entirely new software.

As a side benefit, staff won’t need much training or persuasion to adopt that upgraded system. They’re already familiar with the interface, so working with the additional features is viewed as a bonus rather than a chore.

The Fallout from Scaling Failures

So, what happens when software isn’t scalable?

In the beginning, the weakness is hard to spot. The workload is light in the early stages of an app. With relatively few simultaneous users there isn’t much demand on the architecture.

When the workload increases, problems arise. The more data stored or simultaneous users the software collects, the more strain is put on the software’s architecture.

Limitations that didn’t seem important in the beginning become a barrier to productivity. Patches may alleviate some of the early issues, but patches add complexity.

Complexity makes diagnosing problems on an on-going basis more tedious (translation: pricier and less effective).

When the software is customer-facing, unreliability increases the potential for churn.

Google found that 61% of users won’t give an app a second chance if they had a bad first experience. 40% go straight to a competitor’s product instead.

Scalability issues aren’t just a rookie mistake made by small companies, either. Even Disney ran into trouble with the original launch of their Applause app, which was meant to give viewers an extra way to interact with favorite Disney shows. The app couldn’t handle the flood of simultaneous streaming video users.

Frustrated fans left negative reviews until the app had a single star in the Google Play store. Disney officials had to take the app down to repair the damage, and the negative publicity was so intense it never went back online.

Setting Priorities

Some businesses fail to prioritize scalability because they don’t see the immediate utility of it.

Code

Code should be written so that it can be added to or modified without refactoring the old code. Good developers aim to avoid duplication of effort, reducing the overall size and complexity of the codebase.

Applications do grow in size as they evolve, but keeping code clean will minimize the effect and prevent the formation of “spaghetti code”.

Scaling Out Vs Scaling Up

Scaling up offers better performance than scaling out. Everything is contained in one place, allowing for faster returns and less vulnerability.

The problem with scaling up is that there’s only so much room to grow. Hardware gets more expensive as it becomes more advanced. At a certain point, businesses run up against the law of diminishing returns on buying advanced systems.

It also takes time to implement the new hardware.

Because of these limitations, vertical scaling isn’t the best solutions for software that needs to grow quickly and with little notice.

Scaling out (or “horizontal scaling”) is much more widely used for enterprise purposes.

When scaling out, software grows by using more- not more advanced- hardware and spreading the increased workload across the new infrastructure.

Costs are lower because the extra servers or CPUs can be the same type currently used (or any compatible kind).

Scaling happens faster, too, since nothing has to be imported or rebuilt.

There is a slight tradeoff in speed, however. Horizontally-scaled software is limited by the speed with which the servers can communicate.

The difference isn’t large enough to be noticed by most users, though, and there are tools to help developers minimize the effect. As a result, scaling out is considered a better solution when building scalable applications.

Use load balancing software

This software uses an algorithm to spread the workload across servers to ensure no single server gets overwhelmed. It’s an absolute necessity to avoid performance issues.

Location matters

Scalable software does as much near the client (in the app layer) as possible. Reducing the number of times apps must navigate the heavier traffic near core resources leads to faster speeds and less stress on the servers.

Edge computing is something else to consider. With more applications requiring resource-intensive applications, keeping as much work as possible on the device lowers the impact of low signal areas and network delays.

Cache where possible

Be conscious of security concerns, but caching is a good way to keep from having to perform the same task over and over.

Lead with API

Users connect through a variety of clients, so leading with API that don’t assume a specific client type can serve all of them.

Asynchronous processing

It refers to processes that are separated into discrete steps which don’t need to wait for the previous one to be completed before processing.

For example, a user can be shown a “sent!” notification while the email is still technically processing.

Asynchronous processing removes some of the bottlenecks that affect performance for large-scale software.

Limit concurrent access to limited resources

Don’t duplicate efforts. If more than one request asks for the same calculation from the same resource, let the first finish and just use that result. This adds speed while reducing strain on the system.

Use a scalable database

NoSQL databases tend to be more scalable than SQL. SQL does scale read operations well enough, but when it comes to write operations it conflicts with restrictions meant to enforce ACID principles.

Scaling NoSQL requires less stringent adherence to those principles, so if ACID compliance isn’t a concern a NoSQL database may be the right choice.

Consider PaaS solutions

Platform-as-a-service relieves a lot of scalability issues since the PaaS provider manages scaling. Scaling can be as easy as upgrading the subscription level.

Look into FaaS

Function-as-a-service evolved from PaaS and is very closely related. Serverless computing provides a way to only use the functions that are needed at any given moment, reducing unnecessary demands on the back-end infrastructure.

FaaS is still maturing, but it could be worth looking into as a way to cut operational costs while improving scalability.

Don’t forget about maintenance

Set software up for automated testing and maintenance so that when it grows, the work of maintaining it doesn’t get out of hand.