System Design Mentor

Asked How should I shard a database that's outgrowing a single instance?

Answered

Order matters here, and most people jump straight to step five, which is exactly backwards. Here's the sequence the course teaches: 1.…

Order matters here, and most people jump straight to step five, which is exactly backwards. Here's the sequence the course teaches: 1. Check you've actually exhausted a single instance. Vertical scaling is boring but it works — managed Postgres runs to hundreds of thousands of IOPS. A lot of "we need to shard" conversations start before anyone's checked whether a bigger box solves it. 2. Fix your queries first. A missing index or an N+1 query has ended more sharding conversations than any architecture change ever has. This is the step people skip because it's less exciting than designing a distributed system. 3. Move reads to replicas if reads dominate your load. It's a configuration change, not a redesign, and it buys real headroom. 4. Split by table — move your busiest tables to their own instance. Simpler than sharding, and often that's enough on its own. 5. Only then partition by key. Pick a key that spreads writes evenly *and* keeps the queries you actually run on a single shard. Customer ID is usually the right choice; time-based keys concentrate all of today's writes on one shard, which defeats the purpose. 6. Plan resharding before you need it. Use consistent hashing or a lookup table of ranges. If you do hash of ID modulo N and then double your shard count, you'll end up moving almost everything — that's the mistake that turns a planned migration into a fire drill. The part that actually costs you isn't the split itself — it's everything downstream: cross-shard queries, transactions that used to be free and now aren't, and unique constraints that no longer hold globally once your data is spread across instances. Plan for those before you shard, not after. This is week five of the course if you want the full treatment with worked examples.

Asked How much experience do I need before this course is useful?

Answered

Two years minimum, realistically — that's the honest floor. Below that, the material is understandable but stays abstract, because you haven't yet lived through the problems it's trying to prevent.…

Two years minimum, realistically — that's the honest floor. Below that, the material is understandable but stays abstract, because you haven't yet lived through the problems it's trying to prevent. Sharding advice hits differently once you've watched a table melt down at 2am versus reading about it cold. The course is really aimed at engineers with two to eight years of experience — people who can build features competently but freeze when handed a blank page and asked to design a system from scratch. If that's you, this is squarely the target audience. If you're earlier than two years, I wouldn't say it's useless, just that a lot of it will feel like theory rather than "oh, that's the thing that happened to us last month." Happy to walk you through what's covered so you can judge for yourself whether it's the right time.

Asked Is this an interview-prep course?

Answered

Partly, but that's not its main focus. Week eight is explicitly about interviews and real design reviews — writing a design and defending it — and the eight exercises (URL shortener, rate limiter, feed, payments ledger, etc.)…

Partly, but that's not its main focus. Week eight is explicitly about interviews and real design reviews — writing a design and defending it — and the eight exercises (URL shortener, rate limiter, feed, payments ledger, etc.) are the same shape as questions you'd get in an interview. That said, the course is written for people who need to do this at work, day to day — not just pass a 45-minute interview loop. So the emphasis leans more toward operating systems over years: knowing when sharding is actually warranted, how caching invalidation bites you in production, why idempotency matters after you've had a real double-charge incident. Interview prep is a byproduct of getting good at the real thing, not the primary goal. If your main need really is interview prep specifically, this will still help — the exercises are structured exactly like interview prompts, and the graded feedback tells you whether your reasoning holds up, which is exactly what an interviewer is judging. But if you want, say, a course drilling mock interviews or FAANG-specific patterns, I don't have any information suggesting that's what this is — I'd rather tell you that plainly than oversell it.

Asked What's the difference between the self-paced and graded tiers?

Answered

The core content is identical either way — same eight weeks, same videos, notes, and exercises. The difference is what happens after you submit an exercise.…

The core content is identical either way — same eight weeks, same videos, notes, and exercises. The difference is what happens after you submit an exercise. On the self-paced tier ($290), you get the material and do the eight design exercises on your own, but no one reviews what you wrote. On the graded tier ($640), you submit your written design and diagram each week and get written feedback within three working days — usually pointing at an assumption you didn't realize you'd made. The feedback isn't grading you against a single "correct" answer, since these problems don't have one. It's checking whether your design actually follows from the requirements you were given, and whether you noticed the tradeoffs you were making or just backed into them. For what it's worth: if budget allows for only one upgrade, make it this one. Most people who've taken the course say the feedback is what actually changed how they think, not just the videos. You catch your own blind spots a lot slower reading them yourself than having someone else point at the exact sentence where you assumed something you shouldn't have. Both tiers come with the thirty-day refund policy and lifetime access, and there's a team licence rate ($480/seat) if you're buying five or more seats for a team — that's the graded-equivalent experience at a lower per-seat cost, though I don't have specifics on whether the team tier includes feedback by default, so check with support on that if it matters for your decision.

Asked Do I need to know a specific programming language?

Answered

No — you don't need a specific programming language for this course. There's very little code involved. The examples reference Postgres, Redis, and Kafka by name (being concrete helps make the ideas stick), but the underlying concepts — sharding, caching,…

No — you don't need a specific programming language for this course. There's very little code involved. The examples reference Postgres, Redis, and Kafka by name (being concrete helps make the ideas stick), but the underlying concepts — sharding, caching, idempotency, and so on — transfer regardless of what language or stack you work in day to day. The two-years-of-experience recommendation is really about having hit these problems in practice, not about knowing any particular tech.

Asked Can my employer be invoiced?

Answered Yes — your employer can be invoiced. Email [email protected] with the company details and a purchase order if one's required. If you're purchasing for five or more people, mention that too, since team licences of five or more get the reduced rate of $480 per seat instead of the standard pricing. Anything else you want to know about pricing or getting set up?