System Design

A Beginner's Comprehensive Guide to Scalable System Design

Bilal Momin9 min read
A Beginner's Comprehensive Guide to Scalable System Design

Understand the fundamentals of scalable system design, from DNS to CDNs, queues, load balancers, microservices, and more. Perfect for beginners aiming to learn how modern distributed systems handle millions of users.

In our hyper-connected world, apps and services are expected to be fast, reliable, and available 24/7 – even when millions of people use them at the same time. This doesn’t happen by accident. Behind every seamless experience is a carefully designed system architecture that ensures scalability and fault tolerance.

If you are just starting your journey into system design, this guide covers the fundamental building blocks that make modern distributed systems work.

1. Servers and Clients – The Foundation of Everything

At the heart of every system are servers and clients.

  • Servers are powerful machines that run continuously, hosting applications and services. They have a public IP address so that anyone on the internet can send them requests.
  • Clients can be anything — your laptop, mobile phone, or even IoT devices. These clients send requests to the server, and the server processes and returns the response.

While technically you could run a server from your home computer (if it has a stable public IP and uptime), most companies rely on cloud providers like AWS or DigitalOcean because they offer reliability, scalability, and performance out of the box.

Think of an IP address as the house address of a server. It’s unique, but hard to remember — and that’s where DNS comes in.

2. DNS – The Phonebook of the Internet

Typing amazon.com is much easier than remembering its numeric IP address. The Domain Name System (DNS) is a global, decentralized service that maps human-friendly domain names to machine-friendly IP addresses.

When a user types a URL into their browser:

  1. The request goes to a DNS server.
  2. The DNS server looks up the domain name and returns the correct IP address.
  3. The browser then connects to that IP.

This process is called DNS resolution. Without DNS, users would need to memorize every IP they wanted to visit!

3. Scaling: Vertical vs. Horizontal

As your user base grows, a single server may no longer be able to handle all requests. You need scaling.

Vertical Scaling (Scaling Up)

You add more resources to a single server: faster CPUs, more RAM, more storage. While simple, it has drawbacks:

  • There’s a hardware limit.
  • It requires downtime for upgrades.
  • Extra capacity sits idle during off-peak hours.

Horizontal Scaling (Scaling Out)

Instead of one powerful machine, you add more servers and distribute requests among them. This approach:

  • Avoids downtime.
  • Can scale almost infinitely.
  • Requires a way to manage traffic across multiple servers: a load balancer.

4. Load Balancers – Traffic Managers

A load balancer acts like a smart traffic cop sitting between users and servers.

  • It has a public IP that clients connect to.
  • It distributes incoming requests across multiple backend servers.
  • It ensures no server is overloaded and checks server health.
  • If one server goes down, the load balancer routes traffic to others.

Load balancers themselves are built to be fault-tolerant, often using multiple internal machines so they don’t become a single point of failure.

5. Microservices and API Gateways

Modern systems are rarely one giant application (called a monolith). Instead, they use microservices.

  • Microservices break an application into smaller, independent parts: authentication service, orders service, payments service. Each service can be updated and scaled independently.

To manage these services, companies use an API Gateway:

  • It is the single entry point for all requests.
  • Routes requests to the right service based on the path.
  • Handles authentication and traffic policies.
  • Acts like a reverse proxy.

This approach improves modularity, scalability, and fault isolation.

6. Asynchronous Processing: Queues and Pub-Sub

Some tasks don’t need to be done immediately. For example, after a payment, the user shouldn’t wait for an email confirmation to be sent before seeing the success page. This is where asynchronous communication comes in.

Queue Systems

  • Tasks (like sending emails) are pushed into a queue.
  • Background workers pull tasks from the queue and execute them independently.
  • Scaling workers horizontally allows more tasks to be processed in parallel.

This design ensures that critical user-facing actions are fast and non-blocking.

Pub-Sub Model

In a publish-subscribe model, one event can trigger multiple services.

  • Example: After a payment, a message is published.
  • Multiple services subscribe: one sends an email, another sends SMS, another updates analytics.
  • Unlike queues, multiple consumers receive the same event.

This pattern is essential for fan-out communication.

7. Rate Limiting – Protecting the System

With millions of users, how do you ensure one user doesn’t overload the system with requests?

Rate limiting sets limits on how many requests can be made in a given time. This:

  • Protects from abuse (e.g., DDoS attacks).
  • Ensures fair usage.
  • Can be implemented at the API Gateway, load balancer, or service level.

Algorithms like Token Bucket or Leaky Bucket are commonly used to manage this.

8. Database Scaling: Replication and Caching

As more users join, databases can become bottlenecks.

Replication

  • A primary database handles all writes.
  • Read replicas are created to handle read requests.
  • This reduces load on the primary database and improves performance.

Replicas may have slight delays, which is fine for analytics and read-heavy workloads.

Caching

Caching stores frequently used data in fast, in-memory stores like Redis.

  • If data is in cache → return it immediately.
  • If not → fetch from the database, store it in cache for next time.

This dramatically improves speed and reduces database load.

9. Content Delivery Networks (CDN)

A CDN helps deliver static content (images, videos, CSS) faster by storing copies on servers around the world.

  • When a user requests a file, they are routed to the closest CDN server.
  • This reduces latency and server load.
  • CDNs use a routing mechanism called Anycast IP to direct users to the nearest edge location.

This is why websites load fast even if the main servers are on another continent.

Putting It All Together

Imagine an e-commerce site:

  1. The user types the URL — DNS resolves the domain to a load balancer.
  2. The load balancer distributes requests to backend servers.
  3. The API Gateway routes requests to different microservices.
  4. Non-critical tasks (like sending emails) are processed via queues asynchronously.
  5. Pub-sub models ensure multiple services can act on important events.
  6. Rate limiting prevents abusive traffic.
  7. Databases scale through replication and caching.
  8. Static files are delivered instantly via a CDN.

This combination ensures scalability, fault tolerance, and fast performance.

Conclusion

Understanding these building blocks is the first step to mastering system design. From DNS to CDNs, from queues to microservices, these concepts form the foundation of how modern applications handle millions of users seamlessly.

If you’re just starting, this is a great mental model to build upon. For a more visual explanation, watch this beginner-friendly video by Piyush Garg: https://www.youtube.com/watch?v=lFeYU31TnQ8