System Design

Module 01 - System Design Fundamentals
1. What System Design Actually I...2. The Magic of DNS - How Does T...3. Functional vs Non-Functional ...4. Capacity Estimation & Back-of...5. Latency Budgeting6. Load Balancing - Distributing...
ProfileProfile
Akkal DhamiFull Stack Developer

Building modern web experiences with a focus on performance, scalability, and clean architecture.

© 2026 | Akkal Dhami | All rights reserved

Built with
byAkkal Dhami

Navigation

  • Projects
  • Dev Setup
  • Playbook
  • Templates
  • Networking
  • SQL - MySQL
  • SQL Playground
  • System Design
  • DSA
AKKAL DHAMIAKKAL DHAMIAKKAL DHAMI

What System Design Actually Is

Get started with system design by learning the basics of system design.

1. What is System Design?

System design is the process of defining the architecture, components, and data flow of a system to satisfy specific requirements.

Every system has two types of requirements:

  • Functional Requirements

    • What the system should do.
    • Example: User can sign up, place an order, upload a file.
  • Non-Functional Requirements

    • How well the system does it.
    • Example: Scalability, availability, latency, consistency, security.

System design: deciding the structure, components, and data flow of a software system so it works correctly, scales well, and stays reliable.


2. Functional and Non Functional Requirements

2.1 Functional Requirements (FR)

Functional requirements describe what the system should do — the specific features, behaviors, and capabilities users interact with. They define the core business logic.

Characteristics:

  • Directly tied to user actions and business use-cases
  • Testable ("does clicking this button do X?")
  • Usually gathered from product/business requirements

2.2 Non-Functional Requirements (NFR)

Non-functional requirements describe how well the system performs — the quality attributes, constraints, and operational characteristics rather than specific features.

Characteristics:

  • Not tied to a single feature — they apply system-wide
  • Harder to test with a simple pass/fail; usually measured (ms, %, req/sec)
  • This is where senior-level system design thinking lives — trade-offs happen here
AspectFunctional RequirementsNon-Functional Requirements
DefinitionWhat the system should doHow well the system does it
FocusFeatures & business logicQuality, performance & constraints
ExamplesUser can log in, place an order, upload a file, search productsSystem handles 10k req/sec, 99.9% uptime, response under 200ms
Impact if missedFeature is broken or missingSystem is slow, crashes under load, or loses data
Common categoriesLogin, CRUD operations, search, notificationsScalability, availability, latency, security, consistency, maintainability

3. Networking Basics

3.1 IP Address & Port

  • IP Address: Unique identifier for a device on a network (e.g. 192.168.1.1)
  • Port: A number identifying a specific process/service on that device (e.g. :8080)
  • Combined: IP:PORT tells you exactly where to send a request

3.2 DNS (Domain Name System)

  • Translates human-readable domain names (google.com) into IP addresses
  • Think of it as the "phonebook of the internet"

3.3 TCP vs UDP

AspectTCPUDP
Full FormTransmission Control ProtocolUser Datagram Protocol
ConnectionConnection-oriented (handshake required)Connectionless (no handshake)
ReliabilityReliable — guarantees deliveryUnreliable — no delivery guarantee
OrderingMaintains order of packetsNo ordering guarantee
SpeedSlower (overhead from acks, retransmits)Faster (minimal overhead)
Error CheckingExtensive (checksum + retransmission)Basic (checksum only, no recovery)
Header Size20–60 bytes8 bytes
Use CasesWeb (HTTP/HTTPS), email, file transfer, APIsVideo streaming, gaming, VoIP, DNS

One-liner to remember: TCP = reliable but slower. UDP = fast but unreliable.

3.4 HTTP / HTTPS

  • HTTP: Protocol for transferring data over the web (application layer, built on TCP)
  • HTTPS: HTTP + encryption (TLS/SSL)

4. Core Vocabulary Cheat Sheet

  • Latency: Time delay for a single request to complete (ms)

  • Throughput: Number of requests a system can handle per unit time

  • Vertical Scaling: Making a single machine more powerful (more CPU/RAM)

  • Horizontal Scaling: Adding more machines to share the load

  • Availability: System is up and responding when requested

  • Reliability: System performs correctly and consistently over time

  • Redundancy: Keeping extra copies of components or data to avoid a single point of failure.

  • Consistency: All nodes/users see the same data at the same time

  • Durability: Once data is successfully written, it won't be lost even if the system crashes.

  • Fault Tolerance: The ability of a system to continue operating when components fail.

  • Bandwidth: The maximum amount of data that can be transferred per second.

Latency

The time it takes for a request to travel from the client to the server and back.

User ───── Request ─────> Server

User <──── Response ───── Server

Time taken = Latency

Example:

Open Google → page loads in 80 ms Latency = 80 milliseconds

Lower latency is better.

Throughput

The amount of work a system can complete in a given period.

1000 requests / second

500 MB / second

10,000 messages / minute

Example:

A server handles:

5,000 requests every second

Throughput = 5,000 RPS

Higher throughput means the system can serve more users.

Bandwidth

The maximum amount of data that can be transferred per second.

100 Mbps, 1 Gbps

Think of it as the width of a highway.

Wider highway → more cars

Higher bandwidth → more data

Don't confuse Latency (speed of one request) with Throughput (volume of requests handled). A system can have low latency but low throughput, or vice versa.

Availability

The percentage of time a system is up and accessible to users.

User ───── Request ─────> Server ✔

Server ───── Response ─────> User

Service is reachable = Available

Example:

A website with 99.99% uptime is almost always accessible.

Higher availability is better.

Reliability

The probability a system performs correctly, without failure, over a given period of time.

User ───── Request ─────> Server

Server ───── Correct Response ─────> User ✔

Works correctly every time = Reliable

Example:

An ATM always dispenses the correct amount after payment.

Higher reliability is better.

Reliability is about correctness — availability is about uptime. A system can be up (available) but still return wrong answers (unreliable).

Consistency

The guarantee that all users see the same data after an update.

User A ── Update Balance → Database

User B ── Read Balance → Same Updated Value ✔

Everyone sees the same data = Consistent

Example:

You update your profile picture. Consistency means every friend viewing your profile sees the new picture immediately, not the old one.

Stronger consistency provides more accurate data.

Durability

The guarantee that once data is successfully saved, it will not be lost—even after crashes or power failures.

Write data ──> Saved to disk ──> [Power loss] ──> Restart ──> Data still there ✔

Example:

You place an order online, the server crashes 1 second later. Durability means your order is still recorded when the server comes back.

Higher durability is better. Durability protects against loss. It says nothing about speed.

Fault Tolerance

A system's ability to keep working correctly even when part of it fails.

Server A ✘ (down)

Server B ✔ ── still serving requests

Server C ✔ ── still serving requests

System stays up despite Server A failing

Example:

If one web server crashes, another server automatically handles incoming requests.

Higher fault tolerance means fewer service interruptions. Fault tolerance = failures happen, but users don't feel them.

Redundancy

Keeping extra copies of components or data so the system can survive failures.

Primary DB ──> [copy] ──> Replica DB 1

                       └────> Replica DB 2

Backup copy = Redundancy

Example:

Your database has 2 replicas. If the primary fails, a replica takes over — no data lost, no downtime.

More redundancy improves availability and fault tolerance.

The Magic of DNS - How Does The Intern...