Architectures in Distributed Systems
Distributed System has been a buzzword for quite sometime now. Everyone wants to build a system or application that is scalable, robust and secure. So, let us learn more about Distributed System and their architectures.
While designing a Distributed System, it is extremely important to pick the right kind of architecture at the inception to make your system thrive. So, let us discuss four most common architectures in Distributed Systems.
Client-Server
In this, the client contacts the server with a request and the server sends back the data requested. The client is smart enough to understand how to request the data, post-process it, format it, and then serve it to the end-user.
This kind of architecture is not much common in our day-to-day web applications. Still, it is prevalent when multiple services share a common database server and request data directly from the database.
Three-tier
Three-tier is one of the most widely used architecture. Unlike client-server architecture, the clients in a three-tier architecture are stateless. This architecture introduces a middle layer which holds the business logic. The client interacts with the middle layer, and this middle layer interacts with the server which holds the data. The middle layer processes and formats the data and sends it back to the client. The client does not know how the data is being fetched from the server, making it stateless. Most of the web applications are three-tier applications.
N-tier
N-tier architecture is also referred as multitier architecture. It is an extension to the 3-tier architecture, the n-tier application is where your middle layer interacts with another service to get information. This is typically seen when there are multiple independent business logic in the system.
A classic example of an n-tier architecture is Microservices based architecture. Each service is responsible for its information, and the service communicates with other services to get the required data. Thus, a 3-tier application typically evolves into an n-tier application.
Peer-to-Peer
Peer-to-peer architecture is typically a decentralized system. The tasks or workloads are divided among peers. The peers can act as both clients and servers, and they communicate with each other to serve the request.
Popular example of P2P architecture are BitTorrent and Bitcoin networks.
Benefits and challenges of distributed systems
Benefits :
- Horizontal Scalability — Since computing happens independently on each node, it is easy and generally inexpensive to add additional nodes and functionality as necessary.
- Reliability — Most distributed systems are fault-tolerant as they can be made up of hundreds of nodes that work together. The system generally doesn’t experience any disruptions if a single machine fails.
- Performance — Distributed systems are extremely efficient because work loads can be broken up and sent to multiple machines.
However, distributed systems are not without challenges. Complex architectural design, construction, and debugging processes that are required to create an effective distributed system can be mind-boggling.
Challenges :
- Scheduling — A distributed system has to decide which jobs need to run, when they should run, and where they should run. Schedulers ultimately have limitations, leading to underutilized hardware and unpredictable runtimes.
- Latency — The more widely your system is distributed, the more latency you can experience with communications. This often leads to teams making tradeoffs between availability, consistency, and latency.
- Observability — Gathering, processing, presenting, and monitoring hardware usage metrics for large clusters is a significant challenge.
So, now we have some idea on what Distributed Systems actually are and what they do. In the next posts, I will discuss in detail about these architectures. In this post, I wrote lot of theoretical explanation with no diagrams or sample code. I will try to include more visuals in my next posts onward. Stay Tuned. Happy Learning! :)
