Distributed System

Before going to the Distributed System we’ll see one example of a startup. Suppose you created an API that is super helpful for investing in cryptocurrency. This is API predicts the price of cryptocurrency (Bitcoin, Ethereum, Dogecoin).

The user wants to access this website, They are willing to pay for it. So you host this website on a single server.

As you can see in the figure, the user sends the request for Dogecoin cryptocurrency price prediction for a specified date and the server serves the user by sending the response.

But our users start increasing and the server is reaching its maximum potential we need to scale the system, So we’ll upgrade the RAM and CPU of the existing system. By this, we optimize the process and increase throughput via the same resource. This is called Vertical Scaling.

Also, we can do is Preparing beforehand at non-peak hours. So if the system has continuous traffic and our server is engaging with the update the developer sends, Then the user may get a bad experience with the system. So What we can do is Instead of releasing the update at peak hours we can release an update in non-peak hours so that the update will be rolled out perfectly and users will use the service seamlessly. It is also called Preparing and crone-job.

Now, Suppose our only server which is serving to the user got crashed due to internal failures then our startup will fall apart as we can’t serve users anymore. To overcome this issue we always consider border cases like this. So in this scenario, we’ll get a backup server and avoid the single point of failure. It is called master-slave architecture.

If the startup is growing daily, then we better make that backup server permanent(full time). In fact, get more servers(Resources). This is called horizontal scaling.

Expansion:

At this time our startup goes really big we have 10 servers. 3 for Bitcoins, 4 for Ethereum, and 3 for Dogecoin. So we’ll route all the bitcoin requests to the 3 servers and respectively. This is Expansion.

We make available the servers in this way that the cryptocurrency with the highest traffic has a larger number of servers. Here is a diagrammatic view of expansion.

But still, if the electricity goes down in the area our all servers will be down. On that day we’ll not have a business. So we can’t put our system at a single point of failure.

So we’ll buy another hardware(servers) and set it up in a different location, which is somehow far from the existing location. The number of servers will be less but at least we have a backup now.

Distributed System(Partitioning)

So the new problem is we should be able to route the request from a user to different servers of different locations.

Any request which is local to the new location server(Geographically) will be served by new servers, So this will give us an advantage of low latency. As it gives users quick response time because of local servers.

The above diagram explains the new backup system which is having a different geographical area from the existing system.

Load Balancer

Now, We need something that will route our request to either system1 or System 2. here the Load Balancer comes. It efficiently distributing incoming network traffic across a group of backend servers, also known as backend pool.

Load Balancer will get real-time updates from systems i.e. System1, System2, So by this it can judge on which system the request will go.

Decoupling

Separation of responsibility, instead of same managing the systems and API/CDN’s. We’ll separate that out.

Separate out concerns, so that we can handle separate systems more efficiently.

Logging and Metrics Calculation

Here we check at what time what happens, or what is the next event should occur.

• Analytics
• Auditing
• Reporting
• Machine Learning

Extensible

As engineers, we should consider the corner cases while designing the system. As ideally we shouldn’t rewrite or repeat the code to serve different purposes.

In our example, API shouldn’t know that it is delivering the price of bitcoin it could be stock value the next day, or something else.

All we did is called the High-Level design.

High-level design (HLD) explains the architecture that would be used to develop a system. The architecture diagram provides an overview of an entire system, identifying the main components that would be developed for the product and their interfaces.