System Design Masterclass (2026) | From FAANG Insiders

Decide functional and non-functional requirements for a newsfeed system, covering creating posts (text, image, video), follow/unfollow, reverse chronological newsfeed, like, comment, and user notifications.

Learn six non-functional requirements for the newsfeed system—availability, eventual consistency, latency, scalability, extensibility, and usability—with metrics like 99.999% uptime and 1 to 2 second load times.

Discover capacity estimation in system design by exploring daily and monthly active users, throughput, storage, memory, and network, with planned deep dives in each area.

This lecture explains why capacity estimation matters in system design, guiding you to size servers and databases by throughput and storage, manage costs, choose hardware, handle read and write workloads.

Master capacity estimation by using daily active users and monthly active users, with DAU at 500 million and MAU at 2 billion for a newsfeed system.

Estimate write throughput by analyzing create post, follow, and like/comment operations, focusing on create post as the heaviest; 50 million daily writes and 50 billion daily reads illustrate system capacity.

Calculate write throughput for following and activities using 500 million daily active users; find 71.4 million follow requests per day and 1.5 billion activities per day.

Estimate storage needs by post type—text, image, and video—using average sizes and share of posts to reach about 216 TB per day and roughly 750 PB over ten years.

Compute ten-year storage for follow activities and user activities such as likes and comments using 16 bytes per follow and 216 bytes per activity. Throughput guides the ten-year storage estimate.

Estimate memory as cache memory size and use caches to speed data access. Daily cache memory equals 1% of daily storage, roughly two tb per day.

Calculate ingress and egress in gb per second from 216 tb per day and 50 billion daily reads to estimate network capacity at about 2.5 gb/s.

Design and implement a rest api for creating a text post by using the post method to the v1/post endpoint, sending user id, text, and hashtags in the body.

Learn API design for creating image or video posts. Post to v1/post with user id, description, hashtags, and media URL; upload media to object storage first (S3) before saving data.

Design a rest api for liking and commenting on a post by sending post requests to v1/comments with user_id, post_id, and comment text, and to v1/likes with user_id and post_id.

Explore the rest api design for follow and unfollow actions. Use http post to the v1/follow endpoint with a body containing follower_id and followed_id to create a follow relationship.

Design a rest API to read a user's newsfeed using the get method and the v1/feed/{userId} endpoint, and note that get requests have no body.

Initiate a follow or unfollow via a POST to the API gateway v1 follow endpoint with the follow ID and the follower ID, then update the graph databases, and confirm.

Explore the high level design for creating a text post and the flow to read a news feed, from the API gateway to the Post Writer Service and posts DB.

Precompute newsfeeds to deliver instant access by enqueuing post events in the message queue. The Newsfeed Generator reads the new post, locates followers, updates feeds, and refreshes the cache.

Discover the high level design for image and video posts using pre-signed URLs to upload to object storage, then post creation updates feeds via a post writer and newsfeed generator.

Explore the high level design for reading the news feed, detailing the end-to-end flow from api gateway routing to the feed reader service, feeds cache, and cdn-assisted media delivery.

Describe the high level design for commenting on a post, detailing the flow from user submission to storage and confirmation with a message queue for notifications.

Explain the high level design for liking a post, from the like button through the api gateway and like service to the likes cache and notification via the message queue.

Assess NoSQL vs SQL choices based on data structure, scale, and queries; apply NoSQL for posts, feeds, comments, and likes, and use a graph database for follow relationships.

Explore data modeling for social platforms by building posts, feeds, comments, likes, and follow databases in a NoSQL design, with indexing on post id and user id to optimize queries.

Explore pre signed URLs for direct uploads to object storage, with temporary permissions and signatures that expire in ten minutes, enabling faster, secure media uploads without server mediation.

Learn how media processing converts uploaded images and videos into formats and resolutions stored in object storage, delivering mp4 for mobile and lower resolutions for slow connections.

Define functional requirements for YouTube's system by detailing viewers and content creators: viewers need streaming and device compatibility, while creators need video uploads with notifications.

Explores non-functional requirements for viewers (low latency, scalability, user experience, availability) and content creators (scalability, security, storage reliability) to ensure smooth, secure, and reliable streaming.

Calculate capacity by estimating DAU and MAU, using 100 million daily active users and 2.5 billion monthly active users to size the system.

Estimate throughput by analyzing write and read paths. Assume 0.4 million daily write requests from 100 million users and 1 billion daily read requests from 100 million active users.

Estimate storage requirements for video data by calculating 600 MB per video with 0.4 million daily uploads, yielding about 240 TB per day and 876 PB over ten years.

Estimate cache memory by allocating about 1% of total daily storage, yielding roughly 2.4 tb of cache memory per day to speed database access.

Compute capacity by estimating ingress and egress bandwidth from daily data and reads. Ingress is 2.7 gigabytes per second, while egress is 70 bits per second.

Design the api flow for uploading content with a resumable, two-step process: post metadata to v1/videos to obtain a session url, then upload chunks via put.

Design the streaming api by returning a manifest of chunk locations in response to a get request to v1/watch. Clients fetch chunks from a cdn using hls for adaptive streaming.

Explore high level design for uploading content, detailing two-step process where video metadata is submitted via api gateway, routed through a load balancer to content upload service, yielding session url.

The client uploads via a session url; the api gateway routes to the content upload service, which stores in object storage and queues a video id for processing.

The content processor workflow engine coordinates services—content checker, format converter, quality converter, and CDN uploader—to process videos through chunking, format and quality variants, via a message queue.

Learn the high level design of streaming content using HLS, including client requests, manifest metadata, and adaptive delivery of video chunks from a CDN based on network conditions.

Learn guidelines for database selection, weighing NoSQL against SQL for fast data access, low latency, scale, simple queries, and evolving or fixed structures, with NoSQL favored for high-scale video data.

Define the videos db schema with video id, technical metadata, general metadata, and content delivery metadata via cdn urls, then cover indexing and video metadata queries.

Explore how HLS encoding enables adaptive streaming by encoding video chunks to H264 or H265. Integrate encoding after chunking, then apply format and quality conversions before CDN upload.

Explore how a tiny URL service, or URL shortener, shortens long URLs by taking a long URL as input and returning a shortened, memorable link.

Discover why a tiny URL service matters for sharing by shortening long links, saving character space on social media. It also presents a clean, professional look in emails and documents.

Define the functional requirements of a tiny url service by outlining core capabilities: generate a short url from a long url, and retrieve the original long url.

Explore non-functional requirements for a tiny URL service, including high availability with 99.99999% uptime, low latency, and scalable capacity to serve millions.

estimate daily active users at 300 million and monthly active users at 1 billion for a tiny URL service to drive capacity planning, because everything starts with understanding the users.

Estimate throughput by calculating daily write and read requests: 150 million writes and 6 billion reads from 300 million daily active users.

Estimate storage needs for short url to long url mappings at 200 bytes per mapping, with 150 million requests, yielding 30 gb per day and 109.5 tb over ten years.

Estimate and optimize memory with a cache to speed data access, storing 30 GB daily and expanding the cache as data grows to keep the service fast and efficient.

Calculate network capacity by ingress and egress. Ingress is 0.35 MB per second (30 GB per day); egress is 13.8 MB per second (100 GB per day) from reads.

Design a short URL API that connects a client to a server via a post request to the v1/urls endpoint, sending the long URL in the request body.

Retrieve the long URL from a short URL via a rest api. The get method uses the short URL as the endpoint and returns the long URL for redirection.

Outline the end-to-end flow of short URL generation: a post to the back end routes through the API gateway to the generate service, stores mappings, and returns the short URL.

Explore the collision problem when different long urls map to the same short url like tinyurl/ABC, causing confusion, and discuss prevention strategies.

Explore high level design approach 1 for random string generation to prevent collisions in short URL systems, highlighting cross-server uniqueness challenges.

Explore how using MD5 for random string generation ties outputs to input, preventing server-based collisions but revealing that shortening to seven characters reintroduces collisions for long URLs.

Evaluate the check db for collisions approach: generate a random string, verify in the database, and retry until unique; this risks higher latency at scale and breaks low latency goals.

Use a unique numbering system to map each long URL to a distinct counter, preventing collisions without regeneration latency. Zookeeper coordinates distributed servers to allocate non-overlapping ranges, ensuring global uniqueness.

Coordinate between servers with the Zookeeper service to assign unique number ranges for URL generation, preventing collisions. Servers obtain distinct ranges such as 1–1000 and 1001–2000 to generate numbers sequentially.

Explore base 62 encoding that uses 0 to 9, uppercase letters A to Z, and lowercase letters a to z to create shorter URLs with billions of unique combinations.

Generate a short URL via API gateway and load balancer. Use short URL service to obtain unique counters from zookeeper, store mappings in database and cache, and return short URL.

Route the short url through the api gateway and load balancer to the get long url service, using a read-through cache that checks the cache, updates after a database fetch.

Apply database selection guidelines by weighing speed, scale, query pattern, and structure flexibility; for URL mappings, choose a NoSQL key-value store for fast, scalable lookups.

Model data as a key-value NoSQL store that maps short URLs to long URLs for fast lookups. Index the short URL to accelerate reads and optimize common queries.

Trace how a short URL request flows from API gateway to the get long URL service, using a read-through cache, and returns a 301 redirect to the long URL.

Explain rate limiter concepts using a roller coaster analogy to show how software tracks user requests and enforces limits, such as two requests per second.

Treat a rate limiter as a security guard that tracks each user's requests and blocks excess activity, such as posting limits to ensure fair use and performance.

Discover why a rate limiter matters in system design: prevent overload, ensure fair usage among users, and control costs while balancing performance and cost efficiency.

Explore the functional requirements of a rate limiter system, including quotas by IP, user, and device, with examples like 100 requests per minute and 50 per hour, notification when exceeded.

Identify non-functional requirements for a rate limiter, emphasizing seven-nines uptime, low latency, and cost effectiveness within a larger system to prevent ripple delays and cost growth.

Estimate capacity for the rate limiter by projecting 500 million daily users and 2 billion monthly active users, then derive throughput, storage, memory, and network bandwidth.

Estimate throughput by analyzing 500 million daily active users each making 100 API requests per day, totaling 50 billion requests daily, to guide scalable and efficient rate limiter design.

Assess storage and memory needs for rate limiter by modeling per user per API counter data; 500 million users across 50 types require 2.5 TB with caching for low latency.

Estimate network bandwidth by calculating daily data transfer from 50 billion requests at roughly 1 kilobyte per request, totaling 50 terabytes per day and about 61 megabytes per second.

Compare rate limiter placements: before the API servers vs on the API servers, weighing security, latency, load, single point of failure, and granular control to guide design decisions.

Describe the high level design flow of a rate limiter. A client sends a request; the rate limiter tracks counts and passes allowed requests to the API server, else 429.

Rate limiter checks the per-client request counter stored in a fast cache like Redis, increments it, and forwards the request to API servers if under the threshold, otherwise drops it.

Rate limiter checks limit from rules db via rules cache, while rule service updates rules in rose cache and updates the counter cache to decide allow or deny.

Explore how to implement rate limiting using five core algorithms: token bucket, leaky bucket, fixed window counter, sliding window lock, and sliding window counter.

Learn the token bucket algorithm for rate limiting, using a bucket capacity and a refill rate to grant requests and allow bursts.

Visualize a leaking bucket to understand the leaky bucket algorithm, where a queue with capacity six holds incoming requests, processing four per minute, with overflow rate-limited, unlike the token bucket.

Explore the sliding window lock algorithm, its lookback window, and capacity to rate limit requests precisely, unlike fixed windows, while noting memory trade-offs.

Explore how concurrent requests cause race conditions in a multi-instance rate limiter, showing read-update races on a shared counter and how locks prevent inconsistent increments (with Lua script options mentioned).

Define requirements for a real-time messaging app: one-on-one messaging with text, images, videos and attachments; message status indicators for sent, delivered and read; last seen and online status; group chats.

Master the non-functional requirements for a scalable chat system, targeting seven nines uptime, instant message latency, and end-to-end encryption to ensure security for millions of users.

Estimate system capacity by analyzing DAU and MAU, using 1 billion daily users in 24 hours and 2 billion monthly users to guide scalable design.

Estimate throughput by three writes and three reads per message as state changes from send to delivered to read yielding 0.34 million writes and reads per second.

Estimate storage capacity by splitting messages into text and media, applying 99% text and 1% media, to project 78 TB per day and 284 PB in ten years.

Estimate memory as cache memory to speed data access, caching 0.5% of daily storage (about 78 TB), roughly 0.39 TB per day, with size scaling as the system grows.

Estimate network bandwidth by equating ingress and egress from daily data; with 78 tb per day, reads and writes are equal, giving about 950 mb per second in and out.

Design a bidirectional messaging API using WebSocket to enable real-time server-to-client and client-to-server communication beyond http requests, illustrated with a WhatsApp-like scenario.

Design an application programming interface for message status updates over WebSocket so the WhatsApp server informs clients of send, delivered, and read stages, including type, message id, and status.

Design and implement online status and last seen APIs using WebSocket updates, server-stored timestamps, and fetch requests to reveal a user’s current and last active times.

Explore API design for group messages in WhatsApp, using WebSocket to broadcast to multiple recipients. Learn the JSON payload includes type, group id, sender id, content, and timestamp.

Map the WebSocket connection flow from http get to http 101 across API gateway and WebSocket handlers. Understand how backend mappings and a WebSocket Connections Manager route messages between clients.

Explore the high level design for one-to-one messaging using WebSocket handlers, a connection manager, and cache-based routing to deliver messages between Max and Emily, even if a recipient disconnects.

Implement a 1:1 messaging flow with offline resilience by storing messages in a database via message service and delivering them through WebSocket handlers with a connections cache when users reconnect.

Max sends a message to Emily through the 1:1 WebSocket flow; the message is stored in the messages database with sender, recipient, content, timestamp, and state, then delivered to Emily.

Learn how 1:1 messaging handles assets by uploading images, videos, or documents to an asset URL via the API gateway and asset service, then delivering via the CDN.

Explore how message status flows from sent to delivered to read in a 1-to-1 chat, detailing server-side handling with websockets, the messages db, and real-time sender notifications.

Design the online status feature around active app use. The app sends a ping every minute via WebSocket to update the last seen service and database.

Understand the high level design of group messaging, from sending a group message through a WebSocket pipeline to delivering to group members via message service, group service, and queues.

Evaluate sql versus nosql for a messaging app, considering structure, scale, and real-time needs, and select nosql for messages, groups, and last seen to ensure low latency and high throughput.

Explore data modeling for three NoSQL databases in a messaging app: messages, groups, and last seen. Review detailed schemas, fields, and indexed queries for messages, group membership, and user activity.

Understand how WhatsApp uses end to end encryption to protect messages from sender to recipient, using a lock and key analogy for encryption, decryption, and encrypted server storage.

Define functional requirements for a search system that supports keywords, hashtags, and usernames, returning newest first and enabling fuzzy search for typos to boost relevance and speed.

Identify non-functional requirements such as availability, low latency, and scalability, and explain how they shape performance and user experience in search systems. Emphasize redundancy and failover to handle real-world load.

Estimate capacity using daily and monthly active users to forecast resources, prevent downtime, and plan scalable infrastructure for a search system with 100 million daily and 400 million monthly users.

Estimate throughput to plan load and prevent bottlenecks by balancing read and write throughput. For search operations, 500 million searches equate to 5,700 per second, ensuring low latency and availability.

Estimate storage needs for a tweet-driven search system by calculating daily storage, about 20 gb per day and 73 tb over ten years, ensuring fast, reliable search.

Estimate memory needs by caching the top 5% of data, about 1 GB per day for popular tweets. Cache memory speeds searches and reduces database load as data grows.

Estimate network bandwidth by quantifying data in and out per second, with 231 MB per second ingress and 11.5 GB per second egress, guiding capacity planning for smooth operation.

Use the get method for search and call /v1/search with a query. Encode spaces as %20 so the server decodes the query and returns tweets with text, user, time.

Present a high level design for a search flow, from api gateway through a load balancer to the search service, exposing a suboptimal, full-database scan.

Show how indexing with the index db speeds searches by returning tweet IDs for keywords and intersecting lists, then retrieving tweets via API gateway, load balancer, and search service.

The system enables fuzzy search by validating requests at the api gateway, distributing load with a load balancer, and correcting typos with a query correction service to fetch correct results.

Explore the high level search design, from indexing and query correction to the ranking service that sorts tweets by relevance and newest to oldest.

Explore the final design for Twitter search, combining caching, indexing, and ranking to deliver fast, accurate results. See how API gateway, load balancer, read-through cache, and query correction drive speed.

Learn how NoSQL provides fast data access and horizontal scaling for evolving data, while SQL handles structured queries and complex analytics; choose based on data structure, key-value lookups, and growth.

Model data with a blueprint for scalable system by designing a tweets DB with tweet ID and text, indexed for fast retrieval, and an IndexedDB mapping keywords to tweet IDs.

Discover how the query correction service uses Levenshtein distance to select the closest intended word, turning typos like f e r y into ferry to improve search results.

Explore Elasticsearch as a supercharged search engine that handles massive data in real time, supports fuzzy search for typos, and ranks results by relevance.

Define functional requirements for an Airbnb app with owners and guests, covering add/update properties, view bookings, search by criteria, view details, and book properties.

Explore non-functional requirements for property owners and guests, emphasizing availability with 99.999% uptime, scalability for growth, and strong consistency with moderate latency to prevent booking conflicts.

Estimate system capacity by analyzing daily active users and monthly active users for Airbnb, using 10 million dau and 100 million mau, including guests and property owners.

Estimate throughput by calculating writes per day from owners updating listings and guests booking properties, using 1/7 and 1/30 on 10 million daily users to obtain about 0.35 million writes.

Estimate storage capacity by calculating daily and ten-year needs for property data and bookings, using per-listing sizes and request volumes to reach 14.61 GB and 52.15 TB in ten years.

Estimate cache memory capacity by storing 5% of daily data, about 0.73 GB per day, and design memory to scale as the system grows.

Estimate network capacity by analyzing ingress and egress data flows, with daily inflow of 14.61 GB and egress of 17.64 TB, about 204 MB per second.

Design a REST API to create a property listing for an owner using v1/properties, including owner_id, name, location, price, availability, and images, returning 201 created with id and created_at.

Design a rest api for property owners to view bookings. Use a get request to v1/owners/{ownerId}/bookings and return a list with booking and property details.

Design a rest api for search properties, enabling guests to fetch available rentals via a get request to the properties search endpoint using city and check-in/out dates, returning property details.

Explore how a REST API retrieves detailed property information when a guest selects a listing. Learn about the get method, the endpoint, and the data returned for a specific property.

Learn a three-step guest booking flow: create a booking session with post to v1/booking-sessions, process payment via a gateway like PayPal, then finalize the booking with a token to v1/bookings.

publish a property by posting to api gateway, upload images via pre signed urls to object storage and cdn, then add the property with image urls to properties db.

Explore a high level design flow for searching properties: from guest query through API gateway and search service to Elasticsearch, with pre-processed search data for fast, fuzzy, and range queries.

Understand the high level design flow for a guest viewing a property: API gateway to property service, fetches details from the properties DB, and loads images from the CDN.

Trace the guest booking flow from property page to payment via the payment gateway, then booking creation and event-driven updates to notifications, availability, and search indexing.

Explore high level design for viewing bookings, showing how a get request to an API gateway routes via a load balancer to the booking service and queries the bookings database.

Learn how to select sql versus nosql databases using guidelines on fast access, scale, fixed structure, complex queries, flexible schemas, and acid transactions, illustrated with properties db and bookings db.

Present data modeling for properties and bookings databases, detailing schemas, key fields, and sql indexing on property id and on guest and owner ids for fast queries.

Explore how concurrent bookings are handled in a high-traffic system like Airbnb, comparing pessimistic locking with optimistic locking to prevent duplicates while boosting throughput.

Discover how a notification system acts as a digital messenger by receiving triggers and delivering the right message at the right time through channels like email, SMS, or app alerts.

Discover why notification systems matter for timely alerts, engagement, and a better user experience, with real-time flight updates and notifications about messages, likes, or comments.

Explore functional requirements for a notification system, including sending across sms, email, and app channels, rate limiting, prioritization and validation, one-time passwords, and user preferences.

Explore non-functional requirements for a system, focusing on availability, latency, scalability, reliability, and flexibility, illustrated by a notification system handling OTPs and alerts across SMS, email, and apps.

Estimate daily active users and monthly active users to guide capacity planning, ensuring compute power, storage, and bandwidth scale with 50 million DAU and 400 million MAU during peak loads.

Estimate system capacity by analyzing throughput, recognizing write throughput at 578 requests per second and the absence of read requests in a notification delivery system.

Estimate storage capacity for notifications, user info, and user preferences from 50 million daily notifications (sms, email, push) with given sizes, projecting ten-year totals in tens of terabytes.

Estimate memory capacity by sizing the cache as 1% of daily storage, about 1.22 GB per day, and ensure the cache scales as the system grows.

Estimate network bandwidth by calculating ingress and egress from daily storage data. Assume 85% delivery, yielding 1.42 MB/s ingress and 1.21 MB/s egress.

Master api design for sending notifications via rest, using a post to v1/notifications with a request body containing user id, from, message, priority, and timestamp.

Design a high level, notification system by splitting into a notification handler and dedicated iOS and Android delivery services, with SMS and email channels, leveraging APNs, FCM, Twilio, and MailChimp.

Examine a notification system design that prioritizes and validates alerts, enforces rate limits to prevent spam, filters by user preferences, and delivers via in-app, SMS, or email.

Design a notification system with validation and prioritization microservices, using an api gateway and user data for verification, routing through a load balancer to apns, fcm, sms, or email.

Implement rate limiting to track notification frequency per target user, delaying or discarding excess promotions, then forward approved messages to Apns, FCM, Twilio, or MailChimp for device delivery.

Integrate the user preference service to tailor notifications by validating user data and aligning with preferences. Route through api gateway to prioritized and rate-limited delivery via apns, fcm, and Twilio.

Learn a decoupled notification design that uses separate sender services for email, SMS, and push, routed by validation, prioritization, and rate limiting through user preferences.

Reorder notification flow by placing the rate limiter before validation and user preferences, routing via the api gateway, validation service, user preference service, and prioritisation service to reduce wasted resources.

Explore high level design for decoupling notification flows with a message queue between the prioritization and notification sender services, preventing bottlenecks, enabling retries, and supporting fault tolerance during traffic spikes.

Learn five guidelines for choosing SQL or NoSQL databases, considering fast data access, scale, fixed versus flexible structures, and query complexity, with examples like users info and user preferences.

Explore the users info db schema with user id as primary key, fields like name, email, created at, and updated at, and how indexing speeds validation queries.

Design a distributed, centralized logging system that aggregates logs from all microservices into one place, enabling real-time search across millions of log lines and unified dashboards for observability.

Implement a unified log collection pipeline, enable efficient search and retrieval, support end to end request tracing, use distributed storage, provide centralized visualization, and enforce compliant log retention.

Define non-functional requirements for the logging system, achieving low latency with asynchronous ingestion and fast search. Ensure high scalability, 99.999% availability, and strict access controls to protect sensitive data.

Explore the high level design of a distributed logging system, tracing a client request through the API gateway to logs collected, processed, and stored safely using a correlation ID.

Collect logs from each microservice with a daemon set log agent like Filebeat or Fluentbit, running on every server to attach metadata and mask sensitive data before real-time forwarding.

Kafka acts as a distributed message queue that buffers logs, organizing them into topics and partitions with offsets to enable replay and decouple producers from consumers like Apache Flink.

Learn how Apache Flink processes logs from Kafka in real time by parsing, validating, enriching, filtering, aggregating, and routing to OpenSearch, Prometheus, and S3 for dashboards and alerts.

Elasticsearch enables search and visualization of enriched logs with an inverted index. Timescale DB stores time series metrics for monitoring, and Amazon S3 archives parquet files for long term storage.

Explore how logs and metrics flow from Flink to Elasticsearch, TimescaleDB, and S3, then visualize and query them with Kibana, Grafana, and Athena for real-time monitoring.

Discover protobuf and Avro serialization to turn JSON logs into compact binary data, using schema-driven encoding with gRPC, Kafka, and Flink for low latency and high throughput.

Transform real-time data with Apache Flink, reading from Kafka, enriching with derived fields, filtering fields, and applying tumbling, hopping, and sliding windows to compute latency and error rate.