$cat about.md

About This Site

The “Draw the Rest of the Owl” Problem

If you've ever searched for system design tutorials, you've probably encountered this pattern:

Step 1: Here's a cache. Here's a load balancer. Here's a message queue.
Step 2: Now go build Netflix.

This is the educational equivalent of the infamous “how to draw an owl” meme: draw two circles, then draw the rest of the owl. It leaves beginners staring at a blank page, wondering how anyone gets from circles to feathers.

The Gap in CS Education

Most computer science programs teach you algorithms, data structures, maybe some databases—but not how systems actually evolve in production. You learn what a B-tree is, but not when your database needs an index. You learn Big-O notation, but not why your cache hit rate matters more than your algorithm’s constant factors.

This knowledge traditionally comes from experience: you build something, it breaks under load, you fix it, you learn. But what if you haven’t had that experience yet? What if you’re preparing for interviews, or building your first real system, or just curious how the internet actually works?

A Different Approach

This site builds intuition from the ground up. Every journey starts small—a toy app for six friends, a script running on your laptop, a prototype built over winter break. Then reality intrudes:

  • Traffic spikes and your database melts
  • Users in Tokyo complain about 3-second load times
  • Your cloud bill arrives and you briefly consider a career change
  • A celebrity shares your link and 50,000 fans arrive simultaneously

Only then—when the pain is real and the problem is concrete—do we introduce the engineering solution. Caching isn’t an abstract concept; it’s the thing that saves your database from executing the same query 10,000 times per second. CDNs aren’t enterprise buzzwords; they’re how you stop making Tokyo users wait for bytes to cross the Pacific.

Learning Like Zuckerberg (Sort Of)

We’re trying to mimic the journey that every successful system actually took. Facebook wasn’t architected for a billion users on day one. It started as a PHP script in a Harvard dorm room. When it got slow, Zuck added caching. When one server wasn’t enough, he added more. When MySQL couldn’t keep up, the team sharded it. Each solution emerged from a specific, painful problem.

This is how you build intuition: not by memorizing architectural patterns, but by understanding why each pattern exists, when you need it, and what trade-offs it brings.

How This Site Works

Each journey is a progression through realistic scaling bottlenecks:

  1. Start small. A working prototype that solves a real problem for a small group.
  2. Hit a bottleneck. Traffic, latency, cost, reliability, or a new feature request breaks your current approach.
  3. Explore solutions. Compare different approaches with honest trade-offs—no “correct” answers, just contextual fitness.
  4. Implement and measure. See how metrics change. Understand what you gained and what you gave up.
  5. Repeat. The solution to stage 3 becomes the bottleneck of stage 4.

By the end, you haven’t just memorized that “Netflix uses microservices.” You understand the journey from monolith to services, the problems that forced each transition, and the trade-offs at every step.

What Makes This Different

Progressive complexity
Start with localhost, end with multi-region geo-distribution. Every step is motivated by a real problem.
Honest trade-offs
No solution is perfect. We show what you gain, what you lose, and when the trade-off makes sense.
Contextual learning
Caching isn’t “always good.” It’s good when reads outnumber writes and you can tolerate some staleness. Context matters.
No vendor lock-in
We teach concepts, not products. “Object storage,” not “S3.” “Message queue,” not “SQS.” Learn principles that transfer.

Who This Is For

  • New grads prepping for Big Tech interviews who need to understand systems beyond “draw some boxes and mention eventual consistency”
  • Self-taught developers who’ve built apps but haven’t hit scaling problems yet (and want to before production does)
  • Curious students who want to know how the internet actually works, not just how to traverse a binary tree
  • Bootcamp grads who learned React and Express but want to understand what happens when your app leaves localhost

This site isn’t a substitute for hands-on experience—nothing is. But it’s a map for the journey, drawn by people who’ve been lost in the same woods. We’re trying to be the resource we wish we’d had: no circles-to-owl leaps, just one honest step at a time.

$whoami

I’ve been fortunate enough to see systems scale from different vantage points: as an early engineer at a unicorn startup (where “move fast and break things” was less philosophy and more accurate incident report), at Meta (where breaking things affected a billion people and made the evening news), and currently at a quantitative hedge fund (where correctness matters more than speed, but the data volumes make “correct” a surprisingly hard problem).

Each job taught me the same lesson from a different angle: system design isn’t about memorizing architectural patterns. It’s about understanding why Instagram’s feed works differently than a financial data pipeline, why techniques that saved us at the startup would get you laughed out of a room at Meta, and why some “best practices” are just practices that happened to work in one specific context.

This site is an attempt to share that intuition—the kind you usually only get from building things, watching them fall over, and staying up until 3 AM figuring out why. Hopefully it helps you skip a few of those 3 AM sessions. Or at least makes them more productive.