1:25:37
System Design for Beginners (2026)
KodeKloud
Overview
This video introduces system design for beginners by walking through the process of building a photo-sharing application. It explains core concepts like load balancing, caching, replication, and sharding by introducing them as solutions to problems encountered as the application scales. The video differentiates between high-level and low-level design, emphasizes the importance of functional and non-functional requirements, and discusses architectural choices like monolith vs. microservices. It also covers scaling strategies (vertical vs. horizontal), the request lifecycle (DNS, HTTP/S), stateful vs. stateless servers, data modeling, SQL vs. NoSQL databases, indexing, and caching strategies like TTL and invalidation.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- System design is the skill of selecting and arranging software components to solve a problem.
- It's crucial for transitioning from junior to senior engineering roles, where responsibilities shift from feature development to system architecture.
- Learning system design involves understanding how systems are built and how they fail.
- The course uses a hands-on approach by designing a real application and introducing concepts as needed.
Understanding system design principles is essential for building scalable and reliable applications and is a key differentiator for senior engineers.
Designing a photo-sharing app, starting with a single server and progressively adding components to handle increased traffic and failures.
- Initial setup with one server fails under high traffic due to CPU/RAM overload.
- A load balancer distributes traffic across multiple servers to prevent overload.
- Databases become bottlenecks when handling repetitive queries; caching popular data in memory speeds up responses.
- Single points of failure (e.g., server death) are addressed by replicating data and using external storage.
These fundamental problems and their solutions (load balancing, caching, replication) are the building blocks of scalable systems.
When 10,000 users visit the photo app, the single server becomes slow. Adding a load balancer distributes requests, a cache stores popular photos, and data replication prevents data loss if a server fails.
- High-Level Design (HLD) focuses on the overall architecture, components, and data flow (e.g., designing Instagram).
- Low-Level Design (LLD) focuses on the implementation details of a specific feature or component (e.g., designing the 'like' button functionality).
- Functional requirements define what the app should do (e.g., upload photo, sign up).
- Non-functional requirements define how well the app should perform (e.g., speed, availability, durability, cost).
Distinguishing between HLD and LLD, and understanding functional vs. non-functional requirements, helps in structuring design discussions and prioritizing development efforts.
Designing Instagram is HLD; designing the 'like' feature's code logic is LLD. Functional requirements are 'upload photo'; non-functional requirements are 'feed loads in under 200ms' or 'photos are never lost'.
- Monolith architecture: a single codebase deployed as one unit, simpler for small teams and early stages.
- Microservices architecture: breaking the application into small, independent services, allowing for independent scaling and team autonomy.
- Monoliths are suitable for smaller applications due to simplicity and fewer inter-service communication issues.
- Microservices are beneficial for large applications needing independent scaling of components or for large development teams.
Choosing between monolith and microservices impacts scalability, development speed, and operational complexity, and the right choice depends on the application's stage and scale.
A small photo app with a few thousand users starts as a monolith. As it grows, if the 'feed' feature requires significantly more resources than 'uploads', it might be split into a separate microservice for independent scaling.
- Vertical scaling: increasing the resources (CPU, RAM) of a single server; simple but has limits and high costs.
- Horizontal scaling: adding more servers to distribute the load; offers unlimited scalability and fault tolerance.
- The request lifecycle involves DNS lookup, HTTPS request to a server (often via a load balancer), server processing, and response.
- Latency (round-trip time) and bandwidth (data throughput) are key performance metrics.
Understanding scaling strategies and the request path is crucial for building applications that can handle growth and perform efficiently.
Instead of buying a bigger, more expensive server (vertical scaling), adding more smaller servers (horizontal scaling) is preferred for large-scale applications like a photo app serving millions.
- Load balancers distribute incoming traffic across multiple servers, acting as a reverse proxy.
- They perform health checks to ensure traffic is only sent to active, responsive servers.
- Stateful servers store session data locally, causing issues when requests are routed to different servers.
- Stateless servers do not store client-specific state, making them disposable and easier to scale horizontally; state is managed externally (e.g., in a shared store).
Stateless servers are fundamental for horizontal scaling, allowing any server to handle any request, which is essential for high availability and scalability.
If a user logs in on Server A, but their next request goes to Server B, Server B won't recognize them if the session is stateful. Moving sessions to a shared store (like Redis) makes servers stateless and solves this logout issue.
- Data modeling involves defining what data to store and how it relates, starting with user access patterns.
- SQL databases are ideal for structured, relational data with clear schemas and transactions (ACID properties).
- NoSQL databases are suited for unstructured or semi-structured data, offering flexibility and horizontal scalability.
- Real-world systems often use a polyglot persistence approach, employing both SQL and NoSQL databases for different data types.
The choice of database and how data is modeled directly impacts query performance, scalability, and the ability to retrieve information efficiently.
For a photo app, SQL (like PostgreSQL) is used for structured data like photos, users, likes, and follows due to their relationships. NoSQL (like MongoDB) might be used for less structured user preferences or behavior logs.
- Indexing speeds up database queries by creating lookup structures for specific columns (e.g., 'posted_by', 'upload_time').
- Indexes improve read performance but add overhead to write operations.
- Caching stores frequently accessed data in a fast, in-memory store (like Redis) to reduce database load and latency.
- Cache consistency is managed using Time-To-Live (TTL) or active invalidation to prevent serving stale data.
Indexing and caching are critical techniques for optimizing database performance and ensuring fast response times for users as the application scales.
To quickly find all photos by a specific user, an index on the 'posted_by' column is created. To serve popular photos instantly, a cache (Redis) stores them, so requests don't always hit the main database.
Key takeaways
- System design is about solving problems by choosing and arranging components, often driven by scaling needs and failure scenarios.
- Understanding non-functional requirements (speed, reliability, cost) is as important as functional requirements for designing robust systems.
- Stateless servers are key to horizontal scaling, enabling applications to handle massive traffic by making servers easily replaceable.
- The choice between SQL and NoSQL databases depends heavily on the data's structure and access patterns.
- Indexing and caching are essential techniques to optimize database performance and reduce latency.
- Every design decision involves trade-offs, and the goal is to meet requirements cost-effectively.
- System design is an iterative process of identifying problems, applying solutions, and managing the new challenges that arise.
Key terms
System DesignLoad BalancerCacheReplicationShardingHigh-Level Design (HLD)Low-Level Design (LLD)Functional RequirementsNon-Functional RequirementsMonolith ArchitectureMicroservices ArchitectureVertical ScalingHorizontal ScalingLatencyBandwidthDNSHTTPSReverse ProxyStateful ServerStateless ServerData ModelingAccess PatternsSQL DatabaseNoSQL DatabaseACID TransactionsIndexingCache HitCache MissTTL (Time To Live)Cache InvalidationCache Stampede
Test your understanding
- What is the primary difference between functional and non-functional requirements, and why are both critical in system design?
- How does a load balancer contribute to the scalability and availability of an application?
- Explain why stateless servers are preferred over stateful servers for horizontal scaling, and what mechanisms are used to manage state externally?
- When would you choose a SQL database over a NoSQL database for storing application data, and vice-versa?
- What is the purpose of indexing in a database, and what are the trade-offs of adding too many indexes?