Here are your notes on the video about system design:
Course Overview:
Subject: System Design for software developers and engineers.
Developer: Gaurav Sen (experienced software engineer with a popular
YouTube channel).
* Learning Objectives:
Understand basic engineering design patterns for large-scale
distributed systems.
Apply these principles to design and code a live streaming
video app.
Target Audience: Beginners in system design, those with little to
no experience, or those who have only read about it.
Key Concepts Explained:
1. Large-Scale Distributed Systems:
Large-Scale: Systems used a lot, intensive in compute/data, or
have high performance expectations (e.g., Google Maps).
Characteristics: Large data storage, high user base,
frequent updates, demanding performance (quick results, accuracy,
availability).
Distributed Systems: Servers/code execution is spread globally,
not in one location.
Benefits: Fault tolerance (if one server fails, others take
over), performance (users connect to nearby servers for faster
results).
2. Design Patterns:
Practices, principles, or processes engineers use to build
systems.
Example: Solving the problem of distributing a single piece of
content (e.g., a social media post) to millions of followers quickly
without overloading the service.
Solution: Publisher-subscriber model (one entity publishes an
event, millions subscribe). The model manages the pace of
notifications to prevent server overload and ensure delivery.
Purpose: Enable engineers to convert business requirements into
reliable, scalable, and maintainable technical solutions.
3. Designing a Live Streaming System (Example):
* Step 1: Define Requirements (from user perspective):
Engineers often rely on Product Requirement Documents
(PRDs) written by product managers based on user feedback.
Prioritize core features (e.g., users must be able to watch
the stream live) over secondary ones (e.g., video quality like HD vs.
480p).
* Step 2: Reduce Features to Data Definitions:
Abstract concepts (e.g., "liking a video") are translated
Страница 1 из 4
into data structures.
Example: A "like" involves a user ID, a video/comment ID,
and a timestamp. Comments have ID, author, creation time, and thread
information.
These definitions map to objects and then to database
schemas.
* Step 3: Define Endpoints (APIs):
Create APIs (e.g., `getVideo`, `postComment`) to allow
external users to query and manipulate data.
Network protocols (HTTP, gRPC, FTP) define how signals are
sent and responses are received.
* Step 4: Consider Engineering Requirements:
Reliability/Fault Tolerance: Avoid single points of failure
by distributing servers globally or having redundant servers within a
region. Data duplication or partitioning can help.
Extensibility: Design solutions that are easy to modify as
requirements change (e.g., adding "read receipts" to messaging).
Avoid tightly coupled code.
* Step 5: Testing:
Test the design with edge cases and common scenarios.
Use load testing tools and capacity estimation to validate
feasibility.
Testing should occur *before* coding.
System Design Considerations for Live Streaming:
Requirements Recap: Streaming video, processing, broadcasting to
millions, fault tolerance, advertisements, reactions, disclaimers,
graceful degradation of quality, multi-device support.
Data Storage: Raw footage (e.g., 8K) is impractical to stream
directly. Needs to be stored (database/file system) and queried. The
internal implementation should be a "black box" to end-users.
* APIs:
`getVideoFrame(videoID, deviceType, offset)`: Returns a
specific frame based on device and progress.
`postComment(videoID, commentData, author)`: Allows users to
post comments.
* Database:
Comments: Suitable for SQL databases (tables for comments,
users, videos).
Video Data: Large files, better suited for file systems (e.g.,
HDFS, Amazon S3) or specialized video hosting solutions (e.g., Wimu).
MySQL could be used but might be expensive and slow for large video
files. NoSQL databases are good for scalable, key-value data like
comments if relational joins aren't needed.
* Network Protocols:
Comments: HTTP is suitable (stateless, widely used).
* Video Frames:
HTTP can be used, but protocols designed for streaming are
better.
Страница 2 из 4
DASH (Dynamic Adaptive Streaming over HTTP): Adapts video
quality based on bandwidth and device.
HLS (HTTP Live Streaming): Similar to DASH, common for
iOS/Mac.
WebRTC: Peer-to-peer, good for video conferencing, but
potentially less ideal for pure broadcasting.
RTMP (Real-Time Messaging Protocol): Reliable protocol
often used at the source for video ingestion to prevent data loss.
Stateful vs. Stateless:
Stateless: Server doesn't store client context (e.g., current
video position). All necessary info is in the request. Benefit:
easier scaling, no lost context on server crash. HTTP is stateless.
Stateful: Server remembers client context. Benefit: simpler
client requests (e.g., "get next 10 seconds"). Drawback: complexity
in scaling and recovery.
* Server-Side Considerations:
Choosing appropriate database solutions (SQL vs. NoSQL vs. File
Systems).
Using existing tools/services (Redis for caching, load
balancers, message queues) vs. building from scratch.
* Content Delivery Networks (CDNs):
Used to cache and deliver static content (including video)
closer to users, improving performance and reducing server load.
Authentication challenges arise with CDNs.
* Video Transformation:
Raw footage needs to be converted into various resolutions
(144p, 480p, 720p, 1080p, 4K) and formats (e.g., H.264 for broad
compatibility, proprietary formats for efficiency).
MapReduce Pattern: Used for processing large datasets in
parallel. Video segments can be processed concurrently on different
servers for transformation and compression.
* Caching:
Caching recent video segments on the server can reduce latency
and bandwidth usage for users re-watching or continuing videos.
* Low-Level Design:
Focuses on detailed implementation of specific components.
Use Case Diagrams: Identify actors (customer, admin,
videographer) and their actions (play video, upload, add metadata).
Class Diagrams: Define objects (Video, User, WatchedVideo,
VideoConsumingService) with their states (data) and behaviors
(methods).
Sequence Diagrams: Illustrate the order of interactions between
objects over time (e.g., user requests frame, service retrieves from
video service, video service gets frame from video data).
Coding: Translating diagrams into actual code, ensuring objects
interact correctly, managing state, and handling edge cases (e.g.,
invalid timestamps, out-of-bounds requests).
Optimization: Using constants for frame durations, handling
timestamps correctly, considering memory optimizations (caching).
API Design: Clear APIs simplify low-level design and
Страница 3 из 4
implementation. Differentiating business use cases (e.g., seeking vs.
background buffering) even if technical implementation is similar.
Key Takeaway: System design involves understanding requirements,
defining data and APIs, selecting appropriate technologies
(protocols, databases), considering scalability and reliability, and
then detailing the implementation through diagrams and code.
Страница 4 из 4
