Day 60

The finish, which is really a base camp 🏁

Today’s one idea: you present your capstone out loud as if to an interviewer, write an honest retrospective on the whole 60 days, and make a concrete plan for what comes next. And you accept the real lesson of the finish line, which is that it is not one. Sixty days does not make anyone a master of distributed systems, and anyone who tells you two months did is selling something. What it makes you is someone with a method, and a method compounds for a career.

Last day. Do it properly, and be a little proud. You earned it.

Before you start ⏪

Your whole capstone: the design doc (Day 55), the running slice (Day 56), the load-test numbers (Day 57), the architecture doc (Day 58). Your review grid (Day 59). Your 60 days of logs and RESULTS.md files. It is all here. Today you look at it as a body of work, because that is what it is.

Words you will meet today 📖

A retrospective is an honest look back: what worked, what did not, what you would do differently. Not a victory lap, a review. The point is to carry the lessons forward, not to congratulate yourself.

Base camp is the staging point partway up a mountain, not the summit. It is the right picture for day 60: you have climbed enough to attempt real things, and the hard, interesting climbing is still ahead.

A learning plan is the small set of concrete next steps you commit to while the momentum is still warm, so day 61 is not a cliff you fall off but a path you already marked.

Block 1: read (50 min)

What to read and watch today 📚

Read, for where to go next:

  • How I’d prepare for a system design interview if I were starting from scratch from Hello Interview. A sane, honest plan for continued interview prep, now that you have the foundations.
  • Designing Data-Intensive Applications by Martin Kleppmann. The book. This course was the hands-on on-ramp; DDIA is the deep, rigorous treatment of almost everything you touched. Reading it now, after 60 days of measuring, will land completely differently than it would have on day 1.
  • Jepsen. Kyle Kingsbury breaks real distributed databases and documents exactly how they violate their own consistency claims. Humbling, brilliant, and the natural next step after week 5.

Watch, if you want one for the road:

Present your capstone, out loud 🎤

The first real task today is a performance, the same muscle you drilled in the mocks, but now on your own system. Set a 20-minute timer and present your capstone to an empty room as if an interviewer is sitting there. Walk the shape: what it does, the scale, the design, the one decision you are proudest of, the measured numbers from your load test, where it breaks, and what you would do next. Do not read your doc. Present it, from the doc, in your own words, the way you would in a room.

This is the exercise that proves the 60 days took. If you can stand up and explain a system you designed, built, broke and wrote up, backed by numbers you measured, calmly, in 20 minutes, you are not someone who memorised answers to “design Twitter.” You are someone who can reason about real systems. That is the whole goal, and it outlasts any interview.

The retrospective, and the honest truth about the finish 🧭

Then look back across all 60 days. What surprised you most? Which number from which lab still sits with you? What do you now reach for instinctively that you had never heard of two months ago? And, honestly, what is still weak? Write it down, because this is the review that turns 60 days of activity into durable judgement.

And hold the honest truth gently: this is base camp, not the summit. You have not mastered distributed systems in two months. Nobody has. What you have is a method, and it is the right one: measure before you guess, know the real numbers, reason from the data in front of you, design the failure path on purpose, and explain your thinking clearly. That method is exactly how good engineers work, and it compounds every year you keep using it. The certificate is not this repo or a score. It is that you now think like someone who builds real systems.

Block 2: drill (40 min) ✍️

Paper first, into notes/day-60-drills.md. The retrospective.

D1. The presentation. After you present your capstone out loud, write the one part that came out clean and the one part that came out muddled. The muddled part is a gap worth one more pass.

D2. The surprise. Across all 60 days, the single number or result that surprised you most, and what it changed in how you think.

D3. The instinct. Three things you now reach for automatically that you had not heard of two months ago.

D4. The honest weakness. The one topic you would still be nervous to be asked about, and whether you will close it or accept it for now.

D5. The next three. Three concrete things you will do after today to keep going (read DDIA chapter by chapter, build the next slice of the capstone, do a mock a week, contribute to an open source system, whatever is real for you).

Block 3: build (100 min) 🔧

Finish it. Open labs/day-60-finish/FINISH.md, copy it, and complete the three parts: the capstone presentation notes (the shape you will walk through), the retrospective (the honest look back), and the learning plan (the concrete next steps, with the first one scheduled). Then do the thing that makes this course different from a tutorial you watched: make sure your work is public. Your fork, with your labs, your numbers, your capstone and your architecture doc, is a portfolio. A hiring manager can see you did the work, not just claimed it.

Spend the last stretch making your repo something you would send someone: a short README on your fork that points to your capstone doc and your best few RESULTS.md files, so the work is easy to find.

What finishing well looks like

You presented your capstone out loud and it mostly held together. You wrote an honest retrospective, not a victory lap. You have three concrete next steps and the first one is scheduled. And your work is public, tidy, and easy to point someone at. That is a finish you can stand behind.

Deliverable

Your filled-in FINISH.md, a tidy public fork, and a scheduled first next step. That is the course, complete.

Block 4: write (30 min) 📣

The last post. Your angle is the honest, earned reflection: 60 days, what it actually gave you, and the truth that it is a base camp, not a summit. “60 days of system design, done. I did not master distributed systems in two months and I will not pretend I did. What I have is a method: measure before I guess, know the real numbers, design the failure path on purpose. Here is my capstone, built and broken and written up, and here is where I go next.” Link your repo and your capstone doc. Thank the people who followed along. This post is the one that might actually get you an opportunity, because it shows the work.

Example posts are on the Day 60 posts page.

End of day: log it, and look back at all of it 📝

Log the last three: the part of your capstone presentation you were proudest of, the single biggest thing these 60 days changed in how you think, and the first concrete step you will take next.

Then close the laptop and notice what happened. Sixty days ago you called yourself a complete beginner. You now have a fork full of systems you built and broke on purpose, a capstone you can present, and a way of thinking that does not come from a video. Keep building. Keep measuring. Keep sharing what you learn. The climb from here is the good part.

Solutions 🔑

There is no answer key for the last day. The capstone is yours, the retrospective is yours, and the plan is yours. But here is the one thing worth carrying above all else.

The one habit to keep forever

If you forget every specific number in this course, keep this: predict, then measure, then close the gap. You did it 60 times. You guessed how slow a disk was, how a cache would behave, where your own service would break, and every time the gap between your guess and the measurement taught you something a blog post never could.

That habit is the whole thing. Engineers who guess and ship and hope are everywhere. Engineers who predict, measure, and reason from what they actually saw are rare, and they are the ones who build systems that hold up. You are now the second kind. Do not stop measuring.

Thank you for doing the work. Now go build something, break it on purpose, and tell people what you found.

Mark your progress for this day

Table of contents