https://christova.writeas.com/tag:designconcepts <b><h3>Tech Articles</h3></b><br/><b>Collated from various sources. Full copyright remains with original authors.</b> Mon, 03 Aug 2026 23:37:27 +0000 https://christova.writeas.com/30-system-design-concepts-easier-to-learn-than-you-think?pk_campaign=rss-feed <![CDATA[ #system #systemdesign #designconcepts #explainwithcode Please Note: This article is free to share - but still, all credit and copyright remains with Ashish Pratap Singh https://blog.algomaster.io/p/30-system-design-concepts Please checkout, sign up, subscribe and support all the excellent work Ashish has created for this excellent content in among other superb excellent posts. I am merely forwarding this content; all work belongs to Ashish. ”I also recently created a 20-minute YouTube video https://www.youtube.com/watch?v=s9Qh9fWeOAk that quickly walks through all 30 concepts—packed with visuals and animations to make everything easier to understand.” \\Ashish Pratap Singh 1\. Client-Server Architecture\\ Almost every web application that you use is built on this simple yet powerful concept called client-server architecture. On one side, you have a client—this could be a web browser, a mobile app, or any other frontend application. and on the other side, you have a server—a machine that runs continuously, waiting to handle incoming requests. The client sends a request to store, retrieve, or modify data. The server receives the request, processes it, performs the necessary operations, and sends back a response. This sounds simple, but there’s a big question: How does the client even know where to find the server? --- 2. IP Address A client doesn’t magically know where a server is, it needs an address to locate and communicate with it. On the internet, computers identify each other using IP addresses, which work like phone numbers for servers. Every publicly deployed server has a unique IP address. When a client wants to interact with a service, it must send requests to the correct IP address. But there’s a problem: When we visit a website, we don’t type its IP address—we just enter the website name. We can’t expect users (or even systems) to memorize a string of random numbers for every service they connect to. And if we migrate our service to another server, its IP address may change—breaking all direct connections. --- 3. DNS Instead of relying on hard-to-remember IP addresses, we use something much more human-friendly: domain names. But, we need a way to map a domain name to it’s corresponding IP address. This is where DNS (or Domain Name System) comes in. It maps easy to remember domain names (like algomaster.io) to their corresponding IP addresses. Here’s what happens behind the scenes: When you type algomaster.io into your browser, your computer asks a DNS server for the corresponding IP address. Once the DNS server responds with the IP, your browser uses it to establish a connection with the server and make a request. You can find the IP address of any domain using the ping command. Just open your terminal and type ping followed by the domain name. And it’ll return the IP address currently assigned to that domain. --- 4. Proxy / Reverse Proxy When you visit a website, your request doesn’t always go directly to the server—sometimes, it passes through a proxy or reverse proxy first. A proxy server acts as a middleman between your device and the internet. When you request a webpage, the proxy forwards your request to the target server, retrieves the response, and sends it back to you. Proxy hides your IP address, keeping your location and identity private. A reverse proxy works the other way around. It intercepts client requests and forwards them to backend servers based on predefined rules. Allowing direct access to servers can pose security risks, exposing them to threats like hackers and DDoS attacks. A reverse proxy mitigates these risks by acting as a controlled entry point that regulates incoming traffic and hides server IPs. It can also act as a load balancer, distributing traffic across multiple servers. If you want to learn about Proxy vs Reverse Proxy in more detail, checkout this article: Proxy vs Reverse Proxy (Explained with Examples) Read full story --- 5. Latency Whenever a client communicates with a server, there’s always some delay. One of the biggest causes of this delay is physical distance. For example, if our server is in New York, but a user in India sends a request, the data has to travel halfway across the world—and then the response has to make the same long trip back. This round-trip delay is called latency—the total time it takes for data to travel between the client and the server. High latency can make applications feel slow and unresponsive. One way to reduce latency is by deploying our service across multiple data centers worldwide. This way, users can connect to the nearest server instead of waiting for data to travel across the globe. Once a connection is made, how do clients and servers actually communicate? --- 6. HTTP/HTTPS Every time you visit a website, your browser and the server communicate using a set of rules called HTTP (Hypertext Transfer Protocol). That’s why most URLs start with http:// or its secure version, https://. Here’s how it works: The client sends a request to the server. This request includes a header (containing details like the request type, browser type, and cookies) and sometimes a request body (which carries additional data, like form inputs). The server processes the request and responds with an HTTP response—either returning the requested data or an error message if something goes wrong. HTTP has a major security flaw, it sends data in plain text. This is a serious problem, especially for sensitive information like passwords, credit card details, and personal data. That’s why modern websites use HTTPS (Hypertext Transfer Protocol Secure) instead. HTTPS encrypts all data using SSL/TLS, ensuring that even if someone intercepts the request, they can’t read or alter it. But clients and servers don’t directly exchange raw HTTP requests and response. HTTP is just a protocol for transferring data but it doesn’t define: How requests should be structured What format responses should be in or how different clients should interact with the server. This is where APIs (or Application Programming Interfaces) come in. --- 7. APIs Think of an API as a middleman that allows clients (like web and mobile apps) to communicate with servers without worrying about low-level details. Almost every digital service you use—social media, e-commerce, online banking, ride-hailing apps—is built on APIs working together behind the scenes. Here’s how it typically works: A client sends a request to an API. The API, hosted on a server, processes the request, interacts with databases or other services, and prepares a response. The API sends back the response in a structured format, usually JSON or XML, which the client understands and can display. APIs provide a layer of abstraction—the client doesn’t need to know how the server processes the request, only that it returns the expected data. If you want to learn more about APIs, checkout this article: What's an API? What's an API? Read full story But, not all APIs are built the same. Different API styles exist to serve different needs. Two of the most popular ones are REST and GraphQL. --- 8. Rest API Among the different API styles, REST (Representational State Transfer) is the most widely used. A REST API follows a set of rules that define how clients and servers communicate over HTTP in a structured way. Rest is: Stateless: Every request is independent; the server doesn’t store client state. Resource-Based: Everything is treated as a resource (e.g., /users, /orders, /products). Uses Standard HTTP Methods: Clients interact with resources using HTTP methods like: GET → Retrieves data (e.g., fetching a user profile). POST → Creates new data (e.g., adding a new user). PUT/PATCH → Updates existing data (e.g., changing user settings). DELETE → Removes data (e.g., deleting an account). REST APIs are great because they’re simple, scalable, and easy to cache, but they have limitations, especially when dealing with complex data retrieval. REST endpoints often return more data than needed, leading to inefficient network usage. If an API doesn’t return related data, the client may need to make multiple requests to retrieve all required information. To address these challenges, GraphQL was introduced in 2015 by Facebook. --- 9. GraphQL Unlike REST, which forces clients to retrieve fixed sets of data, GraphQL lets clients ask for exactly what they need—nothing more, nothing less. With a REST API, if you need a user details, user profile details along with their recent posts, you might have to make multiple requests to different endpoints: GET /api/users/123 → fetch user details GET /api/users/123/profile → fetch user profile GET /api/users/123/posts → fetch user’s posts With GraphQL, you can combine those requests into one and fetch exactly the data you need in a single query: The server responds with only the requested fields, reducing unnecessary data transfer and improving efficiency. However, GraphQL also comes with trade-offs—it requires more processing on the server side and isn’t as easy to cache as REST. Learn more about REST vs GraphQL here: REST vs GraphQL REST vs GraphQL Read full story When a client makes a request, they usually want to store or retrieve data. But this brings up another question—where is the actual data stored? --- 10. Databases If our application deals with small amounts of data, we could store it in memory. But modern applications handle massive volumes of data—far more than what memory can efficiently handle. That’s why we need a dedicated server for storing and managing data—a database. A database is the backbone of any application. It ensures that data is stored, retrieved, and managed efficiently while keeping it secure, consistent, and durable. When a client requests to store or retrieve data, the server communicates with the database, fetches the required information, and returns it to the client. But not all databases are the same. Different applications have different scalability, performance, and consistency requirements, which is choosing the right type of database is important. If you want to learn about different types of databases, checkout this article: 15 Types of Databases and When to Use Them 15 Types of Databases and When to Use Them March 24, 2024 Read full story In system design, we typically choose between SQL and NoSQL databases. --- 11. SQL vs NoSQL SQL databases store data in tables with a strict predefined schema and follow the ACID properties. Atomicity - A transaction is all-or-nothing (it either completes fully or not at all). Consistency – Data always remains valid and follows defined rules. Isolation – Transactions don’t interfere with each other. Durability – Once data is saved, it won’t be lost, even if the system crashes. Because of these guarantees, SQL databases are ideal for applications that require strong consistency and structured relationships, such as banking systems. Examples of popular SQL databases include: MySQL and PostgreSQL NoSQL databases on the other hand are designed for high scalability and performance. They don’t require a fixed schema and use different data models, including: Key-Value Stores – Fast lookups for simple key-value pairs (e.g., Redis). Document Stores – Store flexible, JSON-like documents (e.g., MongoDB). Graph Databases – Best for highly connected data (e.g., Neo4j). Wide-Column Stores – Optimized for large-scale, distributed data (e.g., Cassandra). So, which one should you use? It depends on the system requirements. If you need structured, relational data with strong consistency → SQL is a better choice. If you need high scalability, flexible schemas, or fast reads/writes at scale → NoSQL is a better choice. Many modern applications use both SQL and NoSQL together. For example, an e-commerce platform might: Store customer orders in SQL (because they require strict consistency). and store Product recommendations in NoSQL (because they need flexible and fast lookups). If you want to learn more about SQL vs NoSQL, checkout this article: SQL vs NoSQL - 7 Key Differences You Must Know SQL vs NoSQL - 7 Key Differences You Must Know Read full story --- 12. Vertical Scaling As our user base grows, so does the number of requests hitting our application servers. Initially, a single server might be enough to handle the load. But, as traffic increases, that single server can become a bottleneck, slowing everything down. One of the quickest solutions is to upgrade the existing server by adding more CPU, RAM or storage. This approach is called Vertical Scaling (Scaling Up)—making a single machine more powerful. But there are some major limitations with this approach: Hardware limits → You can’t keep upgrading a server forever. Every machine has a maximum capacity. Cost → More powerful servers become exponentially more expensive. Single Point of Failure (SPOF) → if this one server crashes, the entire system goes down. So, while vertical scaling is a quick fix, it’s not a long-term solution for handling high traffic and ensuring system reliability. Lets look at a better approach—one that makes our system more scalable and fault tolerant. --- 13. Horizontal Scaling Instead of upgrading a single server, what if we add more servers to share the load? This approach is called Horizontal Scaling (Scaling Out)—where we distribute the workload across multiple machines. This approach is better because: More servers = More capacity → The system can handle increasing traffic more effectively. No Single Point of Failure → If one server goes down, others can take over, improving reliability. Cost-effective → Instead of investing in a single, super-expensive machine, we can use multiple affordable ones. But horizontal scaling introduces a new challenge: how do clients know which server to connect to? This is where a Load Balancer comes in. ---&