Goal: “The best way to learn system design is to design systems.” — This week we finish HLD. We’ll cover the remaining advanced patterns, then jump straight into real interview questions. By Friday, we’ll have designed URL shorteners, chat systems, and social media feeds. System design goes from theory to practice this week.
Topics
| Day | Track | Focus | Topics |
|---|---|---|---|
| Mon | A — DSA Practice | Mixed Medium Problems | Solve 2-3 problems. Pick your weakest patterns and drill them — if sliding window trips you up, do 3 sliding window problems. No comfort zone. |
| Tue | B — HLD | Advanced Patterns | gRPC and Protocol Buffers · Polling, Long Polling, and SSE · Rate Limiting · Advanced Caching Patterns · Search and Indexing |
| Wed | A — DSA Practice | More Weak Spots | Solve 2-3 problems. Continue drilling weak areas — if DP is shaky, do 3 DP problems. Rotate through whatever needs work. |
| Thu | B — HLD | Design Questions I | Event Sourcing and CQRS · Distributed Consensus · Design URL Shortener · Design Rate Limiter · Design Chat System |
| Fri | B — HLD | Design Questions II | Design Social Media Feed · Design Video Streaming · Design Ride Sharing · Design File Storage · Design E-Commerce |
Note: The design questions on Thursday and Friday are practice problems. Before reading each note, try to design the system yourself in 45 minutes — grab a whiteboard, a piece of paper, or just a blank doc. Start with requirements, do a quick estimation, sketch the architecture, then read the notes to see what we missed. That’s where the real learning happens.
And with that — HLD is complete! We’ve gone from “what is system design?” all the way to designing real-world systems. Everything from here builds on this foundation.
Key Concepts
- Rate limiting protects our systems from being overwhelmed. The two main algorithms: token bucket (allows bursts, used by AWS and Stripe) and sliding window (smoother rate control). Know both — interviewers love asking “design a rate limiter” as a full system design question.
- Distributed consensus (Raft, Paxos) is how multiple nodes agree on a value. We don’t need to implement these — just know at a high level that leader election, log replication, and safety guarantees are the core pieces. Raft is easier to understand than Paxos, so start there.
- For every design question, follow our framework: requirements gathering → back-of-the-envelope estimation → API design → data model → high-level architecture → deep dives into interesting components. This structure keeps us from rambling.
- URL shortener is the classic starter question — it tests hashing, database design, caching, and read-heavy optimization. Chat system is about real-time communication + message queuing + delivery guarantees. Feed design is all about fan-out-on-write vs fan-out-on-read (the classic trade-off).
- Event sourcing stores every change as an immutable event instead of just the current state. CQRS separates read and write models. Together, they’re powerful for audit trails, temporal queries, and high-throughput systems — but they add complexity we need to justify.
Practice
- DSA: Solve 5-6 mixed problems this week — specifically target the patterns where we’re weakest
- HLD: Time yourself — design a URL shortener in 45 minutes (requirements → estimation → API → data model → architecture → deep dive)
- HLD: Time yourself — design a chat system in 45 minutes using the same framework
- HLD: Compare your designs against the notes — what did we miss? What trade-offs did we not consider?
~15 topics + DSA practice · ~2 hrs/day · HLD complete! Now think in systems