42

What are the best resources to learn system design in a structured way?

Profile picture
Entry-Level Software Engineer [SDE 1] at Amazon2 years ago

Amazon is well-known for its design doc reviews, which appear to be small-scale system design reviews. However, I'm having trouble understanding them, let alone recommending modifications.

I'm aware of Alex Xu's Byte by Byte go course, but I'm skeptical using it as it's specifically for interview preparation. I want to learn for the workplace. I can definitely look at blog posts and current design documentation, but I'd prefer something more structured. How can a novice learn system design and grow to the advanced/intermediate level? What books or resources would you suggest?

5.3K
2

Discussion

(2 comments)
  • 43
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero, PayPal
    2 years ago

    I highly recommend my system design course: [Course] System Design Masterclass: Shipping Real Features To Production. Here's why:

    • It's not as structured as a traditional online course (largely because system design is nothing you can shove into a course), but it covers a real-world system design example.
    • You are 100% correct that resources like ByteByteGo are very focused on the interview aspect of system design. As you probably guessed, interview system design and actual system design are very different, which I cover in-depth in the first video within the series.
    • On top of the 10 part structure, I wrote a very comprehensive system design doc for the series that you should be able to largely copy-paste into your work at Amazon in terms of format. I used this system design doc format at Meta and Robinhood (2 very different companies), and I taught it to all my mentees to great success.

    After you go through that I recommend this in-depth discussion around tactics to get better at system design alongside a breakdown of how to measure how good you actually are at system design: "How to upskill effectively, especially with the software design aspect?"

    All that being said, I want to throw out some words of caution to temper expectations:

    • System design in particular is something that is very fuzzy and effectively impossible to get truly good at with external resources.
    • I totally get how you and many other earlier-in-career software engineers want some book or course to make you good at system design. I want that too, which is why I did my best to capture the heart of system design with my masterclass series.
    • However, system design, like coding overall, is something you get good at by doing - The role Taro can play here is setting you up with the correct overall mentality and general concepts.
    • For more context, here's an incredibly in-depth explainer I wrote about the nuances behind clean code.

    You work at Amazon which is filled to the brim with complex systems and immensely talented engineers who build them. Your goal should be to learn as much from them as possible. Here's some tactics you can use to get that system design mastery from them:

  • 33
    Profile picture
    Principal Software Engineer at Amazon
    2 years ago

    An ambitious SDE-I! You will go far if you keep this up.

    If you are having problems understanding your team's system design documents, I recommend that you proceed no further until you can understand your team's documents. I would try to read a document several times and highlight the acronyms, concepts, and sentences that don't make sense and do your best to figure things out on your own. If you get stuck, I would schedule time with folks on your team that can parse the document to walk you through it. Repeat until you've consumed all of your team's documents, understand the problems each document is addressing, and the solution that was recommended. This may take some amount of time but it's critical.

    The reason I recommend this approach is that system design is a high-dimensional space and it's easy to get lost. You're unlikely to stumble upon a book, article, or video that's going to address the unknown-unknowns you currently have. At this point you likely both have gaps in conceptual understanding of general system design concepts and gaps in understanding your team's existing system, its endemic problems, and historical context.

    Once you have a retrospective understanding of your team's software and systems, only then would I recommend that you attempt to write a prospective system design document. The good news is that you need to search no further than your team's document repository and your team members to grow in this area.

    Good luck!

    -Steve