1. C1: System Context Design

1.1. Key Questions

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

1.2. Making decisions

• All decisions, at a high level, are an optimisation for
  • Functionality (Profit)
  • Cost (Loss)

1.3. CAP Theorem

1.4. Tenancy

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

1.5. Types of Development

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

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

1.7. Compliance

1.7.1. 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.8. Best Practices to Scale

Duplexity: Initiation of communication + Sending of data + Concurrency

1.9. 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

2. C2: Container Design

2.1. Typical Cloud Infrastructure

to be integrated into table above

2.1.1. What is a load balancer?

2.1.2. What is a gateway?

A gateway is a specialised, stateful compute optimised for:

• connection handling
• routing
• auth
• fanout

2.2. Databases

2.3. Rendering Strategy

2.4. Strategies to serve SPAs

2.5. API Architectural Styles

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

2.6. Transport Protocols

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

What common combinations are there?

3. C3: Component Design

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.2. Authentication

• There is a trade-off betweeen safety and convenience
• Best practise to use a pre-built library, but understanding the principles is helpful in system design
• Authentication: verifying identity
• Authorisation: checking permissions

3.2.1. Authentication

Transporting Passwords

• Use HTTPS for password submissions
• Avoid logging raw credentials

3.2.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

3.2.3. Proof of Authentication a.k.a access tokens

• After a user is authenticated, a token needs to be stored on the client
• There are two main types of tokens used: session tokens and JWTs

3.2.4. Refresh Tokens

• Clients can be provided with a refresh token that is used to refresh access tokens
• Access tokens should be short-lived (minutes)
• Refresh tokens can be long-lived (hours/days/weeks)
• Adv
  • Reduced exposure
  • Centralised control if using JWT access tokens and session refresh tokens

3.3. Authorisation

3.3.1. Which cloud layer to authenticate / authorise in

3.4. Sandboxing

3.5. Scaling

Types of horizontal scaling:

1. Database Horizontal Scaling
2. Compute Horizontal Scaling

Database Horizontal Scaling, i.e. sharding

Compute Horizontal Scaling

3.6. 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

3.7. Websockets

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

Distributed

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

Robustness: How do we ensure reliable message processing and delivery over time?

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

Issues and Mitigations

Pubsub

What types of pubsub brokers are there?

3.8. Caching

4. C4: Code Design

4.1. Encoding

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

4.2. Choosing a language for mobile app development

4.3. 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.

4.4. 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.

4.5. Data Structures & Algorithms

How to solve problems with code.

4.5.1. Methods to Reinterpret Problems

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

4.5.2. Modulo

4.5.3. Floor Division

4.5.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.5.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.5.6. Bitwise Operations

4.5.7. Dynamic Programming

• Caching results for fibonacci-style recurrence

4.5.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.5.9. Describing Symmetry

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

5. Concrete Knowledge

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

5.1. JavaScript

Engines

• V8 (Chrome)
• SpiderMonkey (Firefox)
• JavaScriptCore (Safari)
• Hermes (React Native)

Runtimes

• Node
  • V8 engine
  • Adv.
    • Mature ecosystem
    • Safest bet
  • Disadv.
    • Slower
    • Security via containers/OS policies
• Deno
  • V8 engine
  • Adv.
    • Like node but faster
  • Disadv.
    • Mostly compatible with node modules
    • Security via containers/OS policies
• Bun
  • JavaScriptCore engine
  • Adv.
    • Sandboxed
  • Disadv.
    • Least compatibility with node modules

5.2. CPU Optimisations

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

5.3. Language Optimisations

• Peephole Optimisations
• Inline
• Unroll

5.4. Operating Systems

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

5.5. 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

Typically uses a conatiner or VM

5.5.1. Data Types

• Objects are immutable, files are not
• Files are accessed via filepath, objects are accessed via API+key
• Fileshare scales vertically, objects scale horizontally

5.6. Container Orchestration

5.6.1. Orchestration Framework

5.6.2. Platform

5.7. 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.8. 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.9. 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

5.10. Transmission Control Protocol (TCP)

• Lossless

5.11. User Datagram Protocol (UDP)

• Lossy

5.12. Quick UDP Internet Connections (QUIC)

• UDP at Transport Layer + Reliability at App Layer

5.13. Which transport protocol

5.14. Distributed Websocket Approaches

5.15. 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 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.

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.

5.16. Performance Metrics

5.17. Adaptive Performance Strategies

5.18. 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.19. 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.20. 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.21. 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

5.22. Firewalls

5.23. 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

6. 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

7. Testing

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

7.1. 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

8. Concrete Knowledge

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

8.2. Choosing a library for local dev of cloud resources

AWS

8.3. Browser Storage

8.4. Request/Response Flags

8.5. Response Codes

8.6. Web Identifiers

8.7. Python

• Celery
  • Distributed task queue
    • e.g.

8.8. Git

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

8.9. S3

URL Types

8.10. Websockets

8.11. Virtual Private Clouds (VPCs)

8.11.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

8.11.2. Subnets

8.11.3. Connections

8.11.4. Routing Rules

8.11.5. Security Boundaries

8.12. React

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

9. Relational Databases

9.1. Database Terminology

• Statement
  • A single command
  • e.g. SELECT, UPDATE, FROM, WHERE
• Read / Query / Data Query Language (DQL)
  • A complete set of statements
  • Ends with a semicolon
  • e.g. SELECT * FROM fooTable;
• Write / Update / Data Modification Language (DML)
  • A complete set of statements
  • Ends with a semicolon
  • e.g. UPDATE fooTable SET colName = x;
• Read Result Set
  • Data returned from a query
• Update Acknowledgement
  • Confirmation returned from a query
  • e.g. x rows inserted
• Transaction
  • A group of queries executed as a single unit
  • e.g. BEGIN / START TRANSACTION -> COMMIT / ROLLBACK
• Session
  • A client's connection to the DB
• Database Object
  • Anything defined in a DB
  • e.g. Tables, Views, Indices, Stored Procedures, Triggers, Functions
• Schema
  • Logical grouping of DB objects
• Execution Plan
  • The strategy the DB optimiser chooses to run your query
  • e.g. index scan vs full scan, hash join

9.2. 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
   • ???

9.3. Database Isolation Levels

| Isolation Level | Dirty Reads |

10. Mobile

10.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

10.2. Splash Screen

Splash screens are only shown for cold start

11. Resources

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