Why You Should Think of Software Scalable Architecture

Historically, business owners assume that it’s excessive to go through all the development details for their software projects. A business considers this process as extremely tedious due to the complex explanations of changeable technologies and system requirements from the developers. For this reason, when it comes to software architecture scalability, business representatives prefer to have a general dialog with developers cutting off all the technical details at the same time.

If business owners start speaking using the developer’s lingo, the quality of systems multiplies several times over. In particular, this could help avoid many problems while developers create complex server-based solutions.

How can a business maintain close contact with software developers and understand the details of system scalability?

Let’s consider a situation when a project for developing a new system begins. We’ve devised 5 questions that help simplify negotiations and direct them onto the right track.

5 main software scalable architecture questions

From our experience, developers usually ask 5 main questions when they talk about system scalability:

1. Does a business understand the features of the planned system?

2. What are the typical actions of system users?

3. What bottlenecks does the system have? Which part of the system has the heaviest load?

4. What is more crucial for the system: fault tolerance or high performance?

5. Where does the need for scalability appear?

We’d like to take a closer look at each of the five questions and find out what the benefits of comprehensive answers from business representatives are.

Does a business understand the features of the planned system?

Behind the scenes:

Scalability is the ability of a system to deal with the growing load by upgrading the existing hardware or by adding extra new resources. The system has to keep an appropriate architecture to allow the latter.

In other words, when backend-developers start system development, they need to understand if it is possible to scale a system in the future, meaning the increase in its operational features. Thus, they require knowledge of the plans business owners have regarding system characteristics and further development.

Example:

Let’s imagine that an owner of an online service for buying air tickets makes a schedule of the planned website traffic. The schedule can be for a day, a week, a month, a quarter, or a year. It can cover the types of users and user activity, as the required time of a system answer. Using this plan, developers can reveal the times when a load on the website becomes more intensive. For example, it can happen closer to the weekend. Additionally, a business representative can include in the schedule the points of a peak load such as holidays, school vacations, and promo campaigns.

Peak loads in the architecture shouldn’t affect the system’s performance, so it is important to plan them. One of the best ways is a graphic presentation of the system load.

Takeaways:

Formulate clear project goals and make a plan or a diagram for forecasting website traffic. It is also preferred to point out time intervals.

Developers ask questions about system abilities not because they are simply curious. They have to foresee opportunities for server growth. If a business plans to win the world, it’s necessary to state the goals clearly. Let’s say when 10,000 unique visitors come to a website with an average daily audience of 300 users, the system has to survive it.

What are the typical actions of system users?

Behind the scenes:

Forecasting typical actions allow developers to analyze the load on the system. This is also an opportunity to see if system users will upload large files or will require live-chat support and other functions. How functionality is going to spread among web servers depends on the typical flow of user actions.

Example:

We can turn to the example of launching a mobile app. The web-based mobile app for arranging meetings includes an option to upload photos. Developers did load testing using a medium-sized user photo. However, just after the app launch, users began to upload pictures in their original size. When the number of users and pictures exceeded the web server’s abilities for data storage and processing, the system didn’t survive a load and began to crash.

Takeaways:

If you’d like to prevent the adverse effects of system instability, describe the scenario of typical actions in great detail. In particular, consider two points:

• How you want a user to interact with the system
• How it’s going to be in reality

What bottlenecks does a system have? What part of the system has the heaviest load?

Behind the scenes:

Any complex information system can include at least a couple of bottlenecks. A bottleneck is a pressure point that experiences the highest load in a system during specific moments. When a developer knows about possible bottlenecks in the system, he/she can adjust the system’s work if a server crashes. This helps to avoid the loss of potential users when there are peak loads.

The problem of finding bottlenecks doesn’t relate to system scalability. However, it’s best to keep in mind anyway. If a developer doesn’t define where the bottlenecks are, it can blow any progress in scalability. Even when everything goes well in system scalability, it is necessary to analyze the architecture in order to prevent the appearance of bottlenecks.

Example:

An inlet point can be a bottleneck. For instance, if a large number of users open up a website simultaneously, it cannot withstand the high load and nobody continues to use the site.

Another bottleneck example is an insufficient channel width. Imagine that one of the pictures in the photo storage quickly gains in popularity. Several thousands of users open this popular photo, but the capacity of the web server is not intended for this amount. As a result, the upload of the photo stalls and influences negatively on users.

Takeaways:

Only purposeful testing can give a detailed answer to the question of where the bottlenecks are. However, it doesn’t mean that it’s impossible to evaluate potential bottlenecks.

• Make a list of the basic parts of the system. Highlight the most vulnerable places according to your experience.
• Discuss the list with the development team. The experience of technical professionals can most likely help you with new ideas.

What is more important for the system:
fault tolerance or high performance?

Behind the scenes:

Different systems require different approaches. Developers need to know what the main task is: fault tolerance or high performance, or if both are required.

The fault tolerance issue is very cute and it doesn’t have a unique solution. It relates to the ability of a system to respond every time when a server suffers from a failure. In other words, a user doesn’t achieve the desired result. For instance, he or she cannot go to the other page of the website or pay for the services via an app. If it’s unclear what’s going on, there is a high probability a user will refuse to use the service again.

In order to avoid the loss of users, it’s better to protect the system. For example, if a website doesn’t react to user requests or the session was broken off, it’s possible to send users a message with brief information about the event and some recommendations on what to do.

High performance relates to the ability of the system to withstand thousands of users and simultaneously show a good response time. In other words, the system speed is important. If a user spends a lot of time filling out the form and has to wait for pages to load slowly every time, it will negatively influence their attitude to the company.

Example:

Let’s imagine that a bank operator runs a customer query for the receipt of a loan and fills out the data in a system. The session crashes and the system stops answering to the operator at the same time. The data is lost and the operator doesn’t have another way to access the system. Thus, the operator asks a customer to wait while the system will recover or to come back the next day. The customer has spent a lot of time and they now aren’t satisfied with the situation. This means that there is a failure in the system. Whereas customer loyalty depends on the system’s resistance to similar failures.

The problem of possible failures can be solved in different ways if fault tolerance is foreseen. For instance, data can be saved on a duplicate server of the system. Then the bank operator can simply connect to the backup server and continue to work. The other way is when the data is not saved but there is an opportunity to begin a new session. Therefore, the bank operator offers the customer to fill out the information again.

There are billions of solutions to these situations. It is much easier to decide whether data loss during the session is important or what tasks are required for the system.

Takeaways:

Identify what issue is more critical because it helps developers know in advance what should be taken into account first. When developers get a clear purpose, they can list the recommendations for a customer.

Where does the need for scalability appear?

Behind the scenes:

Business owners have expectations that developers have to know their business niche very well and understand from the very beginning whether their information systems need scalability or not. Usually, these expectations are false. In practice, developers focus on specific goals for a software project. They want to define where the need for system scalability appears. It can be a large volume of data that should be kept and processed somewhere or complex computation processes and multistage operations that are required in a particular moment.

Example:

Let’s say, a social network plans to increase the number of users and start a marketing campaign on the internet for this purpose. The social network representatives see that they need to take into account the number of simultaneous visits to the network and increased load during the campaign. The large increase in visitor numbers can influence system performance. When the source of the need becomes clear, developers can move to the solution of the specific task.

Takeaways:

Answer the question of what do you mean by the system scalability in the current software project. Distinguish the meanings:

• There are 10,000 users at the base and you need to extend the server abilities for data storage
• About 10,000 users visit your website simultaneously and the server requires to enlarge the information resources

You choose which approach is better for the system clustering based on your answer. In other words, developers can distribute the load between different servers in accordance with the business needs.

System scalability is a necessary solution for the problem of an increasing load when a business grows. This specific ability provides the extension of system features using new information resources. In fact, scalability allows supporting reaction speed and the general performance of the system with a growing number of operations, transactions, or users.

The need for scalability motivates business owners and developers to find ways for effective discussions. If the first and the second speak one language, they get a common understanding of the development strategy, function growth, and increases in the technical features of the system.