Video summary

System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra

Main summary

Key takeaways

Educational

Main ideas & lessons conveyed

1) Mid-level → Senior mindset: architecture, tradeoffs, and decisions

  • A mid-level developer often focuses on implementing code or extending an existing architecture.
  • A senior engineer must be able to:
    • Design systems from scratch
    • Make decisions with rough requirements
    • Choose approaches while managing tradeoffs
    • Optimize for performance, data storage, and customer impact
  • The course claims to teach the practical “roadmap” and skills that lead to passing system design interviews and reaching senior roles.

2) Course structure / what’s covered (high-level roadmap)

The video presents a multi-part learning path:

  • Foundations of system design core concepts
  • API design
  • Database selection and data-layer design
  • Caching, CDNs, and load balancing
  • Big data processing (large-scale data handling)
  • Production design (making systems that work in real environments)
  • Designing systems specifically for interviews

3) Scaling begins with a simple single-server model, then expands

Methodology / step-by-step progression

  • Start with a single server setup:
    • One server hosts: web app, API endpoints, database, and cache.
  • Explain request flow at small scale:
    • Users access a domain (e.g., app.demo.com)
    • DNS maps domain → server IP
    • Client sends HTTP request to server
    • Server returns content:
      • HTML for browsers
      • JSON for mobile apps/APIs
  • Scale out by identifying pressure points:
    • When traffic grows, a single server becomes insufficient.
  • Separate into tiers:
    • Web tier (handles web/mobile traffic)
    • Data tier (handles the database)

4) Database selection: relational vs non-relational (NoSQL)

Relational (RDBMS)

  • Uses SQL and structured tables (rows/columns).
  • Examples mentioned: PostgreSQL, MySQL, Oracle, SQLite.
  • Advantages:
    • Strong support for joins
    • Strong consistency and integrity for transactions (ACID):
      • Atomicity, Consistency, Isolation, Durability

Non-relational (NoSQL)

  • Different models depending on needs:
    • Document stores (e.g., MongoDB) storing JSON-like documents
    • Wide-column stores (e.g., Cassandra, Cosmos DB)
    • Key-value stores (e.g., Redis, Memcached; often RAM-based for fast reads/writes)
    • Graph stores (e.g., Neo4j; entities/relationships as graphs)
  • Advantages:
    • Handles highly dynamic/large datasets
    • Optimized for low latency and scalability
    • Can model complex relationships differently (e.g., embedding instead of joins)

When to choose which

  • Use SQL when:
    • Data is well structured with clear relationships
    • You need strong consistency/transactional integrity (e.g., financial systems)
  • Use NoSQL when:
    • You need very low latency
    • Data is unstructured/semi-structured (e.g., JSON)
    • You need flexible, scalable storage for massive volumes (e.g., activity logs/recommendations)

5) Scaling approaches: vertical vs horizontal

Vertical scaling (“scale up”)

  • Add more resources to one server (CPU/RAM/etc.).
  • Pros: simple
  • Cons:
    • Resource limits
    • No redundancy (server failure can take the system down)

Horizontal scaling (“scale out”)

  • Add more servers and distribute load.
  • Pros:
    • Better fault tolerance (if one server fails, others continue)
    • Easier to scale further by adding more servers

6) Load balancing: purpose + strategies (core “how”)

Load balancer responsibilities

  • Distribute traffic across multiple servers
  • Avoid overloading any one server
  • Provide fault tolerance:
    • Stop sending traffic to failed servers
    • Resume when they recover

Horizontal scaling implementation detail

  • Clients don’t “pick a server.”
  • A load balancer sits in the middle and routes requests.

Seven load balancing strategies

  • Round robin
    • Sequentially rotates requests across the server pool
    • Works best when servers are similar
  • Least connections
    • Routes to server with fewest active connections
    • Useful when session lengths vary
  • Least response time
    • Chooses server based on best (lowest) response time, considering active connections
    • Targets faster response under mixed server performance
  • IP hash
    • Hash client IP → consistently maps client to the same server
    • Helpful when session consistency matters
  • Weighted algorithms (e.g., weighted round robin / weighted least connections)
    • Assign weights based on capacity/performance metrics (e.g., RAM)
    • Higher-weight servers receive more traffic
  • Geographical routing
    • Send requests to geographically closest server (latency reduction)
  • Consistent hashing
    • Uses a hash ring so the same client consistently maps to the same server
    • Helps reduce remapping when nodes change
    • Similar goal to IP hashing, but more scalable for dynamic pools

Health checks

  • Load balancers monitor server availability by periodically sending health checks.
  • Routing excludes servers marked unhealthy until health checks succeed again.

Load balancer examples (types)

  • Software:
    • Nginx, HAProxy
  • Hardware:
    • F5, Citrix
  • Cloud:
    • AWS Elastic Load Balancing, Azure Load Balancer, Google Cloud Load Balancing
    • Claims: security, auto-scaling, monitoring/health checks

7) Single point of failure: why it’s dangerous + how to fix it

Definition

  • A component whose failure can take down the whole system.

Example given

  • If one shared database goes down, API servers fail and clients receive no responses.

Problems caused

  • Reliability: outage → business loss
  • Scalability: one failing component blocks growth
  • Security: attackers can target the single choke point (e.g., overload load balancer)

Avoiding load balancer single points of failure

  • Strategy 1: Redundancy
    • Multiple load balancers
    • If one fails, route traffic to the remaining one(s)
    • Monitor recovery and gradually shift traffic back
  • Strategy 2: Health checks & monitoring of load balancers
    • Detect load balancer failures and stop routing to them
  • Strategy 3: Self-healing
    • Replace failed load balancer instances automatically to prevent interruption

API design section

8) What APIs are (core concept)

  • API = Application Programming Interface
  • Acts as a contract defining:
    • What requests clients can make (endpoints, methods)
    • What responses they get
  • Key roles:
    • Abstraction: hides internal implementation details
    • Service boundaries: enables separate components/servers to communicate

9) Three main API styles: REST, GraphQL, gRPC

REST

  • Resource-based with HTTP methods
  • Stateless requests (each request includes everything needed)
  • Standard methods:
    • GET (fetch), POST (create), PUT/PATCH (update), DELETE (remove)
  • Typically used for web/mobile applications

GraphQL

  • Single endpoint for operations (commonly /graphql)
  • Clients request exactly what they need:
    • Queries for reads
    • Mutations for updates
    • Subscriptions for real-time (mentioned conceptually)
  • Benefit: fewer round trips / avoids over-fetching
  • Positioned as good for complex UI requirements

gRPC

  • High-performance RPC using protocol buffers
  • Supports streaming and bidirectional communication
  • Best fit: microservices/internal server-to-server communication
  • Mentioned as least common among the three (for general public APIs)

10) API design principles (a checklist)

Four essential design principles

  • Consistency
    • Consistent naming, casing, and URL patterns
  • Simplicity
    • Minimize complexity; intuitive design so developers can use it without heavy docs
  • Security
    • Authentication/authorization
    • Validate inputs
    • Rate limiting
  • Performance
    • Caching strategies
    • Pagination for large datasets
    • Minimize payload size
    • Reduce round trips (embed needed data where appropriate)

11) API design process (lifecycle / methodology)

Process flow

  • Requirements/design:
    • Identify core use cases & user stories
    • Define scope/boundaries (in-scope vs out-of-scope)
    • Define performance requirements and likely bottlenecks
    • Include security constraints early
  • Design approaches:
    • Top-down: start from requirements/workflows (common in interviews)
    • Bottom-up: start from existing data models/capabilities (common in companies)
    • Contract-first: define request/response contract before implementation (like top-down)
  • Lifecycle management:
    • Design → development (possibly local testing)
    • Deploy & monitor (staging/production testing)
    • Maintain (keep design simple for future maintainability)
    • Deprecate/retire old versions when new versions replace them

Authentication & authorization section

12) Authentication vs authorization

  • Authentication: “Who are you?”
    • Verifies identity; failing leads to 401 Unauthorized
  • Authorization: “What can you do?”
    • Determines permissions/actions/resources after login

13) Major authentication methods (conceptual tour)

Basic authentication

  • Base64(username:password) in Authorization header
  • Only safe with HTTPS; rarely used in modern production

Digest authentication

  • Similar challenge-response idea but uses MD5 hashing
  • Still outdated/rare today

API key authentication

  • Client sends key (e.g., Authorization or X-API-Key)
  • Server looks up/validates key and scopes in storage
  • Weakness:
    • If leaked, attacker can use it (no inherent expiration unless added)

Session-based authentication

  • Server stores session state (memory/Redis/DB)
  • Cookie-based session ID
  • Challenge:
    • Stateful; harder to scale for APIs/distributed systems

Token-based authentication

  • Client sends a token with each request (commonly via Bearer token)
  • Bearer token = a pattern (“whoever has the token gets access”), not a specific format
  • Common token format: JWT
    • Signed JSON claims: user identity, expiration, roles/permissions
    • Enables stateless verification (reduces DB dependency)
  • Access vs refresh tokens:
    • Access token: short-lived (minutes to ~1 hour)
    • Refresh token: long-lived (days/weeks)
    • Refresh token stored in HTTP-only cookies (avoid XSS token theft)
    • When access token expires, use refresh token to obtain a new access token

OAuth 2 / OpenID Connect / SSO clarification

  • OAuth 2:
    • Authorization framework, not authentication
    • Gives an app permission to access user resources (delegated access)
  • OpenID Connect (OIDC):
    • Adds authentication on top of OAuth 2
    • Provides an ID token (JWT) containing identity claims
  • Single sign-on (SSO):
    • UX pattern (log in once to access multiple services)
    • Built on identity protocols underneath:
      • SAML (XML-based; common in enterprise/legacy)
      • OpenID Connect (modern; JSON-based ID token)

14) Authorization models (three main types)

RBAC (Role-Based Access Control)

  • Users assigned roles (admin/editor/viewer)
  • Roles map to permissions
  • Used widely in dashboards/tools (example: GitHub)

ABAC (Attribute-Based Access Control)

  • Policies depend on user/resource/environment attributes
  • More flexible but more complex and can have conflicts
  • Examples: department-based rules, time/location/device conditions

ACL (Access Control Lists)

  • Each resource has its own permission list
  • Highly specific; can be harder to scale to very large systems
  • Example mentioned: Google Drive/Docs sharing model

15) OAuth 2 & JWT in enforcing authorization

  • OAuth 2 supports delegated authorization:
    • Apps receive tokens representing permissions (instead of using the user’s password)
  • JWT/bearer token:
    • Carries identity and claims (roles/scopes)
    • Backend checks token validity then applies permission logic defined by authorization model

API security section

16) Protecting APIs: seven techniques (detailed bullet checklist)

Goal: prevent attackers from abusing unsecured endpoints.

  1. Rate limiting

    • Limit requests per time window per:
      • Endpoint
      • User / IP address
      • Overall traffic (helps against bot-driven attempts and DDoS-style flooding)
    • If limit exceeded:
      • Block further requests temporarily until window resets / root cause investigated

  2. CORS (Cross-Origin Resource Sharing)

    • Restrict which browser origins can call the API
    • Prevent malicious sites from using the browser to make requests on users’ behalf
    • Example rule: allow only app.yourdomain.com, block other domains

  3. SQL/NoSQL injection prevention

    • Problem: injection occurs when user input is directly included in queries
    • Fix:
      • Use parameterized queries / ORM safeguards
    • Prevents attackers from reading/modifying/deleting data via crafted input

  4. Firewalls

    • Gatekeeper filtering suspicious traffic before it hits the API
    • Example: AWS WAF-like behavior (block known attack patterns, suspicious HTTP methods/SQL keywords)

  5. VPN for private APIs

    • Restrict access to internal networks only
    • Only users inside the VPN can reach internal endpoints (e.g., admin tools)

  6. CSRF (Cross-Site Request Forgery)

    • Attack: trick a logged-in browser (often cookie-auth) into sending unwanted requests
    • Fix:
      • Use CSRF tokens in addition to session cookies
      • Server verifies token matches expected value

  7. XSS (Cross-Site Scripting)

    • Attack: inject malicious scripts into content displayed to other users
    • Example scenario:
      • Comment includes script → stored → later rendered in other users’ browsers → script executes
    • Risk: cookie theft, malicious actions, data tampering via injected script

Speakers / sources featured

  • Hayek (credited as the developer/creator who “developed this course” and as the instructor)
  • Alex Simonyan (mentioned as the YouTube channel name to search for; referenced as having system design content)
  • Organizations/products mentioned as examples (not speakers):
    • AWS, Azure, Google Cloud, Nginx, HAProxy, F5, Citrix, Redis, MongoDB, Cassandra, Neo4j, PostgreSQL, MySQL, Oracle, SQLite
    • Facebook (GraphQL origin), Google (gRPC; protocol buffers; API examples)
    • OAuth/OpenID Connect providers, GitHub, Stripe, Salesforce, Vercel, Okta
    • Google Drive/Docs/Neptune, WhatsApp/Spotify/TinyURL

Original video