Part 1: Taking your Basic System Architecture into the World of Scalability
The campaign you just launched went very well, but your system couldn’t handle the load. How can you scale effectively, and most importantly, what part of the system needs to be scaled and where? And what is scaling anyway?
The very nature of this inquiry prompts a deep dive into the complexities of system architecture. Scaling in the context of computer systems or applications refers to the ability to handle an increased workload or demand by adjusting the resources or capacity of the system. It involves optimising the infrastructure to accommodate growth, whether in terms of user traffic, data volume, or processing requirements. Scaling can be achieved through two main approaches: vertical scaling (increasing the power of existing resources) or horizontal scaling (adding more resources to distribute the load). The goal of scaling is to ensure that the system remains responsive, reliable, and performs well under varying levels of demand, ultimately supporting the growth and success of the application, service and your business.
The initial step is to pinpoint the source of the system performance issue. Is it an influx of traffic overwhelming your system? Is the database struggling to handle the load? Or is the server overloaded, lacking sufficient processing power or memory? It’s crucial to assess the specific area within your infrastructure where the problem originates so that the least invasive and most effective solution can be diagnosed.
Let’s assume that your system infrastructure is cloud-based. After all, it is the year 2023 ;) Every system has its unique foibles and nuances. To maintain a more generic approach, the primary objective should be to decouple key system dependencies from the main system architecture. For instance, consider a monolithic system design.
A monolithic system design refers to a traditional architecture where all components of an application are interconnected and interdependent. If your system is using any of these, then it is highly likely that you have a monolithic system architecture:
In this design, the entire application is built as a single, cohesive unit, typically comprising of the user interface, application logic/middleware, and database. While this approach simplifies development and deployment, it can present challenges in terms of scalability, flexibility, and maintenance. Decoupling, on the other hand, involves breaking down the system into more modular and independent components, allowing for greater flexibility, easier maintenance, and the ability to scale specific parts of the system independently.
As a suggested initial decoupling exercise, its advisable to move the database and assets storage to an external cloud-hosted solution. If your system is running on Google Cloud, and you are using a MySQL database, you would migrate your system’s database from your GCP compute VM to a managed GCP MySQL instance. As for your assets, you would stop storing them on your GCP compute VM and instead, upload them to GCP Cloud Storage. Another common culprit for causing storage issues are system logs which can also be externally stored in the same location.
Both of these options offer “out of the box” scalability, recoverability, and uptime. But keep in mind that when implementing auto-scaling for storage capabilities, it’s essential to set reasonable upper limits to prevent unexpected charges.
Generally speaking, based on our past experiences, these changes alone have resolved a high number of initial scalability and downtime issues. Concerns related to virtual machine resources, such as CPU and RAM, will be addressed in the upcoming Part 2. In that segment, we’ll delve deeper into on-demand vertical scalability, exploring specific triggers to make your system more responsive and robust in the face of changing loads. Our focus will primarily be on non-serverless systems design.
This article was co-authored with Tony Collins. Stay tuned for more insights!
