Video summary

System Design Explained: APIs, Databases, Caching, CDNs, Load Balancing & Production Infra

Main summary

Key takeaways

Educational

Main ideas / lessons conveyed

1) System design is becoming the key senior-level skill

  • AI-assisted coding (“agentic development”) is accelerating, so interviews and senior hiring increasingly test:
    • High-level understanding of system components
    • Architectural decision-making at scale
    • Ability to explain trade-offs and how parts interact
  • System design is framed as necessary even if you’re not the person making every architectural decision.
  • The course described in the subtitles aims to teach senior+ proven skills through a structured progression.

2) Course structure (explicit 5-step methodology)

  1. Step 1: Foundations
    • Core system architecture concepts every engineer should know.
  2. Step 2: API design
    • Creating API contracts
    • API versioning
    • Communication patterns
    • Designing APIs from scratch
  3. Step 3: Databases
    • Storage patterns
    • Consistency models
    • Choosing the right database type for the application
  4. Step 4: Scaling & reliability
    • Scaling and performance optimization
    • Caching
    • Reliability engineering
    • Handling failure modes / points of failure
  5. Step 5: Interview preparation
    • How to pass system design interviews
    • How to prepare for them for nearly any role applied to

System design concepts covered

3) Start small: single-server architecture, then scale out

  • Principle: “Every complex system starts with something simple.”
  • Lesson approach: build and reason about a minimal setup first, then expand.

Single-server setup components (as described):

  • Web application serving HTML/CSS/JS
  • API endpoints for mobile clients
  • One database
  • One cache (mentioned as part of the single-server stack)

Request flow at a high level:

  • Users access a domain (e.g., app.demo.com)
  • DNS maps the domain to the server IP
  • Client sends HTTP requests to the server
  • Server returns either:
    • HTML for browser requests, or
    • JSON for mobile/API requests

Key takeaway before scaling: this setup works for small user bases but struggles under heavy traffic.

4) Scale using tiers: separate web tier and data tier

As user demand grows:

  • Split web tier (handles web/mobile traffic + business logic/presentation)
  • Split data tier (manages the database)
  • Scale each part according to its specific load.

Databases: relational vs non-relational

5) Relational databases (RDBMS / SQL)

  • Examples mentioned: PostgreSQL, MySQL, Oracle, SQLite
  • Core structure: tables, rows, columns
  • Main advantages:
    • Joins across multiple tables (e.g., customers + products → orders)
    • ACID transactions and integrity:
      • Atomicity (all-or-nothing)
      • Consistency (moves between valid states)
      • Isolation (concurrent transactions don’t interfere)
      • Durability (survives failures)

6) Non-relational databases (NoSQL) and their types

Types listed (with examples):

  • Document stores: MongoDB (JSON-like documents)
  • Wide-column stores: Cassandra, Cosmos DB (dynamic columns, very large scale writes)
  • Graph stores: Neo4j (entities + relationships; example: recommendations via Neptune)
  • Key-value stores: Redis, Memcached (often RAM-based; fast reads/writes)

NoSQL advantages (as described):

  • Supports dynamic / flexible schemas
  • Handles large datasets with lower-latency and scalability
  • Can model “joins” differently (e.g., embedding related data in one document)

7) When to choose SQL vs NoSQL (decision guidance)

  • Use SQL when:
    • Data has clear structure and relationships
    • You need strong consistency and transactional integrity (e.g., banking/financial)
  • Use NoSQL when:
    • You need super low latency
    • Data is unstructured/semi-structured (e.g., JSON objects)
    • You need flexible scalable storage for massive volumes (e.g., recommendation engines)

Scaling: vertical vs horizontal + load balancing

8) Vertical scaling (“scale up”) vs horizontal scaling (“scale out”)

  • Vertical scaling:
    • Add CPU/RAM/resources to one server
    • Works for low/moderate traffic
    • Limits:
      • Hard resource caps
      • Redundancy problems (if the server fails, the app goes down)
  • Horizontal scaling:
    • Add more servers and distribute load
    • Benefits:
      • Better fault tolerance (other servers can keep serving)
      • Better scalability (add servers as traffic grows)

9) Load balancer purpose

When multiple servers exist, a load balancer sits in the middle:

  • Routes client requests to the appropriate backend server
  • Avoids sending traffic to failed servers
  • Distributes load to keep utilization even

10) Load balancing strategies / algorithms (explicit list of 7)

  1. Round robin
    • Sequentially rotates requests across servers
    • Best when servers have similar capacity
  2. Least connections
    • Sends traffic to the server with the fewest active connections
    • Useful when session lengths vary
  3. Least response time
    • Chooses server with the best responsiveness (also considers active connections)
    • Best for fastest end-to-end responses with heterogeneous servers
  4. IP hash
    • Hashes client IP to consistently route a client to the same server
    • Useful for session stickiness
  5. Weighted algorithms (e.g., weighted round robin / weighted least connections)
    • Assign weights based on capacity/performance (e.g., RAM)
  6. Geographical / location-based
    • Routes users to the nearest region (latency reduction)
  7. Consistent hashing
    • Uses a hash ring so clients map predictably to nodes
    • Helps with consistency and redistribution when nodes change

11) How load balancers avoid routing to dead servers

  • Health checks:
    • Load balancers monitor backends via periodic health check requests
    • If a server fails checks, it is removed from routing until recovery

12) Load balancer implementations (examples)

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

13) Single point of failure (SPOF) and how to avoid it

  • Definition: a component whose failure brings down the entire system
  • Example given: a single shared database for multiple APIs
    • If DB goes down → all APIs fail → clients can’t get responses

Impacts described:

  • Reliability risk → business losses
  • Scalability risk → harder to safely scale
  • Security risk → attackers could target the SPOF (e.g., overload load balancer)

Strategies to avoid SPOF for load balancers:

  1. Redundancy
    • Use multiple load balancers; route traffic to healthy one(s)
    • Gradually shift back when the failed one recovers
  2. Health checks + monitoring
    • Detect load balancer failures and stop routing to them
  3. Self-healing
    • Automatically replace failed load balancer with a new instance

API design: concepts, styles, principles, and process

14) What an API is (core framing)

  • API = Application Programming Interface
  • Defines a contract between clients and servers:
    • Which requests can be made (endpoints, methods)
    • What responses to expect (formats, fields)

APIs provide:

  • Abstraction (hide implementation details)
  • Service boundaries (components communicate through stable interfaces)

15) API styles covered

  1. REST
    • Resource-based, uses HTTP methods
    • Stateless (each request contains needed info)
    • Common HTTP methods:
      • GET (read), POST (create), PUT/PATCH (update), DELETE (remove)
    • Common in web/mobile
  2. GraphQL
    • Single endpoint
    • Clients request exactly what they need
    • Operations:
      • Query (read), Mutation (write), Subscription (real-time)
    • Benefits:
      • Fewer round trips / avoids over-fetching
    • Versioning typically via schema evolution; can version fields if needed
  3. gRPC
    • High-performance RPC framework
    • Uses Protocol Buffers
    • Supports streaming and bidirectional communication
    • Most useful for internal server-to-server communication (microservices)

16) API design principles (explicit “4 pillars”)

  • Consistency
    • Consistent naming, casing, URL patterns
  • Simplicity
    • Minimize complexity; intuitive endpoints so devs don’t need to read docs
  • Security
    • Authentication/authorization
    • Input validation
    • Rate limiting
  • Performance
    • Caching strategies
    • Pagination for large datasets
    • Minimize payload size
    • Reduce round trips by bundling small required data

17) Protocol choice shapes API design

  • HTTP enables REST features (CRUD + status codes).
  • WebSockets enable real-time, bidirectional communication.
  • gRPC typically for microservices; HTTP/2-based transport performance benefits.

18) API design process (life cycle steps described)

  • Design phase
    • Understand requirements (core use cases/user stories)
    • Define scope and boundaries
    • Determine performance needs / expected bottlenecks
    • Account for security constraints early
  • Development/testing
    • Implement and test (local first, then more in staging/prod)
  • Deployment & monitoring
    • Deploy, then monitor and test in production/staging
  • Maintenance
    • Keep APIs simple/maintainable for future developers
  • Deprecation/retirement
    • Retire older versions when migrating (e.g., V1 → V2)

API protocols + transport layers (network stack)

19) Application layer protocols (covered)

  • HTTP
    • Request/response model using methods + URL + auth + status codes + headers
    • Status code categories mentioned:
      • 200 success, 300 redirects, 400 client errors, 500 server errors
  • HTTPS
    • HTTP + TLS/SSL encryption
    • Benefits: encryption in transit, integrity, authentication, SEO benefits
    • “Golden standard”: use HTTPS
  • WebSockets
    • Designed for real-time push
    • Uses handshake then bidirectional communication
    • Avoids inefficient HTTP polling (latency/bandwidth/resource savings)
  • AMQP (Advanced Message Queuing Protocol)
    • Asynchronous messaging with producer/consumer + broker + queues
    • Mentioned features like exchange types (direct, fanout, topic)
  • gRPC
    • Uses protocol buffers and typically HTTP/2 for efficient transport
    • Most used between servers

20) Transport layer: TCP vs UDP (decision framework)

  • TCP
    • Reliable but slower
    • Connection-based (three-way handshake)
    • Ensures ordering and retransmits lost/out-of-order packets
    • Used for payments, authentication, user data (per example)
  • UDP
    • Faster but unreliable
    • No delivery guarantee, no handshake/connection tracking
    • Used for video calls, live streams, gaming where packet loss is acceptable
  • Trade-off summary
    • Need reliable/accurate delivery → TCP
    • Need low-latency and can tolerate loss → UDP

RESTful API best practices (resource modeling + CRUD)

21) Resource modeling and URL design

  • Model nouns, not verbs
    • products, orders, reviews rather than getProducts
  • Collections vs individual resources:
    • /products → collection
    • /products/{id} → single item
  • Nested resources:
    • /products/{id}/reviews for product-specific reviews

22) Filtering, sorting, pagination (explicit instructions)

  • Filtering (query params)
    • Example: filter by category and “in stock”
  • Sorting (query params)
    • Example: sort by price or ratings ascending/descending
    • Sorting should be done server-side to avoid client inefficiency
  • Pagination (query params)
    • Page-based: page, limit
    • Offset-based: offset, limit
    • Cursor-based: pass a cursor (e.g., hash) for next page
  • Benefits stated
    • Saves bandwidth
    • Improves performance for server + front end
    • Fetch only what the UI needs

23) HTTP methods mapped to CRUD semantics

  • GET: read (safe, idempotent)
  • POST: create (changes server state, not idempotent)
  • PUT: replace whole resource
  • PATCH: partially update resource
  • DELETE: remove resource

24) REST status codes and error handling

  • 2xx: 200 OK, 201 created, 204 no content
  • 3xx: redirects
  • 4xx: client errors (400 bad request, 401 unauthorized, 404 not found)
  • 5xx: server errors (500)

25) REST best practices recap (explicit)

  • Use plural nouns for resources
  • Use correct HTTP methods for the intended action
  • Support filtering/sorting/pagination
  • Use versioning (e.g., /api/v1/...)
    • Keeps old clients stable during breaking changes

GraphQL concepts + error handling + best practices

26) Why GraphQL exists (problem it solves)

  • REST can cause:
    • Under/over-fetching
    • Multiple API calls needed to assemble one UI view
    • Increased latency while waiting for all responses
  • GraphQL fixes this with:
    • Single endpoint
    • Client-defined response shape per query

27) GraphQL schema/type system (what it is)

  • Schema = contract between client and server
  • Types model domain objects (e.g., User with fields)
  • Schema includes:
    • Queries (read)
    • Mutations (write)

28) GraphQL operations and client control

  • Clients request exactly needed fields (e.g., user name + selected post fields)
  • Mutations specify input fields and can request which fields to return afterward

29) GraphQL error handling difference vs REST

  • GraphQL typically returns HTTP 200 even when errors occur
  • Errors are provided in an errors field of the response
  • Partial data may still be returned alongside errors

30) GraphQL API best practices

  • Keep schemas small and modular
  • Avoid deep nesting; enforce max query depth
  • Use meaningful naming for types/fields
  • Use input types for mutations

Authentication vs authorization + detailed authentication methods

31) Key definitions

  • Authentication: verifies “who the user/service is”
  • Authorization: determines “what they can do/access”

32) Authentication methods covered (and their characteristics)

  • Basic authentication
    • Base64(username:password) in Authorization header
    • Not secure unless under HTTPS; rarely used in production
  • Digest authentication
    • Uses MD5 hashing; still outdated
  • API key authentication
    • Client sends key in Authorization header or X-API-Key
    • Server looks up key + scopes/permissions
    • Risks:
      • If leaked, can be abused
      • No expiration by default unless implemented
  • Session-based authentication
    • Server creates session on login; stores session server-side
    • Session storage options mentioned:
      • In-memory (not durable across restarts)
      • Redis (common in production; supports expiration)
      • SQL/dedicated DB
      • File system (rare; not scalable)
    • Uses cookies; server checks session on each request
    • Challenge: stateful sessions are harder to scale for distributed APIs
  • Bearer authentication / JWT
    • Client sends token every request
    • JWT is signed JSON with claims (identity, expiration, roles/permissions)
    • JWT can be stateless (no DB lookup every time)
    • Access vs refresh tokens
      • Access token: short-lived (15 min to 1 hour)
      • Refresh token: long-lived (days/weeks)
      • Store refresh token in HTTP-only cookies
  • OAuth 2
    • Clarified as authorization framework, not authentication
    • Delegated access to resources on behalf of the user
  • OpenID Connect (OIDC)
    • Authentication layer built on OAuth 2
    • Uses an ID token (JWT) to convey identity (email/user id)
  • Single Sign-On (SSO)
    • UX pattern: log in once, access multiple services
    • Uses underlying identity protocols:
      • SAML (XML-based; common in enterprise/legacy)
      • OpenID Connect (more modern; JSON/JWT)

Authorization models + enforcement patterns

33) Three main authorization models

  1. RBAC (Role-based access control)
    • Users assigned roles (admin/editor/viewer) → roles map to permissions
  2. ABAC (Attribute-based access control)
    • Policies based on user attributes, resource attributes, and environment conditions
  3. ACL (Access control lists)
    • Each resource has its own permission list (who can do what)

34) Real-world enforcement context described

  • Tokens (OAuth2/JWT/bearer tokens) carry identity/claims and are used by backends to apply permission logic.
  • Distinction emphasized:
    • Tokens are mechanisms
    • Authorization models define what is allowed

API security: 7 techniques (explicit list)

35) Seven proven API protection techniques

  1. Rate limiting
    • Limit requests per time window
    • Can be per endpoint, per user/IP
    • Include overall rate limiting to mitigate DDoS and bot swarms
  2. CORS (Cross-Origin Resource Sharing)
    • Restrict which browser origins may call the API
    • Prevent malicious sites from calling API on behalf of users
  3. Prevent SQL/NoSQL injection
    • Use parameterized queries and/or ORM safeguards
  4. Firewalls
    • Block malicious traffic patterns (e.g., suspicious keywords/methods)
    • Example mentioned: AWS WAF
  5. VPN for private/internal APIs
    • Limit access to users within a network (internal tools use this)
  6. CSRF protection
    • Prevent forged requests from another site using CSRF tokens + cookie checks
  7. XSS protection
    • Prevent injection of scripts into

Original video