I've started learning system design three times. The first two attempts followed the same arc: I'd watch a "design Twitter" video, nod along at the load balancer and the cache and the message queue, feel like I got it, and then a month later stare at a blank whiteboard with no idea where to start.

The problem wasn't the videos. Most of them are good. The problem was that I was watching finished designs and treating that as learning. It's a bit like reading solved chess games and expecting to play well.

Here's what I do differently now, after the third attempt finally stuck.

Learn the parts before the products

Every "design X" walkthrough is made from the same dozen or so pieces. If you don't know the pieces well, each new design feels like new material. If you do, you start seeing the same patterns rearranged.

The pieces I'd learn first, in roughly this order:

  • Clients, servers and what an HTTP request actually goes through
  • Load balancers
  • Caching (where it sits, what goes stale, what happens on a miss)
  • SQL vs NoSQL databases, and indexes
  • Replication and sharding
  • Message queues and async work
  • CDNs
  • Rate limiting
  • Consistency trade-offs (the CAP theorem is fine as a starting point, just don't stop there)

For each one, you should be able to answer three questions without notes: what problem does it solve, what does it cost you, and when would you skip it. That third question is where most of the understanding lives. Anyone can say "add a cache." Knowing when a cache makes things worse is what an interviewer, or a teammate reviewing your design doc, is listening for.

Draw it yourself before you watch the answer

This one change did more than anything else. Before I watch a walkthrough of, say, a URL shortener, I pause and sketch my own design for ten minutes. Boxes and arrows on paper. It's usually wrong in places, and that's the point.

Then when I watch the video, I'm comparing instead of absorbing. "Oh, they put the cache in front of the database read path, I had it somewhere weird." Those small corrections stick far better than a design I passively followed from start to finish.

If ten minutes feels like too much, do five. Even a rough attempt gives your brain something to hang the answer on.

Keep one running document of trade-offs

System design is mostly trade-offs, and the same ones keep coming back: latency vs consistency, simplicity vs scale, cost vs redundancy. I keep a single doc where every time I learn a trade-off, I write one or two sentences in my own words with an example.

Something like: "Write-through cache keeps the cache fresh but every write gets slower. Fine for a profile page, annoying for a high-write counter."

After a few weeks that doc is more useful than any course I've taken, because it's in my words and it's short.

The part everyone skips: coming back to it

This is where my first two attempts died. I'd spend a weekend on databases and sharding, feel great, move on to queues, and by the time I got to rate limiting I'd forgotten how consistent hashing worked.

The fix is boring. Revisit each building block a few times, spaced out: the next day, a few days later, a week later, a few weeks later. Each time, close your notes and try to explain it out loud or sketch it. If you can't, reread just that section. That's spaced repetition, and it suits system design well because the core set of ideas is small and you need to recall them quickly under pressure.

Recl's recall schedule spacing reviews over days

This is a big part of why I build Recl. Almost everything I learned about system design came from YouTube walkthroughs and engineering blog posts, and I'd save them and never look at them again. Now I share the video or article to Recl from my phone, or save it with the Chrome extension. It writes a summary with the key takeaways, files it under a topic like "System design," and later sends me a recall question so the idea comes back before it fades.

Key takeaways from a saved video in Recl

You don't need an app for this. Calendar reminders and a stack of index cards work too. What matters is seeing the material again, a few times, spread out.

Practice out loud, with a timer

Interviews and real design reviews both involve talking while thinking, which is a separate skill from knowing the material. Once you're comfortable with the building blocks, pick a prompt (a chat app, a news feed, a file upload service), set a 35-minute timer and talk through it to an empty room or a friend.

A loose structure helps so you don't freeze:

  1. Ask about requirements and rough scale.
  2. Sketch the simplest thing that works.
  3. Find the bottleneck.
  4. Fix that bottleneck and say what it costs.
  5. Repeat steps 3 and 4 until time's up.

You'll notice you keep reaching for the same handful of parts. That's good. It means the building blocks are becoming tools you actually use.

Read real postmortems

Walkthroughs show designs that work. Postmortems show what breaks. Public incident write-ups from companies like Cloudflare, GitHub and AWS are some of the best system design material there is, because they explain a real architecture and exactly where it failed. Pick one a week. Save it, read it, and write down the one trade-off that bit them.

A quick self-check

Without looking anything up, try answering these:

  • Why might you put a queue between your API and a slow email-sending service?
  • What goes wrong if two servers each cache the same user record and one of them updates it?
  • When would you choose to shard a database instead of adding read replicas?

If you can answer all three in a sentence or two, you know more system design than you think. If one of them stumped you, that's your topic for tomorrow. Then again in three days.

I build Recl, an AI learning app that saves the videos, reels and articles you learn from, summarizes them, sorts them into topics, and uses spaced repetition so you actually remember them.