Do you know there are 7 differents ways to scale your web architecture?
Let me tell you a story about scalability. Anybody can understand, so prepare your coffee or tea and enjoy the reading.
Consider a baker. To make the best artisan bread, you have to know exactly the right recipe of the bread and when to put it in the oven just at the right time and temperature. That’s a unique skill that not just anyone can do. Being the best at it allows you to charge a hefty premium and make more money per-bread.
However, you’re limited in how much more you can charge because, eventually, the second best guy will be good enough. You can’t open a second location because the baker at that location doesn’t do it as well as you do and therefore can’t justify the obscenely high price you do.
A business that is perfectly scalable doesn’t depend on any one particular person, place, or resource. It works anywhere and everywhere, and only requires $I to get started, and can expect J% return, provided you find people that are generally good enough to do their jobs and fit into your model.
What is Scalability?
Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system.
Brother, believe me you gone laugh when you say scalable. And everyone in your neighborhood hears something different. A programme or architectural design can be scaled in several ways. These are the two largest dimensions:
- Vertical scalability
- Horizontal scalability
Vertical Scalability
Algorithmic complexity, programming language selection, and execution environment are the main factors to be taken into account here. Vertical scalability occurs when a programme is written using Quicksort, Bubble Sort, and Hash Tables. Scaling up occurs when you get a new iPhone because your previous one became sluggish.
The easiest method for vertical scaling or scaling up is to purchase a machine with greater power. One operating system can manage a large number of CPUs, RAM chips, and discs, and a fast connection lets any CPU reach any location on the memory or disc. All the parts of this shared-memory architecture may be seen as a single computer. A shared-memory architecture has the drawback that cost increases faster than linearly.
Additionally, a computer twice the size cannot necessarily manage a load twice the size because of bottlenecks. Although high-end computers feature hot-swappable components, which allow you to replace drives, memory modules, and even CPUs without shutting down the machines, shared-memory architecture is unquestionably restricted to a particular geographic area.
Another strategy is the shared-disk architecture, which makes use of several computers with distinct CPUs and RAM, but saves the data on a shared array of discs that are connected through a quick network. This architecture is suitable for some data warehousing applications, although the shared-disk approach’s scalability is constrained by contention and the cost of locking.
Horizontal Scalability
Developer experience, server management, task coordination, node connectivity, and cost are the main factors to be taken into account. How much work can we accomplish with several machines operating together? this is the question that you have to ask yourself when you’re thinkig about scaling out.
Horizontal scalability or scaling out occurs when big jobs are divided into smaller ones. Horizontal scalability is what you argue about when AWS ECS and Docker containers are at odds. Horizontal scalability is achieved by managing 13 servers, 8 load balancers, 5 queues, and 3 kubernetes pods.
Shared-nothing systems have become quite popular. Each computer or virtual machine executing the software application is referred to in this method as a node. CPUs, RAM, and drives are used separately by each node. Any node coordination is carried out using a traditional network at the software level. A shared-nothing system doesn’t require any specialised hardware, so you may employ whichever machines offer the best value for your money. By distributing data over several geographical areas, you may be able to decrease user latency and maybe tolerate the destruction of an entirely datacenter.
You don’t have to be operating at Amazon scale using cloud deployments of virtual machines; a multi-region distributed system is now accessible for even tiny businesses.
You must be aware of the limitations and trade-offs that arise in a distributed system if your data is spread over several nodes; the system cannot magically hide these from you. Even though a distributed shared-nothing architecture offers numerous benefits, it often also adds to application complexity and occasionally restricts the expressiveness of the data models that may be used. In some circumstances, a straightforward single-threaded software can outperform a cluster with more than 101 CPU cores. Shared-nothing systems, however, have the potential to be quite strong.
These are 7 differents ways to scale your web architecture.
- Database Replication.
- Database Sharding (Partitioning)
- Database Caching
- Load Balancer
- Content Delivery Network (CDN)
- Stateless Architecture
- Message Queues
Thanks for reading. If you loved this article, feel free to hit that follow button so we can stay in touch.
This article is possible because of these references. some external links in this post are affiliate.
