Common architectural patterns in distributed systems

Arpit Bhayani

entrepreneur, educator, and tinkerer

While designing a Distributed System, it is essential to pick the right kind of architecture. Usually, architectures are evolving, but picking the right one at the inception could make your system thrive.

So, here are 4 common architectures in Distributed Systems


To render some information to the end-user, the client contacts the server (holding the data) with a request; 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 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.


This is one of the most widely used topologies out there. Unlike client-server architecture, the clients in a 3-tier architecture are not smart and are stateless. This architecture introduces a middle layer holding the business logic. The client talks to the business layer, and this business layer talk to the server (holding the data).

Most of the web applications are 3-tier applications where your client (browser) talks to the business layer (webserver), which in turn queries the server (database) for the data. The business layer processes and formats the data (optional) and sends it back to the client. The client does not know how the data is being fetched from the server, making it stateless.


As an extension to the 3-tier architecture, the n-tier application is where your middle layer (business layer) talks to another service to get information. This is typically seen when there is 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 architecture is typically a decentralized system wherein no special machines hold all the responsibilities; instead, the responsibility is split across all the machines equally. The peers act as both clients and servers, and they communicate with each other to serve the request.

A couple of popular examples of P2P architecture are BitTorrent and Bitcoin networks. The n-tier architecture can optionally evolve into a P2P, but this evolution is not that popular. Usually, going P2P is a choice that is made during the inception of the service.


Courses I teach

Alongside my daily work, I also teach some highly practical courses, with a no-fluff no-nonsense approach, that are designed to spark engineering curiosity and help you ace your career.

System Design Masterclass

A no-fluff masterclass that helps SDE-2, SDE-3, and above form the right intuition to design and implement highly scalable, fault-tolerant, extensible, and available systems.

Details →

System Design for Beginners

An in-depth and self-paced course for absolute beginners to become great at designing and implementing scalable, available, and extensible systems.

Details →

Redis Internals

A self-paced and hands-on course covering Redis internals - data structures, algorithms, and some core features by re-implementing them in Go.

Details →

Arpit Bhayani

Arpit's Newsletter

Newsletter for the curious engineers

❤️ by 100,000 readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.

Writings and Learnings

Knowledge Base



Arpit's Newsletter read by 100,000 engineers

Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.