Well, in terms of getting feedback, there are services like interviewing.io, exponent, and formation, but they are expensive. Maybe someone has made an AI tool to help with sys design? Even if not, GPT-4 is pretty helpful. Once I get access to the image feature, I'll try feeding it diagrams to evaluate.<p>I assume that gaining the substantive knowledge isn't the issue--it sounds more like you want to know how to put it all together, structure your responses, understand the criteria, etc.<p>I think there are a couple broad approaches for overall structure<p>1) Spend a lot of time up front gathering requirements; largely functional requirements, but also a major point with a lot of the better questions (i.e. questions more like "design a parking lot" than "design Twitter") is often to get there is a performance trade-off (e.g. maybe for certain things, consistency is more important than latency/speed considerations).<p>2) You can either do your main diagram or do data model first.<p>3) After high-level diagram and data model, discuss single-points of failure, additional scaling issues, etc.<p>The overall vibe of communication here is that you want to be discussing trade-offs and various tech choices. The most obvious, and something which will come up almost all the time, is SQL v NoSQL databases. It's mostly pretty straight-forward to list trade-offs for a given use-case/scenario and make a case for one over the other.<p>There often won't be right answers to various components of the exercise. Again, NoSQL and SQL is a paradigmatic example. In theory, you can do anything in NoSQL and vice versa, but knowing the trade offs is key.<p>System design interviews are basically like law school exams. I can't help but note that even though basically nobody reading this will have gone to law school, and thus there is nobody nodding their head right now.