Art of scalability

I will write two or three articles about scalability. I will call the first one ‘Scalability principles’ and I will speak about what is the scalability and its principles, and then I will move to Scalability pattern, anti-pattern, and guidelines in next posts. So let’s start.

Go to : Part 1- Scalability principles

Go to : Part 2 – Scalability guidelines part 1

Scalability Guidelines for building scalable software system – part 2:

Requirements must be known

To build successful software system, you need to know what your goals are what you are aiming for. While the functional requirements are often well-known, it’s the non-functional requirements that are usually absent or ignored.
If you do genuinely need to build a piece of software that is highly scalable, then you need to understand the next types of things:

• Target average and peak performance (Response time, latency, etc)
• Target average and peak load (Concurrent users, etc)
• Acceptable limits for performance and scalability

After you know and understand the requirements well, now you can start design and build the solution. The design, all performance and scalability decisions should be backed up by evidence, and this evidence should be gathered and reviewed from the start of the project and on a continuous basis thereafter. In other words; set measurable goals throughout the system, verify and measure the real performance and consider performance at all stages of the project.

Also you should consider the performance in every development step (Designing, Developing, and Testing). You can’t simply say it’s important to make the design the solution to be fixable and in the development we can optimize the code for the Scalability. If you do this you will pay at the end. You should think about the performance in every development step.

Avoid Distributed Transactions

We all know that distributed transactions have higher cost, actually this point make be back to the partition speak. You should know how to partition your application, and your data, because bad partition will make you need to perform distributed transaction.

Finally advices:

• Start with well understanding requirements.
• Design the application well, and all important decisions should backed up by evidence.
• Consider the next points:
  • Partition your application into small loose-coupled prices, if you do this, then you will be able to optimize and scale every piece independently.
  • Move Processing to Asynchronous Flows.
  • Cache the data.
  • Optimize the code.
• Also consider the Verticale Scalability.