Advanced System Design Interview, Volume II
The advanced successor to the world's best-selling System Design course, designed to help experienced engineers master complex distributed systems and secure L5/L6 roles.
Level:
Intermediate
Videos:
2
Study Time:
36h
Lessons:
224
Assessments:
420
Updated
Last week
4.8
(10,644 ratings)
31,932 learners
Created byArslan Ahmad
Ex FAANG Manager, Expert Behind Advanced System Design Interview, Volume IICourse Overview
Volume II is where system design stops being about naming components and starts being about defending decisions under pressure. It is built for engineers targeting Senior, Staff, and L5/L6 roles, where "it scales" is not an answer and the interviewer keeps pushing until something breaks. Volume 1 gave you the vocabulary. Volume II gives you the fluency. Instead of surface-level walkthroughs, you go deep into the real systems on which modern infrastructure is built: Dynamo, Cassandra, Kafka, BigTable, GFS, HDFS, and Chubby. You learn how they partition data, survive node failures, and maintain their consistency guarantees at massive scale, so you can reason from first principles rather than memorizing diagrams. Top-tier companies don't just want to see if you can draw boxes on a whiteboard; they want to see if you can anticipate failure and defend your decisions. This course mimics the rigor of a real-world design review, challenging you to solve open-ended problems like the Distributed Notification Service and the Flash Sale System. Whether you are aiming for a promotion or preparing for the toughest interview of your career, Volume 2 provides the deep, defensible strategies you need to stop guessing what the interviewer wants and start leading the conversation with authority. This is the advanced sequel to Grokking the System Design Interview, the most-taken system design course online.
Best value
Lifetime access to this course
One-time payment. Yours forever.
$123
Discussions
Certificate
Free updates
Want all 42+ courses?
Best value
Lifetime access to this course
One-time payment. Yours forever.
$123
Discussions
Certificate
Free updates
Want all 42+ courses?
What you'll learn in Advanced System Design Interview, Volume II
- Deep dives into the systems modern infrastructure runs on: Dynamo, Cassandra, Kafka, BigTable, GFS, HDFS, and Chubby, taken apart piece by piece.
- The 20 distributed systems patterns senior interviews assume you already know: consistent hashing, quorum, write-ahead log, leader and follower, Merkle trees, and more.
- How to reason about consistency at scale: CAP, PACELC, vector clocks, read repair, and hinted handoff, and when each trade-off actually matters.
- The internals interviewers probe at L5 and L6: data partitioning, gossip protocols, anti-entropy, compaction, and master election.
- How to architect for 99.999% availability: replication, failover, and fault tolerance that hold up when nodes start failing.
- The hardest open-ended design problems, walked through end-to-end: a distributed notification service, a flash-sale system, a payment platform, and a recommendation engine.
- How to defend your design like a Staff engineer: anticipate failure, justify every decision, and lead the conversation instead of guessing what the interviewer wants.
- Guided mock interviews on every major system, so you practice explaining your trade-offs out loud before the real thing.
Course Content
2.
Designing YouTube Likes Counter
11 lessons
YouTube Likes Counter: System Definition
Define the YouTube likes counter: what the system has to do, which reactions it tracks, and the scope that the rest of the design works within.
YouTube Likes Counter: Requirements
Set the functional and non-functional requirements for a likes counter, and see which of them will shape the design that follows the most.
YouTube Likes Counter: Capacity Estimation
Estimate the traffic and storage for a likes counter, and find the numbers that decide the design before any component has been chosen.
YouTube Likes Counter: API Design
Design the API for a likes counter: the endpoints clients call, what each one takes and returns, and why the shape of it matters.
YouTube Likes Counter: High-Level Design
Walk the high-level design of a likes counter, the parts it is built from, and how the write path and the read path move through them.
YouTube Likes Counter: Database Schema
Design the schema for a likes counter, with one row per user reaction and a separate totals table, and see what that costs each read and write.
YouTube Likes Counter: Detailed Component Design
Compare synchronous counting, asynchronous counting with Kafka, and a hybrid of the two, and see which approach this design picks and why.
YouTube Likes Counter: Toggles and Idempotency
Understand why a like is a state change and not an increment, how the read-then-write race appears, and how an idempotency key closes it.
YouTube Likes Counter: Scalability and Performance
Scale a likes counter: shard the two stores, handle the hot key in the cache, serve 250,000 reads per second, and limit vote manipulation.
YouTube Likes Counter: Failure Modes and Operations
Walk the five real failures of a likes counter, from a lagging consumer to a lost region, what the design does about each, and what to watch.
Quiz
Test your understanding of the likes counter design: requirements and estimation, the counting approaches, idempotency, sharding, and failures.
3.
Designing Unique ID Generator
9 lessons
Unique ID Generator: System Definition
Define the unique ID generator: what the service must guarantee about uniqueness and ordering, and the scope the rest of the design works within.
Unique ID Generator: Requirements
Set the functional and non-functional requirements for an ID generator, and see which of those guarantees drives every later decision.
Unique ID Generator: Capacity Estimation
Estimate how many IDs the service must produce and how little each one costs, and see why the call itself is the real expense to design around.
Unique ID Generator: API Design
Design the API for an ID generator, in a shape that decides how often clients have to call the service at all, and what each call returns.
Unique ID Generator: High-Level Design
Decide between a library and a service for ID generation, then walk the high-level design of the service that sits behind one endpoint.
Unique ID Generator: ID Generation Strategies
Compare the ID generation approaches, design Snowflake IDs and opaque UUIDs, and handle state management and failure recovery for each.
Unique ID Generator: Scalability and Performance
Scale an ID generator by adding nodes, understand why that is almost all it takes, and learn the three numbers that cap how far it goes.
Unique ID Generator: Failure Modes and Operations
Walk the failures of an ID generator: a clock moving backwards, a node restart, an unreachable coordinator, and a reused machine number.
Quiz
Test your understanding of the ID generator design: uniqueness and ordering, Snowflake IDs and UUIDs, clock skew, and machine numbers.
4.
Designing Notification Service
10 lessons
Notification System: System Definition
Define the notification service: the kinds of message it sends, the channels it sends them over, and the scope the rest of the design sits within.
Notification System: Requirements
Set the functional and non-functional requirements for a notification service, including channels, user preferences, and delivery guarantees.
Notification System: Capacity Estimation
Estimate the daily notification volume and the fan-out of a single publish, and find the numbers the rest of the design has to carry.
Notification System: API Design
Design the API for a notification service, including the endpoint that accepts work and answers before anything has actually been delivered.
Notification System: High-Level Design
Walk the high-level design of a notification service, and see why creating a notification is kept separate from delivering it.
Notification System: Data Storage and Schema
Design storage for a notification service, splitting the small slow-changing records in SQL from the huge notification history in NoSQL.
Notification System: Detailed Component Design
Go inside the scheduler, the queue, and the workers of a notification service, plus retries, rate limits, templates, and security.
Notification System: Scalability and Performance
Scale a notification service to 150 million notifications a day, and handle the fan-out event where one publish turns into very many.
Notification System: Failure Modes and Operations
Walk the failures of a notification service: a throttling provider, a backed-up queue, a crashed worker, an unreachable recipient, and what to watch.
Quiz
Test your understanding of the notification service design: channels and preferences, queues and workers, fan-out, retries, and failure modes.
5.
Designing Reddit
8 lessons
Design Reddit: System Definition
Define the Reddit-style platform: posts, comments, votes, feeds, and messages, and the scope that the rest of the design works within.
Design Reddit: Requirements
Set the functional and non-functional requirements for a Reddit-style platform, and see which of them shape the design that follows.
Design Reddit: Capacity Estimation
Estimate the workload and the stored data for a Reddit-style platform, and find the numbers that decide how its components must be built.
Design Reddit: API Design
Design the seven core APIs of a Reddit-style platform, from the home feed and posts to votes, messages, notifications, and search.
Design Reddit: High-Level Design
Walk the high-level design of a Reddit-style platform as a set of single-purpose services, and follow the submission and the read flows.
Design Reddit: Detailed Component Design
Design the data model, voting and scores, feed generation and ranking, messaging, notifications, and search for a Reddit-style platform.
Design Reddit: Scalability and Performance
Scale a Reddit-style platform with stateless services, sharding and replication, caching, asynchronous processing, and traffic management.
Quiz
Test your understanding of the Reddit design: the data model, voting and ranking, feed generation, messaging, search, and sharding.
6.
Design Google Calendar
9 lessons
Google Calendar: System Definition
Define the calendar system: events, invitations, recurrence, and shared calendars, and the scope that the rest of the design works within.
Google Calendar: Requirements
Set the functional and non-functional requirements for a calendar system, from invitations and recurrence to availability and reminders.
Google Calendar: Capacity Estimation
Estimate the users, events, and queries a calendar system has to carry, and find the numbers the rest of the design must respect.
Google Calendar: API Design
Design the APIs of a calendar system, for creating and changing events, responding to invitations, and reading a user's schedule.
Google Calendar: High-Level Design
Walk the high-level architecture of a calendar system, and see how its services divide the work of events, invitations, and reminders.
Google Calendar: Database Schema
Design the schema for a calendar system: users, calendars, events, recurrence rules, exceptions, invitations, rooms, and access control.
Google Calendar: Detailed Component Design
Design the event lifecycle, availability and meeting room suggestions, reminder delivery, and time zone handling for a calendar system.
Google Calendar: Scalability and Performance
Scale a calendar system, covering how its reads and writes spread across machines and where its performance limits show up first.
Quiz
Test your understanding of the calendar design: recurrence and exceptions, invitations, availability lookups, reminders, and time zones.
7.
Designing Gmail
11 lessons
Gmail: System Definition
Define the email system: sending, receiving, storing, threading, and searching mail, and the scope that the rest of the design works within.
Gmail: Requirements
Set the functional and non-functional requirements for an email system, from delivery and search to durability, availability, and privacy.
Gmail: Capacity Estimation
Estimate the mail volume, the stored data, and the query load an email system must carry, and find the numbers that shape the design.
Gmail: RESTful APIs
Design the REST APIs of an email system, for sending mail, fetching an inbox, reading one message, and searching a whole mailbox.
Gmail: High-Level Design
Walk the high-level design of an email system, follow the data flow of one message, and weigh the trade-offs that this design makes.
Gmail: Database Design
Design the storage model behind an email system, and see what each choice costs when a user opens an inbox or searches a mailbox.
Gmail: Detailed Component Design
Design the caching layer, conversation threading, security and privacy measures, and the indexing strategies that make search fast.
Gmail: Scalability and Performance
Scale an email system, covering how storage and search spread across machines and which parts reach their limit first under load.
Gmail: Reliability and Availability
Make an email system reliable: what must never be lost, how replication and failover work, and what users see while a part is down.
Gmail: Evolution and Future Optimizations
See how an email system evolves after launch, which extensions fit it naturally, and where later optimization work pays off the most.
Quiz
Test your understanding of the email design: the storage model, conversation threading, search indexes, caching, reliability, and scaling.
8.
Designing Google News
8 lessons
Google News: System Definition and Goals
Define the news aggregator: the entities and concepts it works with, the goals it has to meet, and the scope of the design that follows.
Google News: Requirements
Set the functional and non-functional requirements for a news aggregator, from ingestion and ranking to freshness and availability.
Google News: Capacity Estimation
Estimate the article volume, the reader traffic, and the storage a news aggregator must carry, and find the numbers that shape the design.
Google News: High-Level Architecture
Walk the high-level architecture of a news aggregator, and see how ingestion, ranking, and serving are divided between its services.
Google News: Data Model and Storage
Design the data model and storage for a news aggregator, and see what each choice costs when a reader opens a personalized feed.
Google News: Detailed Component Design
Design the ingestion and deduplication pipeline, the pull and push feed engine, real-time updates, and the client-facing APIs.
Google News: Scalability and Performance
Scale a news aggregator, covering how ingestion and feed serving spread across machines and which part limits throughput first.
Quiz
Test your understanding of the news aggregator design: ingestion and deduplication, ranking, pull and push feeds, and real-time updates.
9.
Design a Recommendation System
8 lessons
Netflix Recommendations: System Definition
Define the recommendation system: what it recommends, to whom, and when, and the scope that the rest of the design works within.
Netflix Recommendations: Requirements
Set the functional and non-functional requirements for a recommendation system, from personalization and freshness to latency limits.
Netflix Recommendations: Capacity Estimation
Estimate the users, events, and recommendation requests the system must carry, and find the numbers that decide how it is built.
Netflix Recommendations: API Design
Design the APIs of a recommendation system, both for fetching a user's recommendations and for recording the events that later shape them.
Netflix Recommendations: High-Level Design
Walk the high-level design of a recommendation system, and see why heavy offline computation is kept apart from fast online serving.
Netflix Recommendations: Database Schema
Design the stores for precomputed recommendations, an item-to-item similarity index, trending content, and real-time user events.
Netflix Recommendations: Detailed Component Design
Design the recommendation computation workflow, real-time serving and updates, and the caching layers that keep responses fast.
Quiz
Test your understanding of the recommendation design: offline computation, real-time serving, similarity indexes, trending, and caching.
10.
Designing Code Judging System
7 lessons
Code Judging System: System Definition
Define the code judging system: what a submission is, what the verdict must mean, and the scope that the rest of the design works within.
Code Judging System: Requirements
Set the functional and non-functional requirements for a code judging system, from running untrusted code to fairness and latency.
Code Judging System: Capacity Estimation
Estimate the submission rate, the execution time, and the storage a code judging system must carry, and find the limiting numbers.
Code Judging System: High-Level Architecture
Walk the high-level architecture of a code judging system, from the submission path to the workers that run and grade the code.
Code Judging System: Data Storage and Indexing
Design storage and indexing for a code judging system, covering submissions, verdicts, test cases, and the queries each one serves.
Code Judging System: Detailed Component Design
Design the submission queue, the code execution engine, and the leaderboard, and weigh the trade-offs and alternatives for each.
Quiz
Test your understanding of the code judging design: the submission queue, sandboxed execution, test cases, verdicts, and the leaderboard.
11.
Designing Payment System
8 lessons
Payment System: System Definition
Define the payment system: what a payment is, which parties take part, and the scope that the rest of the design has to work within.
Payment System: Requirements
Set the functional and non-functional requirements for a payment system, from refunds and webhooks to correctness and availability.
Payment System: Capacity Estimation
Estimate the transaction rate and the stored records a payment system must carry, and find the numbers that shape the whole design.
Payment System: High-Level Design
Walk the high-level architecture of a payment system, and see how the work of taking, recording, and settling a payment is divided.
Payment System: Database Schema
Design the schema for a payment system: merchants, customers, payment methods, transactions, ledgers, refunds, webhooks, and event logs.
Payment System: Detailed Component Design
Design the payment service as an orchestrator, separate retryable from non-retryable errors, and handle the asynchronous workflow.
Payment System: Scalability and Performance
Scale a payment system without losing correctness, and see which parts of the path limit throughput as transaction volume grows.
Quiz
Test your understanding of the payment design: ledgers and transactions, retryable errors, refunds, webhooks, and asynchronous workflows.
12.
Designing Flash Sale System
7 lessons
Flash Sale: System Definition
Define the flash sale system: a million buyers competing for the same item at the same second, and the scope of the design that follows.
Flash Sale: Requirements
Set the functional and non-functional requirements for a flash sale, including fairness, no overselling, and surviving the opening spike.
Flash Sale: Capacity Estimation
Estimate the burst traffic a flash sale has to absorb and the data it stores, and find the numbers that decide every later choice.
Flash Sale: High-Level Architecture
Walk the high-level architecture of a flash sale system, including the caching layer that keeps the opening spike off the database.
Flash Sale: Database Schema
Design the schema for a flash sale: users, products, inventory, reservations, orders, and payments, plus indexing and partitioning.
Flash Sale: Detailed Component Design
Design the transaction states, the reservation expiry job, the queue and concurrency control, and the booking service of a flash sale.
Quiz
Test your understanding of the flash sale design: reservations and expiry, concurrency control, overselling, queues, and the opening spike.
13.
Designing Reminder Alert System
8 lessons
Reminder Alert System: System Definition
Define the reminder alert system: what a reminder is, when it must fire, and the scope that the rest of the design works within.
Reminder Alert System: Requirements
Set the functional and non-functional requirements for a reminder system, from recurring reminders to on-time, once-only delivery.
Reminder Alert System: Capacity Estimation
Estimate the stored reminders and the per-minute firing load a reminder system must carry, and find the numbers that shape the design.
Reminder Alert System: High-Level Design
Walk the high-level design of a reminder system, and see how storing a reminder is separated from firing and delivering it on time.
Reminder Alert System: Data Model and Storage
Design the data model and storage for a reminder system, so that finding every reminder due in the next minute stays cheap at any size.
Reminder Alert System: Detailed Component Design
Design the scheduling algorithm and execution pipeline, per-channel delivery, time zone and daylight saving handling, and failure handling.
Reminder Alert System: Scalability and Performance
Scale a reminder system, covering how the firing load spreads across workers and what happens when many reminders fall on one minute.
Quiz
Test your understanding of the reminder design: scheduling and firing, time zones and daylight saving, delivery channels, and failures.
14.
System Design Patterns
22 lessons
Introduction: System Design Patterns
Meet the twenty building blocks collected in this chapter, and learn to recognize each pattern the moment a design calls for it.
1. Bloom Filters
Understand how a Bloom filter answers set membership in very little memory, so a system can skip the files that cannot hold a record.
2. Consistent Hashing
Understand how consistent hashing keeps data movement small when a machine joins or leaves, and how virtual nodes even out the load.
3. Quorum
Understand how a quorum sets how many machines must agree before an operation counts as done, so two clients cannot read two answers.
4. Leader and Follower
Understand how this pattern names one server to resolve conflicting writes, and how its followers replicate the data from it.
5. Write-ahead Log
Understand how a write-ahead log records an intended change before making it, so a machine can tell what it was doing after a crash.
6. Segmented Log
Understand how splitting a growing log into smaller equal-sized parts keeps writes fast and makes the cleanup of old data simple.
7. High-Water Mark
Understand how the high-water mark marks the last safely replicated log entry, so followers never serve a write that could still be lost.
8. Lease
Understand how a lease works as a lock that expires on its own, so a resource is never blocked forever by a holder that never returns.
9. Heartbeat
Understand how a heartbeat is a small, regular signal that tells a distributed system which of its servers are still up and working.
10. Gossip Protocol
Understand how gossip spreads cluster state by having each node share with one random peer, so state reaches everyone without direct checks.
11. Phi Accrual Failure Detection
Understand how phi accrual failure detection replaces an up-or-down verdict with a suspicion level that rises as evidence of failure builds.
12. Split Brain
Understand how a leader-based system can end up with two active leaders, and how it decides which one is real and ignores the other.
13. Fencing
Understand how fencing stops a failed leader that is still running from touching cluster resources once a new leader has been elected.
14. Checksum
Understand how a checksum lets a client detect data corrupted by a bad disk, a network fault, or a bug, instead of accepting it silently.
15. Vector Clocks
Understand how vector clocks tell which replica produced which version of an object, and which of those versions truly conflict.
16. CAP Theorem
Understand which promise a distributed system has to break during a network partition, and when the CAP theorem forces that choice.
17. PACELC Theorem
Understand how PACELC extends CAP by also covering the normal case, when nothing has failed and latency becomes the real trade-off.
18. Hinted Handoff
Understand how hinted handoff keeps writes succeeding while one replica is offline, and how that replica is caught up afterwards.
19. Read Repair
Understand how read repair fixes a stale replica at the moment someone reads it, instead of waiting for a separate repair process.
20. Merkle Trees
Understand how a Merkle tree finds exactly where two large replicas differ, without moving most of the data between them over the network.
Quiz
Test your understanding of the twenty patterns, from Bloom filters and consistent hashing to quorums, leases, fencing, and Merkle trees.
15.
Dynamo: How to design a key value store?
12 lessons
Dynamo: Introduction
Understand what Dynamo is, the design goals behind it, the use cases it was built for, and the simple key-value APIs it exposes.
High-Level Architecture
Walk Dynamo's architecture: data distribution, replication and consistency, temporary failures, node communication, and high availability.
Data Partitioning
Understand how Dynamo distributes data with consistent hashing, and how virtual nodes spread the load and simplify adding a machine.
Replication
Understand optimistic replication in Dynamo, the preference list, the sloppy quorum that absorbs temporary failures, and hinted handoff.
Vector Clocks and Conflicting Data
Understand clock skew, how vector clocks track versions in Dynamo, and how CRDTs and last-write-wins settle conflicting data.
The Life of Dynamo’s put() & get() Operations
Follow a put and a get through Dynamo: choosing a coordinator node, the consistency protocol, and the state machine that handles a request.
Anti-entropy Through Merkle Trees
Understand how Dynamo uses Merkle trees to find differences between replicas cheaply, and the merits and demerits of that approach.
Gossip Protocol
Understand how Dynamo nodes learn about one another through the gossip protocol, and how seed nodes handle external discovery.
Dynamo Characteristics and Criticism
Understand what each Dynamo node is responsible for, the system's characteristics, the criticism of it, and the datastores built on it.
Summary: Dynamo
Review Dynamo in one place: the design decisions behind it, the system design patterns it uses, and where to read further about it.
Quiz: Dynamo
Test your understanding of Dynamo: consistent hashing, sloppy quorums, hinted handoff, vector clocks, Merkle trees, and gossip.
Rapid-Fire Interview Questions: Dynamo
Work through rapid-fire questions on Dynamo, to check that every part of its design is recallable under the pressure of an interview.
16.
Cassandra: How to Design a Wide-column NoSQL Database?
12 lessons
Cassandra: Introduction
Understand what Cassandra is, the background it came from, and the kinds of workload that suit a wide-column distributed database.
High-level Architecture
Walk Cassandra's architecture: its common terms, data partitioning, partition and clustering keys, the partitioner, and the coordinator.
Replication
Understand Cassandra's replication factor and its replication strategies, from simple replication to network topology awareness.
Cassandra Consistency Levels
Understand Cassandra's write and read consistency levels, where hinted handoff fits in, and what the snitch is there to do for reads.
Gossiper
Understand how Cassandra uses the gossip protocol to share cluster state, and how it decides that one of its nodes has failed.
Anatomy of Cassandra's Write Operation
Follow a Cassandra write through the commit log, the memtable, and the SSTable, and see why that path stays so fast under load.
Anatomy of Cassandra's Read Operation
Follow a Cassandra read through caches, the memtable, and SSTables, using Bloom filters, the index summary, and the key cache.
Compaction
Understand how compaction merges Cassandra's SSTables, the compaction strategies available, and why sequential writes matter here.
Tombstones
Understand what a tombstone is in Cassandra, why a delete is written rather than removed, and the problems tombstones go on to cause.
Summary: Cassandra
Review Cassandra in one place: its characteristics, the system design patterns it uses, and where to read further about its design.
Quiz: Cassandra
Test your understanding of Cassandra: partition and clustering keys, consistency levels, the write and read paths, and compaction.
Rapid-Fire Interview Questions: Cassandra
Work through rapid-fire questions on Cassandra, to check that every part of its design is recallable under interview pressure now.
17.
Kafka: How to Design a Distributed Messaging System?
13 lessons
Messaging Systems: Introduction
Understand what a messaging system is, and how the queue model differs from the publish-subscribe model that Kafka is built on.
Kafka: Introduction
Understand what Kafka is, the background it came from, and the use cases that suit a distributed, durable, replayable commit log.
High-level Architecture
Walk Kafka's architecture and its common terms: brokers, records, topics, producers, consumers, the cluster, and cluster coordination.
Kafka: Deep Dive
Understand Kafka's topic partitions, the leader and follower roles, in-sync replicas, and the high-water mark that bounds safe reads.
Consumer Groups
Understand what a Kafka consumer group is, and how the partitions of a topic are distributed between the consumers inside one group.
Kafka Workflow
Follow the Kafka workflow twice, once as plain publish-subscribe messaging and once through a consumer group that shares the partitions.
Cluster Coordination: KRaft and ZooKeeper
Understand what Kafka's coordination layer does, how KRaft handles it, what it improved on ZooKeeper, and how a client finds a leader.
Controller Broker
Understand what the Kafka controller broker does, how split brain can appear, and how a generation clock settles which one is current.
Kafka Delivery Semantics
Understand Kafka's delivery semantics on both sides, for producers writing records and for consumers committing their offsets.
Kafka Characteristics
Understand how Kafka stores messages on disk, how long it retains records, how client quotas work, and where its performance comes from.
Summary: Kafka
Review Kafka in one place, with the patterns it is built from: the high-water mark, leader and follower, split brain, and the segmented log.
Quiz: Kafka
Test your understanding of Kafka: partitions and replicas, the high-water mark, consumer groups, coordination, and delivery semantics.
Rapid-Fire Interview Questions: Kafka
Work through rapid-fire questions on Kafka, to check that every part of its design is recallable under the pressure of an interview.
18.
Chubby: How to Design a Distributed Locking Service?
14 lessons
Chubby: Introduction
Understand what Chubby is and what it is used for, from leader election and naming to small-object storage and distributed locking.
High-level Architecture
Walk Chubby's architecture: the Chubby cell and its servers, the client library, and the general, file, locking, and sequencer APIs.
Design Rationale
Understand why Chubby is a service with coarse-grained advisory locks and a file-like interface, and where it sits on the CAP trade-off.
How Chubby Works
Follow service and client initialization in Chubby, then work through a leader election example with the pseudocode behind it.
File, Directories, and Handles
Understand Chubby's file and directory nodes, the metadata each one carries, and the handles through which clients read and change them.
Locks, Sequencers, and Lock-delays
Understand Chubby's locks, how a sequencer proves a lock is still held, and how a lock-delay protects a resource after a client fails.
Sessions and Events
Understand the Chubby session and its protocol, what KeepAlive does, how sessions are optimized, and what happens during a failover.
Master Election and Chubby Events
Understand how a newly elected Chubby master initializes itself, and the events Chubby sends to its clients when things change.
Caching
Understand how the Chubby client cache keeps reads cheap, and how the master invalidates that cache so clients never read stale data.
Database
Understand how Chubby keeps its own database safe, through regular backups and through mirroring to other cells for wider availability.
Scaling Chubby
Understand how Chubby scales to many clients, through proxies and partitioning, and what its designers learned from doing so.
Summary: Chubby
Review Chubby in one place: the design decisions behind it, the system design patterns it uses, and where to read further about it.
Quiz: Chubby
Test your understanding of Chubby: cells and servers, advisory locks and sequencers, sessions and KeepAlive, caching, and scaling.
Rapid-Fire Interview Questions: Chubby
Work through rapid-fire questions on Chubby, to check that every part of its design is recallable under the pressure of an interview.
19.
HDFS: How to Design File Storage System?
12 lessons
Hadoop Distributed File System: Introduction
Understand what HDFS is, the background it came from, and the APIs it offers for storing very large files across many machines.
High-level Architecture
Walk the HDFS architecture, with its NameNode and DataNodes, and compare the design against the Google File System it came from.
Deep Dive
Understand the HDFS cluster topology, rack aware replication, its synchronization semantics, and the consistency model it offers.
Anatomy of a Read Operation
Follow an HDFS read from the NameNode lookup to the DataNode transfer, and see what a short circuit read saves a local client.
Anatomy of a Write Operation
Follow an HDFS write, from the NameNode allocating each block to the pipeline of DataNodes that store it and acknowledge it in turn.
Data Integrity & Caching
Understand how HDFS protects data integrity with checksums and the block scanner, and how its caching keeps hot blocks fast to read.
Fault Tolerance
Understand how HDFS survives a DataNode failure through replication and heartbeats, and what happens when the NameNode itself fails.
HDFS High Availability (HA)
Understand the HDFS high availability design, with the quorum journal manager, ZooKeeper, and the fencing that makes failover safe.
HDFS Characteristics
Understand HDFS security and permissions, federation for scaling its namespace, erasure coding, and how it is used in practice.
Summary: HDFS
Review HDFS in one place: the design decisions behind it, the system design patterns it uses, and where to read further about it.
Quiz: HDFS
Test your understanding of HDFS: the NameNode and DataNodes, rack aware replication, the read and write paths, and high availability.
Rapid-Fire Interview Questions: HDFS
Work through rapid-fire questions on HDFS, to check that every part of its design is recallable under the pressure of an interview.
20.
GFS: How to Design a Distributed File System Storage?
15 lessons
Google File System: Introduction
Understand what the Google File System is, the background it came from, the workloads it was built for, and the APIs it exposes.
High-level Architecture
Walk the GFS architecture and its parts: chunks and chunk handles, the cluster, its chunkservers, the master, and the client.
Single Master and Large Chunk Size
Understand why GFS uses a single master and a very large chunk size, and how lazy space allocation keeps that choice affordable.
Metadata
Understand how the GFS master keeps metadata in memory, how it learns chunk locations, and how the operation log and checkpoints protect it.
Master Operations
Understand the GFS master's work: namespace locking, replica placement, re-replication, rebalancing, and stale replica detection.
Anatomy of a Read Operation
Follow a GFS read, from the client asking the master where a chunk lives to reading the data straight from a nearby chunkserver.
Anatomy of a Write Operation
Follow a GFS write, and understand how a chunk lease lets one replica order the writes that every other replica then applies.
Anatomy of an Append Operation
Follow a GFS record append, and see why appending, not overwriting, is the operation this whole file system was optimized for.
GFS Consistency Model and Snapshotting
Understand what the GFS consistency model actually promises after a write or an append, and how snapshotting is done cheaply.
Fault Tolerance, High Availability, and Data Integrity
Understand how GFS tolerates failures, how chunk replication keeps it available, and how checksums protect the integrity of the data.
Garbage Collection
Understand how GFS reclaims space through lazy deletion, and weigh the advantages of that approach against its disadvantages.
Criticism on GFS
Understand the problems that come with a single GFS master and with its very large chunk size, and what they cost in practice.
Summary: GFS
Review the Google File System in one place: its design, the system design patterns it uses, and where to read further about it.
Quiz: GFS
Test your understanding of GFS: chunks and the single master, leases and writes, record appends, the consistency model, and deletion.
Rapid-Fire Interview Questions: GFS
Work through rapid-fire questions on GFS, to check that every part of its design is recallable under the pressure of an interview.
21.
BigTable: How to Design a Wide Column Storage System?
15 lessons
BigTable: Introduction
Understand what BigTable is, the background it came from, and the kinds of workload that suit a wide-column storage system at scale.
BigTable Data Model
Understand the BigTable data model: rows and their keys, column families, the columns inside them, and the timestamps on each cell.
System APIs
Understand the BigTable APIs, both the metadata operations that manage tables and families and the data operations that read and write.
Partitioning and High-level Architecture
Understand how BigTable splits a table into tablets, and walk the high-level architecture that stores and serves those tablets.
SSTable
Understand how BigTable stores its tablets in GFS as SSTables, and keep the difference between a table, a tablet, and an SSTable clear.
GFS and Chubby
Understand what BigTable depends on the Google File System for, and what it depends on Chubby for, and why it needs both of them.
Bigtable Components
Understand the two kinds of server in BigTable: the master that assigns and monitors work, and the tablet servers that do it.
Working with Tablets
Understand how BigTable locates and assigns tablets, how it monitors its tablet servers, and how it balances load between them.
The Life of BigTable's Read & Write Operations
Follow a write and then a read through BigTable, and see which parts of its storage each one has to touch along the way, and why.
Fault Tolerance and Compaction
Understand how BigTable tolerates the failure of a tablet server or its master, what it inherits from GFS and Chubby, and how it compacts.
BigTable Refinements
Understand the refinements that make BigTable fast: locality groups, compression, caching, Bloom filters, and a unified commit log.
BigTable Characteristics
Understand BigTable's performance, how it compares with Dynamo, and which of the later datastores were built on its principles.
Summary: BigTable
Review BigTable in one place: the design decisions behind it, how its parts fit together, and where to read further about it.
Quiz: BigTable
Test your understanding of BigTable: the data model, tablets and SSTables, its use of GFS and Chubby, the read and write paths, and compaction.
Rapid-Fire Interview Questions: BigTable
Work through rapid-fire questions on BigTable, to check that every part of its design is recallable under the pressure of an interview.
22.
Final Assessment
2 lessons
Final Assessment I: The Twelve Case Studies
Test what you learned across the twelve case studies, from requirements and estimation to component design, scaling, and failure modes.
Final Assessment II: Patterns and the Deep Dives
Test what you learned from the system design patterns and from the architecture deep dives into real distributed systems and their trade-offs.
What people say about our courses
Roger Cruz
Software Engineer
The world gets better inch by inch when you help someone else. If you haven't tried Grokking The Coding Interview, check it out, it's a great resource!
Simon Barker
Software Engineer
This is what I love about http://designgurus.io’s Grokking the coding interview course. They teach patterns rather than solutions.
Ashley Pean
Software Engineer
Check out Grokking the Coding Interview. Instead of trying out random Algos, they break down the patterns you need to solve them. Helps immensely with retention!
Eric
Software Engineer
I've completed my first pass of "grokking the System Design Interview" and I can say this was an excellent use of money and time. I've grown as a developer and now know the secrets of how to build these really giant internet systems.
Steven Zhang
Software Engineer
Just wanted to say thanks for your Grokking the system design interview resource (https://lnkd.in/g4Wii9r7) - it helped me immensely when I was interviewing from Tableau (very little system design exp) and helped me land 18 FAANG+ jobs!
Arijeet
Software Engineer
Just completed the “Grokking the system design interview”. It's amazing and super informative. Have come across very few courses that are as good as this!
About the Author
Arslan Ahmad
Design Gurus Founder
Ex-FAANG Manager
Meta
Microsoft
Google
Amazon
Uber
Industry Expertise & Leadership
Arslan Ahmad is the lead author of Advanced System Design Interview, Volume II. As the founder of Design Gurus and a former FAANG hiring manager, he has worked at industry giants like Facebook (now Meta) and Microsoft.
He has conducted hundreds of system design interviews, giving him unique insight into what top tech companies look for in candidates.
The course also incorporates expertise from senior engineers at Google, Meta, Amazon, Microsoft, and Uber, ensuring you learn system design best practices from professionals who have built and scaled real-world systems.
500+
Interviews Conducted
10k+
Students Taught
Related Courses
Grokking the System Design Interview
The original system design interview course from DesignGurus. Master scalable systems, critical trade-offs, and 15+ real-world design problems with a repeatable interview framework.
4.7
191K learners
$148
System Design Interview Crash Course
Master modern system design in two weeks with 30+ real-world problems and a rigorous 14-step framework.
4.5
7K learners
$123
Grokking Scalable Systems for Interviews
Learn how FAANG engineers design systems that handle billions of users, from caching and sharding to observability and fault tolerance.
4.4
4.6K learners
$88
FAQs
What is Advanced System Design Interview, Volume II, and who is it for?
Advanced System Design Interview, Volume II is the next step after the original best-selling Grokking the System Design Interview. It is built for engineers preparing for Senior, Staff, and L5/L6 interviews, where you are expected to design complex distributed systems and defend every trade-off under pressure. If Volume 1 taught you the vocabulary of system design, Volume II is where you build real fluency. It is ideal for mid-level and senior engineers who can already sketch a basic design and now want the depth to handle the hardest open-ended problems at top tech companies.
How is Volume II different from the original Grokking the System Design Interview? Do I need Volume 1 first?
Volume 1 covers the foundations: the framework, the core building blocks, and classic design problems like a URL shortener or Instagram. Volume II goes deeper. It dissects the real distributed systems that modern infrastructure runs on and tackles harder, more ambiguous problems aimed at senior-level interviews. You do not strictly need Volume 1 first, but you should be comfortable with the basics before you start. Most learners take Volume 1 to build the vocabulary, then move to Volume II for the fluency that Staff and L5/L6 interviews demand.
What topics and systems does Volume II cover?
Volume II is a deep dive into the systems behind real infrastructure. You study Dynamo, Cassandra, Kafka, BigTable, GFS, HDFS, and Chubby, learning how each one partitions data, survives node failures, and holds its consistency guarantees at scale. You then apply that knowledge to hard, open-ended design problems, including a distributed notification service, a flash-sale system, a payment platform, and a recommendation engine. The course also includes a dedicated System Design Patterns section covering consistent hashing, quorums, write-ahead logs, Merkle trees, CAP, PACELC, and more.
Is Volume II worth it for Senior and Staff (L5/L6) interviews?
Yes. Senior and Staff interviews are not testing whether you can draw boxes on a whiteboard. They test whether you can architect for high availability, anticipate failure, and justify your decisions when the requirements get messy. Volume II is built specifically for that bar. With 142 lessons, 400 practice quizzes, and a guided mock interview on each major system, it gives you the depth and the repetition to walk in confident and lead the conversation rather than guess what the interviewer wants.
Who created Advanced System Design Interview, Volume II, and what are their credentials?
Advanced System Design Interview, Volume II was created by Arslan Ahmad and the team at Design Gurus, the same people behind the original Grokking the System Design Interview that has been taken by over 175,000 learners. Arslan is an ex-FAANG engineer and hiring manager who has built global-scale distributed systems at Microsoft and Meta and interviewed hundreds of candidates at both companies. That experience on both sides of the table shapes every lesson, so you learn not just how these systems work but what interviewers are actually looking for.
How long is Volume II, and how is it structured?
Volume II includes 142 lessons and roughly 36 hours of content, organized into deep-dive system breakdowns, hard design problems, and a System Design Patterns reference section. Nearly every module ends with a quiz, and the major systems include a walkthrough mock interview, for 400 quizzes in total. The format is self-paced, so you can move quickly through the topics you already know and slow down on the ones that matter most for your target role.
Recommended Blogs
One-Stop Portal For Tech Interviews.
Copyright © 2026 Design Gurus, LLC. All rights reserved.