May 5, 2020
Strategy and Innovation
Reading Time
4 min

The Dos and Don'ts of Scalable Architecture

How to design scalable architecture? Rather than focusing on specific brands or tools, keep a set of design principles in mind.
A glass cube with lines and a white square.
Share on X/Twitter
Share on LinkedIn
Share on Facebook
Scalability is having its moment in the sun. After being dismissed as something to think about down the road, leaders have begun to realize how important it is to plan for scalability from the start. This strategy puts companies in a solid position to take advantage of unexpected growth without taking a hit on service quality.

As scalability grows in importance, some common themes are beginning to emerge. Companies are realizing their legacy architecture is too rigid to handle a sudden increase in workload, and adjusting for growth is more expensive than they’d planned.

Read on to find out where they’re going wrong and how to learn from their mistakes.

Principles of Scalability

Simply put, scalability is the ability of a system to handle sudden changes in workload without negatively impacting performance. It’s usually broken down into three areas.

  • Availability: The system should be available for use as much as possible (ideally, always). Uptime percentage has the most immediate effect on customer experience. After all, it doesn’t matter how useful an application is if no one can access it.
  • Performance: The system must maintain a high level of performance even under heavy loads. Speed is critical to providing a good user experience, and customer experience is fast becoming the most important factor in preventing churn.
  • Reliability: The system must accurately store, retrieve, and edit data under stress. It should return the most current data on request without defaulting to old or inaccurate data or failing to record new data. Unlike availability and performance, reliability builds good customer experiences in the long run rather than just at the moment.

How to Design Scalable Architecture

Rather than focusing on specific brands or tools, keep a set of design principles in mind.

Don’t use vertical scaling

Vertical scaling is scaling by adding more powerful resources (ie, more RAM). It’s secure and fast under light loads, but it does not scale well at all. More powerful equipment is increasingly more expensive, and there’s only so high it can scale. Plus, vertical scaling tends to lock companies into technology without an easy path to modernization. It’s unavoidable sometimes- especially when dealing with many atomic transactions or high-grade security concerns- but whenever possible don’t scale up.

Do favor horizontal scaling

Horizontal scaling involves adding more nodes to a distributed network (ie, adding another server) rather than more powerful nodes. It’s the fastest, most cost-effective way to scale since increasing its capacity is as simple as increasing the size of the network.

Don’t default to physical servers

Physical servers are only really valuable for multinational companies with high security requirements and a lot of usable capital. For the vast majority of companies, they’re a waste of time and money. Servers are expensive to build, maintain, and secure. New projects have to be put on hold while waiting for the storage to be finished. Plus, there’s always the risk of hardware becoming outdated.

Do take advantage of cloud storage

Cloud storage puts data in logical pools spread out over a number of servers. Vendors then sell access to that storage through subscriptions. This model takes the burden of security and hardware maintenance off companies and allows them to purchase only what is needed at launch while remaining prepared for rapid scaling. Because the cost is spread out like a utility instead of an upfront investment, the project can reach ROI faster and begin to pay for itself much sooner.

Don’t create unnecessary bottlenecks

Bottlenecks form when multiple processes require the same resources to proceed. Plan the application architecture to maximize the availability of resources that will be in high demand. What does that look like?

  • Caching stores data closer to end-users. It’s an excellent way to facilitate the return of data that are needed often but changes rarely.
  • Non-blocking IO calls serve more requests with limited resources by letting processes continue before a slower one has finished.
  • Load balancing software intelligently spreads the workload across the network to reduce pressure on anyone single node.
  • Redundancy safeguards against lost data as well as provide more access to high-demand resources.

Do consider a microservice architecture

Microservice architecture breaks large software into smaller pieces that can operate independently of each other. When one node is in high demand others can work without adding to its load. Fault isolation is a major advantage of using microservices. If something does go wrong, the majority of the system can usually remain up while that part is repaired.

A Final Thought

Choosing components that lend themselves to a scalable architecture saves both time and money. The slightly higher cost of emphasizing scalability during development is offset by greater agility and lower operational costs.

Concepta specializes in the kind of scalable architecture businesses need to meet the demands of digital transformation. Set up a complimentary appointment to discuss how to position your next application for success!


Have an idea?

Let's bring it to life. Request your free consultation today.
Schedule Consultation