1. C1: System Context Design

1.1. Overview

System design is a series of decisions optimising for:

• Profit: Functionality, Scalability, Speed
• Loss: Security, Robustness, Observability, Cost

1. [Functionality] Does the system work?
2. [Compliance] Is the system compliant?
3. [Security] Is the system secure?
4. [Robustness] How does the system handle failures?
5. [Scalability] Does the system scale?
6. [Speed] What are the bottlenecks?
7. [Observabilty] Is the system observable?
8. [Cost] Is there anything we can simplify do decrease cost?

1.2. Functionality

1.2.1. Types of Development

• Web
  • Frontend
  • Backend
• Mobile
• Game
• Desktop
• Embedded
• DevOps
• Data
• ML / AI
• Security

1.2.2. CAP Theorem

1.2.3. Duplexity: Initiation of communication + Sending of data + Concurrency

1.2.4. Message Distribution / Fanout Patterns

Key question: For one event,

• who should receive it,
  • this determines fanout appraoch
• how many recipients at peak
  • if >1000, avoid broadcast and look into group fanout strategies

1.3. Compliance

1.3.1. MIFID

Markets in Financial Instruments Directive (MIFID) is a EU compliance standard for financial systems

Key Requirements:

• Be synchronised to UTC
• Stay within strict accuracy limits (e.g. milliseconds or microseconds depending on system)

Common implementations: NTP = Network Time Protocol

• It keeps a machine’s clock accurate and synced with official time servers
• Prevents clock drift (when a system slowly becomes a few seconds/minutes off)
• Used everywhere in infrastructure (servers, containers, databases)

1.3.2. PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) is a security compliance standard governed by major card brands (Visa, Mastercard, Amex) relevant to credit/debit card data

1. Prefer using payment providers (e.g. Stripe) to avoid handling card data
2. If unavoidable:
   1. Never store sensitive authentication data (CVV, PIN, track data)
   2. Isolate the Card Data Environment (CDE) via network segmentation
   3. Encrypt cardholder data in transit and at rest
   4. Strict access control + audit logging for in-scope systems

1.4. Security

1.5. Robustness

1.6. Scalability

1.7. Speed

1.8. Observabilty

1.9. Cost

1.9.1. Infrastructure as a Service (IaaS) vs Platform as a Service (PaaS)

1.9.2. Tenancy

A tenant is a customer/organisation space with its own users, data, config

2. C2: Container Design

2.1. Functionality

2.1.1. Typical Cloud Infrastructure

2.1.2. Options for storing data

Storage = Abstraction + Deployment

2.1.3. Options for structuring data

2.1.4. File Transfer Options

2.1.5. Operating Systems

• Stack Size
  • Linux: 8MB
  • macOS: 8MB
  • Windows: 1MB

2.1.6. Transport Models

2.1.7. API Architectural Styles

What API architectural style is optimal for functionality (speed) and cost (DevX, maintenance, opex)?

2.1.8. Transport Protocols

What transport protocol is optimal for functionality (user experience) and cost (DevX, maintenance, opex)?

What common combinations are there?

2.1.9. Scheduler

Scheduler

• Does
  • Assign task to node
• Does not
  • Start or manage the workload

Orchestrator

• Does
  • Scheduler
  • Provisioning and starting workloads on nodes
  • Scaling workloads up/down based on demand
  • Health monitoring and self-healing
  • Rolling updates and rollback management
  • Managing networking, storage and service discovery

2.1.10. WebRTC

If asked: “How would you design WhatsApp voice calls?”

• Signaling: WebSockets (or SIP for enterprise VoIP).
• Transport: RTP/SRTP for media.
• NAT traversal: STUN + TURN fallback.
• Encryption: SRTP end-to-end.
• QoS handling: Adaptive bitrate, jitter buffer.

If asked: “How does WebRTC work?”

• WebRTC = framework, uses:
• Signaling (custom, often WebSocket)
• RTP/SRTP for audio/video streams
• STUN/TURN for NAT traversal
• DTLS/SRTP for security
• Adaptive bitrate + codec negotiation.

2.1.11. Websockets

2.1.11.1. Single-Node

At high level design, a single-node WebSocket system can often handle up to ~10k concurrent connections, but to maintain a margin of safety, it’s reasonable to start thinking about distributed WebSocket systems above ~1k connections. At that point, distributed systems also bring benefits like better fault tolerance and operational robustness. When calculating costs

At a lower level, websocket soak test tools can be used to validate these assumptions by observing system behaviour over time (CPU/memory usage, message latency, connection health (success/lifetime/dropped), network egress), identifying which part of the system becomes a bottleneck and needs to be scaled. The goal at this stage is typically to meet some kind of SLO, e.g.:

• 99.9% of WebSocket messages delivered within 200ms
• 99% of API requests complete under 500ms
• < 0.1% connection drops per hour

2.1.12. Pubsub

What types of pubsub brokers are there?

2.2. Compliance

2.3. Security

2.3.1. Auth

The process of designing an auth system involves two categories,

1. Authentication
2. Authorisation

and four key questions:

1. What type of token do we want to use / Where is auth state stored?
2. Who issues the token?
3. Who validates the token?
4. How do we want to maintain auth state over time?

2.3.1.1. What type of token do we want to use / Where is auth state stored?

2.3.1.2. Who issues the token to the client?

2.3.1.3. Who validates the client's token?

2.3.1.4. How do we want to maintain auth state over time?

2.3.1.5. Auth Implementations

2.3.1.5.1. What common combinations of authn/authz/refresh strategies are there?

2.3.1.5.2. Which AWS API Gateway Authoriser should we use?

2.3.2. Typical Cloud Infrastructure

2.3.3. Virtual Private Clouds (VPCs)

2.3.3.1. Connections

2.3.3.2. Subnets

Port Forwarding: Forwarding of information from a router's port to a port on a device on its subnet

Tailscale Protocol: Connecting directly to a device's port when it is already on a subnet

2.3.4. Firewalls

2.4. Robustness

If asked: “How does VoLTE differ from WhatsApp?” • VoLTE → Managed SIP + RTP inside carrier network, guaranteed QoS, low jitter. • WhatsApp → WebRTC over the public Internet, no QoS guarantees.

2.4.1. Typical Cloud Infrastructure

2.4.2. How do we ensure reliable message processing and delivery over time?

2.4.3. Websockets

2.4.4. Caching

2.4.5. Distributed Websockets

2.4.5.1. Issues and Mitigations

2.4.6. Adaptive Performance Strategies

2.5. Scalability

2.5.1. Overview

Types of horizontal scaling:

1. Database Horizontal Scaling
2. Compute Horizontal Scaling

Database Horizontal Scaling, i.e. sharding

Compute Horizontal Scaling

2.5.2. Rules of Thumb

2.5.3. Typical Cloud Infrastructure

2.5.4. Options for storing data

2.5.5. Strategies to serve SPAs

2.5.6. Container Orchestration

2.5.6.1. Orchestration Framework

2.5.6.2. Platform

2.5.7. Distributed Websockets

2.5.8. Optimising for reads/writes

The disadvantages in general are:

1. Higher storage
2. Stale data
3. Additional complexity with invalidation strategy

The disadvantages in general are:

1. More complex read paths
2. Additional complexity with background preprocessors

2.5.9. Caching

2.5.10. Distributed Websockets

2.5.10.1. : How do we ensure that messages get to the correct client?

2.6. Speed

2.6.1. Typical Cloud Infrastructure

2.6.2. Rendering Strategy

2.6.3. Caching

2.7. Observabilty

2.7.1. Typical Cloud Infrastructure

2.8. Cost

2.8.1. Typical Cloud Infrastructure

2.8.1.1. How do we route clients to the same instance to reduce coordination?

3. C3: Component Design

• BFF: Backend for Frontend
  • GET /dashboard instead of GET /users + GET /orders + GET /recommendations

3.1. Functionality

3.1.1. Choosing a language for mobile app development

3.1.2. Choosing a language for frontend web development

JS is the default choice as it is the only language that has direct access to the DOM to render UI.

3.1.3. Choosing a language / framework for backend web development

The choice of language for backend web development is tightly coupled to the language's runtime, libraries and frameworks as they provide key tradeoffs.

3.1.4. Choosing an Infrastructure as Code (IaC) framework for cloud

3.1.5. Choosing a library for local dev of cloud resources

AWS

3.1.6. Encoding

Encoding is used to serialise user facing data (text/image/audio/video) for storage / transport over the network.

3.1.7. JavaScript

3.1.8. Websockets

Choosing a websocket session identifier

3.1.9. Testing Frameworks

Frontend

• Web
  • Playwright (purpose built from the ground up)
  • Cypress (multiple packages patched together)
• Cross Platform
  • integration_test (flutter)
• Mobile
  • Maestro (js)
    • Supports OS level interaction, e.g. going to system settings

3.1.10. Browser Storage

3.1.11. Database Data Persistence

Data in Tables (Persistent)

1. Base/Regular Table
   • Data stored in disk
   • Data is persistent across sessions
2. Temporary Table
   • Data stored in disk
   • Data exists only in session
   • Data can exist across sessions if cached

Data in Queries (In Memory)

1. Result Set
   • Data stored in memory
   • Data exists onl
2. Derived / Subquery e.g. FROM
   • Data stored in memory
   • Data exists only in query
3. Common Table Expression (CTEs) e.g. WITH
   • Same as subquery, but provides syntactic alias for reusing subqueries

Named Queries

1. View/Virtual
   • Query definition stored in disk
   • Data only stored
2. Materialised View
   • Data stored in disk
   • Manual/scheduled refresh
3. Stored Procedure
   • Data stored in disk
   • ???

3.1.12. Database Isolation Levels

3.2. Compliance

3.3. Security

3.3.0.1. Auth: How do we model who gets access to what?

3.3.1. Encryption / Decryption with Keys

There are two types of encryption/decryption patterns

Public and private keys are used for two main purposes:

3.4. Robustness

3.4.1. Queues

3.5. Scalability

3.5.1. Database Access Patterns

3.5.1.1. DB Lock Modes and Granularity

3.5.1.2. ORM Lock Types

3.5.1.3. Spring

@Transactional: joins existing transaction, or starts a new one if no transaction exists

3.5.2. S3

URL Types

3.6. Speed

3.6.1. HTTP

There are 3 main versions of HTTP being used

• Modern clients auto-negotiate best protocol via Application Layer Protocol Negotiation (ALPN)
  • client says “I support h2, http/1.1, h3”, server picks one

3.7. Observabilty

3.8. Cost

4. C4: Code Design

4.1. Functionality

4.1.1. Data Structures & Algorithms

How to solve problems with code.

4.1.1.1. Methods to Reinterpret Problems

• Create formula and see if shifting variables around can simplify solution

4.1.1.2. Modulo

4.1.1.3. Floor Division

4.1.1.4. Binary Trees

Sizes

• no. of nodes: $n$
• height of tree: $log_x n$,
  • where $x$ is for a $x$-ary tree
• width of tree: $2^x$
  • where $x$ is the level of the tree for which you want the width

How to navigate a Tree

There are two methods of navigating a tree: Depth-First Search (DFS) and Breadth-First Search (BFS)

DFS

There are three ways to perform traversal:

1. In-Order Traversal (IOT) -> left, node, right
2. Pre-Order Traversal (PreOT) -> node, left, right
3. Post-Order Traversal (PostOT) -> left, right, node

There are two ways to implement DFS:

'''
1. Recursively
    - Adv.: Clean and intuitive
    - Disadv.: Limited by recursion depth, stack overflow risk
'''

def recursive(root):
    iot(root)
    preOT(root)
    postOT(root)

def iot(node):
    if node is None:
        return

    iot(node.left)
    process(node)
    iot(node.right)

def preOT(node):
    if node is None:
        return

    process(node)
    preOT(node.left)
    preOT(node.right)

def postOT(node):
    if node is None:
        return

    preOT(node.left)
    preOT(node.right)
    process(node)

'''
2. Iteratively
    - Adv.: Robust for large or unbounded inputs
    - Disadv.: Less intuitive and readable
'''

def iot(root):
    if root is None:
        return
        
    stack = []
    node = root

    while stack or node:
         go left as far as possible
        while node:
            stack.append(node)
            node = node.left
        
        node = stack.pop()
        process(node)
        stack.append(node.right)

def preOT(root):
    if root is None:
        return 
    
    stack = [root]  switching this to a queue changes the DFS to BFS
    while stack:
        node = stack.pop()
        
        process(node)

         push right first so left is processed first
        if node.right:
            stack.append(node.right)
        if node.left:
            stack.append(node.left)


def postOT(root):
    if root is None:
        return
    
    stack = []
    lastNode = None
    node = root

    while stack or node:
         go left as far as possible
        if node:
            stack.append(node)
            node = node.left
            continue
        
         at leftmost node, if candidate has right and is not the last visited node, check right subtree
         at 
        candidateNode = stack[-1]
        if candidateNode.right and lastNode != candidateNode.right:
            node = candidateNode.right
            continue

        node = stack.pop()
        process(node)
        lastNode = node
        node = None  do not process node again

BFS

There are two ways to perform traversal:

1. Flat Traversal (FT)
2. Level-Order Traversal (LOT)

BFS is primarily done iteratively - it can be implemented recursively but there is no practical benefit.

def ft(root):
    if root is None:
        return
    
    queue = deque([root])

    while queue:
        node = queue.popleft()

        process(node)

        if node.left is not None:
            queue.append(node.left)
        if node.right is not None:
            queue.append(node.right)

def lot(root):
    if root is None:
        return

    queue = deque([root])

    while queue: 
         for LOT, we just need to wrap the flat traversal logic in a for loop with levelSize iterations
        levelSize = len(queue)
        for _ in range(0,levelSize):
             same as flat traversal

Note:

• You can also add metadata for each node by appending tuples (node, metadata) to the queue instead of just nodes

4.1.1.5. Array

How many times can I slide a window over an array?

• Intuition
  • Start from the base case - window size 1
    • How many times can you slide it?
  • Increase window size
• Formula
  • len(array) - windowSize + 1

4.1.1.6. Bitwise Operations

4.1.1.7. Dynamic Programming

• Caching results for fibonacci-style recurrence

4.1.1.8. Binomial Theorem

Theory

• The Binomial Theorem describes how to expand binomial expressions without brute force
  • Binomial Expression:
    • An expression formed from two terms,
    • e.g. $(a + b)$
  • Binomial Theorem Formula:
    • $(x+y)^n = \sum_{k=0}^{n} \binom{n}{k} x^{n-k} y^{k}$
      • where $\binom{n}{k} \equiv {}^{n}C_k$ is the binomial coefficient a.k.a. combinations

Applications

• The binomial coefficient can be used to describe symmetric number sequences, e.g. 1 4 6 4 1

4.1.1.9. Describing Symmetry

• Linear Symmetry
  • Combinations / Binomial Coefficient
  • Modulus
  • Even Functions
  • Cosine
• Rotational Symmetry
  • Odd Functions
  • Sine

4.2. Compliance

4.3. Security

4.3.1. Request/Response Flags

4.3.1.1. Authentication

Transporting Passwords

• Use HTTPS for password submissions
• Avoid logging raw credentials

4.3.1.2. Authentication Methods

• Hashing
  • Passwords should be stored as irreversible cryptographic hashes
• Salting
  • A random, user-specific unique value (salt) is added to the plain-text password before hashing, which is stored in plaintext in the database
  • Prevents
    • two users with the same passwords from getting the same hash
    • hackers using rainbow tables (precomputed mappings of common passwords -> hashes)
• Peppering
  • A random, global value (pepper) is added to the plain-text password before hashing, which is stored as an env variable on the server
  • An additional layer of security on top of salting

4.4. Robustness

4.4.1. Recursion Depth Limits

• C++: 100,000
  • Depends on frame size + OS stack size
• Dart: 10,000
  • Set by default
• JS: 10,000
  • (V8 engine/chrome)
  • Depends on
• Java: 1,000
  • Depends on frame size + OS stack size
• Python: 1,000
  • Set by default

4.5. Scalability

4.6. Speed

4.6.1. CPU Optimisations

• Branch Prediction
• Variable reassignment
• CPU Pipelining
• CPU Preloading
• CPU Prefetching
• Cache Locality
• Memory Access Patterns

4.6.2. Language Optimisations

• Peephole Optimisations
• Inline
• Unroll

4.6.3. Caching

4.7. Observability

4.7.1. Logging

• Avoid auto logging POST bodies and GET parameters
  • If the auto logging runs on auth endpoints, passwords could be written in plaintext to logs

4.7.2. Performance Metrics

4.8. Cost

4.8.1. Maintainability

How to deliver value to users with minimal waste using code.

• Single Layer of Abstraction Principle (SLAP)
• Dependency Injection
• Clean Conditionals
• Conventional Commits
• Early Returns / Continues
• Prefer for loops over while

4.8.2. Response Codes

4.8.3. React

• Avoid useEffect if there are no external deps (source)

4.8.4. Git

• BFG Repo-Cleaner
  • CLI for cleaning up git repos
    • e.g. committed large files / sensitive data

5. First Principles

5.1. Options for deploying

5.2. Testing Best Practices

• E2E
  • Main user stories, happy paths
• Integration
  • Edge cases not caught by E2E, unhappy paths
• Unit
  • Edge cases for small functions

5.3. Mobile

5.3.1. Cold/Warm/Hot Starts on Mobile

1. Cold Start
   • binary not in memory
   • e.g. launching app after killing it
2. Warm Start
   • binary in memory, app process in background
   • e.g. when switching between apps
3. Hot Start
   • binary in memory, app process in foreground
   • e.g. when locking and unlocking the screen momentarily, or switching between apps briefly
     • This occurs because the Android and iOS give apps a grace period (~2s) before backgrounding
   • App still has GPU and CPU priority

5.3.2. Splash Screen

Splash screens are only shown for cold start

5.4. Databases

5.4.1. SQL Databases

5.4.1.1. Deadlock Problem

5.4.2. ORMs

5.5. Networking Model

There are two main models that are used in the industry today:

1. Open Systems Intercommunication (OSI) model
   1. Abstract: Typically used to discuss concepts
2. TCP/IP model
   1. Concrete: This is what is used in the internet today

5.6. Sessions and connections

Definition

Signaling: Session Management Signaling is the process of setting up, managing, and tearing down a communication session before real-time data flows. Signaling encompasses multiple processes:

• Session Setup
• Codec Negotiation
• Process where two peers agree on a common codec for audio/video during signaling
• NAT Traversal
• Techniques + Protocols that allow devices behind NAT to communicate directly
• There are three main techniques
  1. Session Traversal Utilities for NAT (STUN)
     • Device asks STUN server "What's my public IP:port?"
     • Device shares info with other peer (P2P)
     • Works only if NAT keeps mappings stable
  2. Traversal Using Relays around NAT (TURN)
     • Both devices send media to a TURN server
     • Used as fallback if direct P2P fails
     • Higher latency + server bandwith cost
  3. Interactive Connectivity Establishment (ICE)
     • Gathers candidates
       • Private IP:port
       • Public IP:port from STUN
       • Relay addresses from TURN
     • Tries all possible paths
     • Picks the fastest, lowest-latency route
• Encryption keys exchange
• Exchange session metadata

5.7. Web Identifiers

5.7.1. Defining IP address ranges

• CIDR blocks
  • Protocol that allows defining a range of valid IP addresses
  • Notation: <ip address>/<prefix length>
    • Prefix length determines how many bits in the address are fixed
• Classless Inter-Domain Routing

5.8. Telco 101:

• Cell Tower
  • Software Components i.e. Base Station Software Stack
    • Radio Access Network (RAN) Software
      • Handles communication between mobile devices and cell tower, e.g.
        • Handover Control: Deciding when phone switches from one tower to another
        • Radio Resource Control (RRC): managing spectrum and assigning frequencies to devices
        • MAC & PHY Scheduling: Deciding which user gets how much bandwidth every millisecond
        • Security & Authentication: Encrypting radio traffic before it hits the core
        • Quality of Service: Prioritising latency-sensitive traffic like voice and video
    • Cell Tower OS
      • Manages hardware scheduling, memory and task prioritisation
    • Management Software
      • For engineers to monitor and configure the cell tower
  • Hardware Components
    • Antennas: Send/receive radio signals
    • Remote Radio Unit (RRU): Converts radio waves to/from digital data
    • Baseband Unit (BBU): Runs the base station software stack
      • In 5G, BBUs are
        • centralised in regional data centers
        • serve dozens of towers
        • do not exist on the cell tower
    • Backhaul: Connection to core network via
      • Fiber (Most common)
      • Microwave (rural areas)
      • Satellite (remote locations)

5.9. WebRTC

• Frameworks

  • Web Real-Time Connection (WebRTC)
    • Open source framework for P2P RTC
    • Components
      • Signaling
      • Media Capture
      • Media Transport
      • Encryption
      • NAT Traversal
      • Adaptive Quality
      • Data Channels

• Signaling Protocols

  • Session Initiation Protocol (SIP)
    • Set up, modify, tear down real-time sessions for voice/video/messaging

• Monitoring Protocols

  • Real-time Transport Control Protocol (RTCP)
    • Measures network performance metrics for RTP

• Security Protocols

  • Transport Layer Security (TLS)
    • Secures TCP
  • Datagram Transport Layer Security (DTLS)
    • Secures UDP
    • i.e. TLS for UDP

• Transport Protocols

  • Real-time Transport Protocol (RTP)
    • Transports real-time media (audio/video)
    • Rides on UDP, sometimes TCP
  • Secure Real-time Transport Protocol (SRTP)
    • Encrypted RTP
    • Uses DTLS for key exchange
  • RTCP

• Network Address Translation (NAT)

  • NAT Devices
    • Home Routers
    • Corporate Firewalls
  • Vanilla NAT
    • 1:1 mapping between private IPs to public IPs (e.g. 192.168.0.1 (private) : 203.0.113.1 (public))
    • Provides control over private IP ranges
    • Single source of truth for configuring public/private IP mappings (e.g. ISP changes IP allocations)
  • Port Address Translation (PAT) a.k.a NAT Overload
    • 1:many mapping between private IPs to public IPs by using ports as well
      • e.g.
        • 192.168.0.10:52301 -> 203.0.113.7:40001
        • 192.168.0.11:52301 -> 203.0.113.7:40002
    • Workaround to IPv4's small address space, not needed in IPv6 where 1:1 mappings are encouraged

• Firewall

  • Decides which packets are allowed/blocked
  • Lives between private network and public internet
  • Typically blocks incoming connections, not outgoing
  • Corporates typically block UDP entirely because the lack of handshakes make it hard for firewalls to understand the session state

5.10. Wireless Systems

• Application
• Transport / IP
• Radio Resource Control (RRC): Manages radio resources and connection states between base station and user device
  • Types of radio resources:
    • Time
    • Frequency
    • Power
    • Modulation & Coding
    • Bearer
    • Control
    • Random access
    • Beamforming
  • Types of connection states:
    • RRC_IDLE
    • RRC_INACTIVE (5G)
    • RRC_CONNECTED
• PDCP
• RLC
• Medium Access Control (MAC) Layer: Decides who gets to transmit, when, and how much bandwidth
• Physical (PHY) Layer: Deals with actual signal transmission over radio waves (modulation, power levels etc.)

5.11. Network Protocols

Application Layer

Signaling Layer

• Voice over Public Switched Telephone Network (PSTN)
  • Dedicated E2E path between landlines/mobile phones using circuit switchers
  • Transmits uncompressed voice using Pulse Code Modulation (PCM) at 64 kbps per call
  • Used in landlines and mobile phones when on connections of < 4G
  • >4G and above
  • Carrier provides QoS guarantees
• Voice over IP
  • Transmits voice using IP
  • No QoS guarantees, call quality depends on network connection
• Video over IP
  • Transmits video using IP

5.12. Links

• DS&A
  • LeetCode
• System Design
  • interviewing.io guide
  • github system design primer flashcards
  • codemia.io practice questions