Last week, we had a lecture on ‘Quality Attributes’ for Software Architecture. Basically quality attributes are properties of the system that can tell you how good or bad the system is performing. Modifiable, Re-usability, Performance, Security, Availability, Usability… and Scalability is one of them. Here is something related to the scalability of a system which I found.
https://miro.medium.com/max/1126/0*woG3aeCME7_k3wGU.
While researching on this topic ‘Scalability’, I found this book called “The Art of Scalability” by MARTIN L. ABBOTT and MICHAEL T. FISHER. And something interesting in it was this model called “The Scale Cube”. Basically what it is, is a representation on how a system could be scaled. Scalability in terms of a system is its ability to scale itself on different conditions without affecting its qualities like the performance.
As in the diagram: 3 axes on the cube (x,y,z) denotes three different ways how the system could be scaled. The X-axis is scaling the application by balancing the load (load balancing) using something the load balancer and having clones of the application behind it. What the load balancer does is it directs the incoming traffic into selected clones based on the active traffic on each of them. For example in database related application, you distribute the queries to copies of databases. In each case, each and every instance of the database or the application would associated only with 1/N load where N is the number of available copies.
The Y-axis decomposed the application into multiple services where coupling is a minimum. A service would be responsible for only a single task. In most of the cases, these services would communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP (Advanced Message Queuing Protocol). They could be developed and deployed independently due to their very low de-coupled existence. Examples for such service you would find within an application may be the User Authentication service, the Stock Management service … etc. Related: Microservices Architecture.
The Z-axis, as in X-axis, runs copies of the application in different servers. But this time, each copy would be responsible for only a specific section of the application and related traffic would be routed to designated server. Database-wise the data is partitioned and distributed among these servers based on the functions each of them are responsible for.
In each case there are pros and cons. The Z-axis has advantages like, less memory usage, less responsibility per server, ease of fault isolation. But, it results in downfalls like the higher complexity of the application and partitioning data.
Top comments (0)