Architecture

In the previous article, you learned about microservices and monolith architectures. Now let us talk about protecting your APIs from abuse: rate limiting. Rate limiting controls how many requests a client can make in a given time period. Without it, a single client can overwhelm your servers, intentionally or by accident. Why Every API Needs Rate Limiting 1. Prevent Abuse A malicious user can send thousands of requests per second to overload your servers. Rate limiting stops them before they cause damage. ...

In the previous article, you learned about API design with REST, GraphQL, and gRPC. Now let us talk about how to structure your entire application: as one big service (monolith) or many small services (microservices). This is one of the most debated topics in software engineering. The answer is not always microservices. Many successful companies run monoliths. The right choice depends on your team size, system complexity, and stage of growth. ...

In the previous article, you learned about message queues for asynchronous communication. But most communication in a system is synchronous — a client sends a request and waits for a response. That is where APIs come in. An API (Application Programming Interface) is a contract between two systems. It defines how they communicate: what requests you can send, what responses you get back, and what format the data is in. Good API design is critical. A bad API slows down development, confuses users, and is hard to change later. ...

In the previous article, you learned about the CAP Theorem and consistency patterns. Now let us look at one of the most important building blocks in distributed systems: message queues. Almost every large-scale system uses message queues. They are the backbone of asynchronous communication between services. What is a Message Queue? A message queue is a system that stores messages sent by one service (the producer) and delivers them to another service (the consumer). The producer and consumer do not need to be online at the same time. ...

In the previous article, you learned about databases, replication, and sharding. You saw that replicated databases can have “replication lag” where followers temporarily have stale data. This brings us to one of the most important concepts in distributed systems: the CAP Theorem. It explains why you cannot have everything in a distributed system. You must make trade-offs. What is the CAP Theorem? The CAP Theorem was introduced by computer scientist Eric Brewer in 2000. It states that a distributed system can only guarantee two out of three properties at the same time: ...

In the previous article, you learned how caching speeds up systems. But behind every cache, there is a database. The database is where your data lives permanently. Choosing the right database is one of the most important decisions in system design. It affects performance, scalability, and how easy your system is to maintain. SQL Databases SQL (Structured Query Language) databases store data in tables with rows and columns. They follow a fixed schema — you define the structure before inserting data. ...

In the previous article, you learned how load balancers distribute traffic across servers. But even with many servers, your system can be slow if every request hits the database. This is where caching comes in. Caching is one of the most effective ways to speed up any system. It reduces database load, lowers latency, and saves money. What is Caching? Caching means storing a copy of data in a faster storage layer so future requests can be served quicker. Instead of fetching data from a slow source (like a database), you fetch it from a fast source (like memory). ...

In the previous article, you learned about horizontal scaling — adding more servers to handle more traffic. But when you have multiple servers, how do you distribute traffic across them? That is what a load balancer does. It is one of the most important components in any scalable system. What is a Load Balancer? A load balancer is a device or software that distributes incoming network traffic across multiple servers. Think of it as a traffic director at a busy intersection. ...

In the previous article, you learned what system design is and how to approach any design problem. Now let us talk about the most fundamental concept: scalability. Scalability is the ability of a system to handle more work by adding resources. Every system starts small. The question is: what happens when it needs to grow? What is Scalability? Imagine you own a coffee shop. On Monday, you serve 50 customers. Your single barista handles it fine. But on Saturday, 500 people show up. What do you do? ...

You know how to write code. You can build features, fix bugs, and ship apps. But when someone asks you to design a system that handles millions of users, you freeze. This is what system design is about. It is the skill of building software systems that work at scale. And it is not just for senior engineers or job interviews. Every developer needs it. This is the first article in the System Design from Zero to Senior series. We will start from the basics and build up to designing real systems like URL shorteners, chat apps, and video streaming platforms. ...