A complete guide to all the building blocks in System Design. https://t.co/Y1yHWxEdKf

---

System Design Essentials - 1

This article is part of a 3-part series on the essential concepts you will use when designing a software system. Once you understand each one clearly, you can combine them to solve almost any problem.

Every topic here is a core building block in system design. Each one has a short explanation, a simple diagram, the problem it solves, and the trade-off behind it.

Read the article end to end and understand each block. After that, system design problems get much easier, whether you are starting from scratch or preparing for interviews.

1. Client-Server Architecture

Client-Server Architecture

Client-Server Architecture

Client-Server Architecture is the foundation for almost every system. A client sends requests, and a server processes them while talking to a database. When the client connects straight to a database, it’s called 2-tier. Once you add a dedicated application server between the client and the database, it becomes 3-tier, the setup most modern apps actually use. Concepts like caching and scaling sit on top of this basic client-server relationship.

2. Vertical Scaling vs Horizontal Scaling

Scaling a system means improving the capacity of the system to handle more load without breaking. Systems can experience load in the form of more requests, more database access, etc. There are two ways to scale a system

Vertical Scaling vs Horizontal Scaling

Vertical Scaling vs Horizontal Scaling

Vertical Scaling

In this type, we add more power or improve specs on our existing system. This means

• Adding more RAM

• Adding more Compute Power

• Adding more Storage

Vertical Scaling is great in the initial days, but it soon reaches a ceiling. You can’t scale a system beyond a point due to hardware limits.

Horizontal Scaling

In this type, we add more machines instead of improving the existing machine. This is also called the fan-out pattern. More machines work together in accomplishing a task.

3. Database

Every application needs a place to store data. For an E-Commerce application, we will need a storage solution to store details about users, products, orders, and messages. For a Chat application, we will need to store users, groups, and their messages. This is what a Database is for.

A Database is an organised collection of data that can be stored, retrieved, updated, and deleted reliably even after the server restarts or crashes. A Server does not store data; it is only responsible to read/update/delete data from a database. A Database supports four types of operations:

Create, Read, Update, Delete. Also called CRUD operations.

**Types of Databases **

• Relational Databases

• Non-Relational Databases

• Graph Databases

• Object-Oriented Databases

• Hierarchical Databases

• Vector Databases

4. ACID vs BASE

Databases use different models to manage transactions, consistency, availability, and scalability. ACID and BASE are two approaches used in database systems, each designed for different application requirements.

ACID Properties vs Base Properties

ACID Properties vs Base Properties

ACID (SQL Databases)

ACID stands for Atomicity, Consistency, Isolation, and Fault Tolerance.

**Atomicity - **A transaction either fully completes or doesn’t happen at all. No partial updates.

For example, in a money transfer request from account A to B.

Step 1: Deduct money from Account A Step 2: Credit money to Account B

If step 2 fails, step 1 should be rolled back.

Consistency - A transaction takes the database from one valid state to another, never violating defined rules.

Isolation - Transactions running at the same time don’t interfere with each other.

Durability - Once a transaction is committed, it stays saved, even if the system crashes right after.

BASE Properties (NoSQL databases)

BASE stands for Basically Available, Soft State, and Eventually Consistent. BASE properties prioritize availability over consistency and allow temporary inconsistent data.

**Basically Available - **The system is available at all times for reads and writes

**Soft State - **State gets changed without any input due to sync action

**Eventually Consistent - **Data gets consistent over time and not instantly.

5. CAP Theorem

CAP Theorem

CAP Theorem

CAP Theorem states that in a distributed system, you can only guarantee two out of these three at the same time.

Consistency: Every read gets the most recent write, no matter which node handles it.

Availability: Every request gets a response, even if some nodes are down.

Partition Tolerance: The system keeps working even if network communication between nodes breaks.

Why not all three?

Network partitions will happen eventually. Once nodes can’t talk to each other, you’re forced to choose.

CP systems - Choose Consistency over Availability during a partition.

**AP systems - **Choose Availability over Consistency during a partition.

CA systems - Choose Consistency and Availability and give up on tolerance to partition.

ACID leans CP. Strict correctness, willing to reject requests to stay consistent.

BASE leans AP. Stays available, accepts eventual consistency.

6. Relational Databases

Relational Databases

Relational Databases

Relational Databases, also called SQL databases, are a type of database where data is stored in rows and columns, organized into tables. The data follows a strict, predefined schema, so every row in a table has the same structure. Tables are connected to each other through foreign keys, which represent relationships between different entities, like a user and their orders.

This structure lets you run complex queries using joins, combining data across multiple tables in a single query. SQL databases also follow ACID properties, making them reliable for use cases where accuracy matters, like banking and order management.

Common examples of Relational Databases: PostgreSQL, MySQL, and Oracle.7. Non-Relational Database

7. Non-Relational Databases

Non-Relational Databases

Non-Relational Databases

Non-Relational Databases, also called NoSQL databases, are a type of database where data doesn’t need to follow a fixed table structure. Instead, data is stored in flexible formats like documents, key-value pairs, or wide columns, depending on the database type.

Each record can have a different structure, so you’re not locked into a strict schema upfront. This flexibility makes NoSQL databases well suited for unstructured or fast-changing data, and for applications that need to scale horizontally across many servers. Most NoSQL databases favor availability and speed over strict consistency, following BASE instead of ACID.

Common examples include MongoDB, Redis, and Cassandra.

7. Database Replication

Database Replication

Database Replication

Creating and maintaining copies/replicas of the same database, kept in sync with each other, is called Database Replication.

The core pattern: Primary-Replica(master-slave)

Primary(Master) - handles all writes

Replicas(Slaves) - handle all reads and continuously sync data with the primary

Most applications are read-heavy, i. e., way more people browsing products than placing orders. By routing reads to replicas, the Primary is freed up to focus only on writes, and you can add more replicas to handle more read traffic.

1 Primary (writes) → can’t scale infinitely

5 Replicas (reads) → scale read capacity easily by adding more

Types of Replications

Synchronous Replication: The primary waits for the replica to confirm the write command before responding to the server (client for the DB).

Client -> write -> Primary -> write to replica -> confirm to client

Asynchronous Replication: The primary responds to the client immediately and signals the write to replicas in the background.

Client -> write -> Primary -> respond to Client -> run background write to replica.

8. Database Partitioning

Data Partitioning

Data Partitioning

Data partitioning is the practice of breaking the main database into separate smaller databases for processing and storage. There are two types of database partitioning.

Vertical Partitioning: In this type, we split the tables by columns. Different columns of the same row live in different tables or stores.

**Horizontal Partitioning: In this type, we **split a table by rows. Same columns, but different rows live in different partitions.

Benefits of Database Partitioning:

• Smaller pieces are easy to manage and scale

• Easy and fast lookups

• Data that is no longer needed can be moved to a separate database and archived.

9. Database Sharding

Database Sharding

Database Sharding

Database Sharding is a way of scaling a database by splitting it into smaller, independent pieces called shards, each holding only a portion of the total data. Instead of one database handling every read and write, the load gets distributed across multiple shards, each running on its own server. Database Sharding is a Horizontal type of Database Partitioning.

A sharding key decides which shard a piece of data belongs to, commonly using range-based, hash-based, or geo-based strategies. This helps when a single database can no longer handle the write load or the total data size, something replication alone can’t fix, since every replica still stores the full dataset. The tradeoff is that queries spanning multiple shards become harder, and cross-shard transactions aren’t simple to keep atomic.

10. HTTP

HTTP - HyperText Transfer Protocol

HTTP - HyperText Transfer Protocol

HTTP stands for HyperText Transfer Protocol and is a protocol that is used by clients and servers to communicate and transfer data with each other. HTTP contains a set of rules on how communication is established, requests are formatted and sent, and responses are sent. HTTP is a stateless protocol and uses TCP underneath.

Every HTTP request contains:

Method - what action to perform

URL - address of the resource

Headers - Request metadata

Body - Data sent by the client to the server

Every HTTP response contains:

Status Code - result of the request

Headers - metadata of the response

Body - requested data

HTTP methods:

GET - get data

POST - create new data

PUT - update/replace data

PATCH - update data in place

DELETE - delete data

HTTP status codes

200 - OK

201 - Created

301 - Moved

304 - Not Modified

400 - Bad Request

401 - Unauthorized

404 - Not Found

500 - Internal Server Error

503 - Service Unavailable

11. Monolithic Architecture

Monolithic Architecture

Monolithic Architecture

Monolithic Architecture is a single unified codebase where all the features of an application reside together and run as a single unit.

One codebase - One build - One Deployment

Monolithic Architecture is further divided into two more types

**Traditional Monolithic: **An application where all the features, including the User interface, Business Layer, Data access layer, and database, all reside within the same repository. For example: A Java or Spring application

Modular Monolithic / Modern Monolithic: A modern form of the monolith where only the Service layer features remain monolithic, whereas the UI and database are kept separate.

Advantages of Monolithic Architecture:

• Easy to set up, develop, test, and deploy

• Fast speed of execution

• Great for smaller teams and limited scope

Disadvantages of Monolithic Architecture:

• Difficult to maintain once the application starts growing

• Tight coupling within layers

• Difficult for multiple teams to work independently

• Lock-in for the tech stack.

12. Microservices Architecture

Microservices Architecture

Microservices Architecture

In a Microservices Architecture, instead of building one large application, the system is divided into multiple small, independent services. Each service is responsible for a single business functionality, maintaining its own codebase, deployment pipeline, and often its own database. This architecture allows applications to be designed as a collection of loosely coupled, interdependent services that can be developed, deployed, and maintained independently.

In an E-Commerce app built with microservices:

• User Service handles authentication and profiles

• Product Service handles catalog and inventory

• Order Service handles order creation and tracking

• Payment Service handles transactions

**Advantages of Microservices: **

• Independent Deployability

• Scalability

• Fault Isolation and separation of concerns

• Technology Flexibility

• Faster Development Cycles

Disadvantages of Microservices:

• Complex Communication

• Data Management

• Operational Overhead

• Testing Complexity

• Latency

13. API Gateway

API Gateway

API Gateway

An API gateway sits between the client and server and only exposes the part needed for the client, hiding all the complexity. An API gateway is a single point of entry for all clients of an application. It sits between the clients and microservices.

Client -> API gateway -> Microservices

**Responsibilities of an API gateway include: **

• Handling authentication and authorisation for each request from the client.

• Routing the request to the correct microservice

• Logging and monitoring

• Load balancing

• Rate limiting

• Caching

• Changing protocols (requests can be HTTP, changed to gRPC for service-to-service communication).

Amazon’s API Gateway is one of the most common API gateway services. Other services include NGINX and Kong.

14. REST APIs

REST APIs

REST APIs

REST, which stands for Representational State Transfer, are sets fo rules built on top of HTTP for designing an API(Application Programming Interface). REST APIs are like a set of rules and a contract for entities (client and server) to interact with each other predictably.

REST follows six principles

Uniform Interface: Consistent naming, standard interface, consistent structure, consistent use of HTTP methods and status codes across the entire API.

Stateless: No request is saved, and every request must contain all the information that the server needs.

Client-Server: Separation of interfaces and concerns between client and server.

Cacheable: Responses can be explicitly marked as cacheable or non-cacheable and can reuse previously fetched responses

Layered System: Multiple layers can be introduced between the base architecture(client-server). The client cannot see beyond the immediate layer they are interacting with and is not concerned about whether it’s called to the end server.

**Code-On-Demand: **Servers can extend or enhance the client’s functionality by sending executable code to the client.

15. SOAP APIs

SOAP, which stands for Simple Object Access Protocol, is a simple protocol for exchanging structured information between systems. It has strict rules on message formats, and communication happens only in XML. Unlike REST, which is an API style and uses JSON/XML and plain text for communication. SOAP is far more rigid and strict.

Every SOAP request/response is wrapped in an XML structure called an Envelope. The Envelope header has the metadata, while the body has the actual request/response data alongside the error details.

Example SOAP Request:

xmlsoap:Envelope soap:Body 45 </soap:Body> </soap:Envelope>

16. GraphQL

GraphQL

GraphQL

REST APIs have two problems

• Overfetching: Fetching more data than needed.

• Underfetching: Need more than one API call since one API response is not enough.

GraphQL fixes both problems. GraphQL is a query language for APIs where the client specifies exactly what data it needs, in a single request- nothing more, nothing less. Unlike REST (multiple endpoints, fixed responses), GraphQL exposes a single endpoint, and the client shapes the response.

POST /graphql.

That’s it. One endpoint for everything.

Example: Fetching a profile page

REST equivalent (2 calls):

GET /users/12 GET /users/12/orders?limit=3

Each call returns its own full object — you get fields you don’t need (email, address) and still have to stitch two responses together on the client.

GraphQL (1 call):

Request (what the client asks for):

javascript{ user(id: 12) { name profilePicture orders(limit: 3) { id total } } }

Response (exactly matching the shape requested):

{ “user”: { “name”: “Anurag”, “profilePicture”: “url…”, “orders”: [ { “id”: 89, “total”: 1200 }, { “id”: 84, “total”: 850 }, { “id”: 77, “total”: 2100 } ] } }

One request. Exact fields. No over-fetching, no under-fetching, no stitching responses together.

17. WebSocket

Websocket

Websocket

A WebSocket is a persistent, two-way connection between a client and a server. Once a connection is established, the client and server can both send messages to each other without repeated connection establishments or handshakes.

A WebSocket connection starts as a regular HTTP request but upgrades to a WebSocket connection once the server responds with a 101 status code. Once the 101 status code is received, the request-response cycle ends. It becomes an open, two-way communication channel.

Real-world examples:

• Chat apps

• Online games

• Sports or Stock apps

• Food Delivery apps

• Collaborative tools like Google Docs.

18. gRPC

gRPC

gRPC

gRPC, which stands for Google Remote Procedure Call, is a high-performance framework that lets one server call a method on another server running on a completely different machine as if it’s a local function call.

For example, inside an OrderService you can do

javascriptProductService.getProductDetails(order.productId) UserService.getUserDetails(order.userId)

This feels like calling a function from the same file, but under the hood, there’s a network call to a different server running on a different machine entirely.

How is gRPC so fast?

• Uses ProtoBuf, gRPC serialises data into a compact binary format. Smaller payload, faster to parse.

• Uses HTTP/2, which is faster than HTTP/1.1 (used by REST)

When to use gRPC?

• Server-to-server communication where speed matters

• Low-latency requirement systems

• Systems with streaming

19. Polling

Web Polling

Web Polling

Imagine you are building an E-commerce application checkout page. On this page, the user has to make a payment, and they can use their phone to scan the QR code and pay. Here, the client should auto-update the payment status without the client clicking on refresh. We need the server to notify the client once the payment is successful without the client asking for it explicitly. Without Webhooks, our app would have to ask the PaymentService for the payment status every second.

Client -> GET /payments/33/status Client -> GET /payments/33/status Client -> GET /payments/33/status Client -> GET /payments/33/status

This is called Polling. The client repeatedly asks the server if there is any change. The client reacts based on the response provided by the server.

Used in:

• Payment Gateways

• Live Dashboards

• Chat apps

Disadvantages

• Inefficient and a waste of resources

• The server can get overloaded due to continuous requests

20. Webhooks

WebHooks

WebHooks

Webhooks are a better alternative to Web Polling. A Webhook flips the direction of communication. Instead of the client requesting the server first, the server calls the client automatically the moment an event occurs.

Client → “Here’s my URL, call me when the payment is done” → Server saves this URL

…time passes, event happens…

Server → POST https: //yourapp.com/webhook-handler → Client.

The client never asks what happened, but the server pushes the update once it happens. REST, GraphQL, and gRPC are all pull-based techniques, i.e., the client pulls for information. Webhooks are push-based, i.e., servers push the events to the clients.

That’s it for the first part. Stay tuned for the second and last part, where I will explain topics like Event-Driven Architecture, Load Balancing Algorithms, Rate Limiting Algorithms, Worker Queues, etc.