Introduction

I believe it is essential to be able to scale a system, as more and more people use the internet, and the data we operate with grows in tandem with them. If we want to provide services that satisfy clients’ needs, once we grow, it is mandatory to know how to architect the system so it can adapt to the business needs.

Additionally, it is pretty interesting because it provides an opportunity to see the entire picture. For example, most of my experience is in the front‑end, and I have not seen many scalability issues there, except team‑wise, so a lot of fun things have been outside my horizon, such as infrastructure and whole system architecture. There is a saying that when we talk about scaling, we have two types of engineers: one who knows a lot and the other who knows nothing. I am from the latter, and I am keen to learn more.

The resources I am using right now are these two books:

• Web Scalability for Startup Engineers
• Designing Data-Intensive Applications

What is scalability?

Scalability is a term used to evaluate how well a system responds to high traffic loads. Traffic can be described using different parameters for various systems, depending on their specific requirements. Some of these parameters include how well the system will handle increased data and associated operations, such as writing, reading, and searching, as well as the number of active users simultaneously and their interaction rate.

Of course, scalability is not only about the technical aspect but also about people. If we want to maintain our pace and stay ahead, the system we develop needs to put effort into this aspect as well. We can’t expect that once we have the technical solution, it will be well‑supported by the team that initially built it, because obviously, we have grown, and this brings new requirements, such as getting more people into the team and establishing good processes around them. Usually, more people = more problems if not managed well—at least that’s what I have seen, and most of my experience is in startups. Organizational scalability is not something I plan to delve into for now.

A quick real‑world example

At my previous company, we developed software for online payments, similar to Stripe, but built on top of the blockchain and utilizing stablecoins. Now, imagine visiting a website and using our product, but at the same time, 100 other people do the same. However, our system’s capacity is only 100 concurrent users. If you are user 101, you will wait—or worse, see a failure, which for a payment service provider is unacceptable. When I started reading about scalability, another example came to mind: a platform for online tickets in my country that struggles to manage high traffic spikes. I spent half a day getting a ticket just because the system constantly failed.

I will be using this diagram for the next blog post because it groups the different layers included in a system very well. The next thing we will examine is the Front Layer and its ingredients.

Taken from Artur Ejsmont’s book - Web Scalability for Startup Engineers