I'm a adherent to the idea that nothing teaches system design except experience and having to fix your own mistakes in sufficiently large systems.
In most software development courses, the student is learning how to make something (and then after that is done, its thrown away for the next homework assignment).
System design is often about writing the glue between different constraints - frequently through another constrained component... and then having to live with the consequences of that design for a year or more (possibly trying to fix it).
Take the "I've got a relational database here with mixed transactions and record updates and a document database there that I want to reflect the current state of an object in the relational database." And so you get to figure out how to use GoldenGate ( https://docs.oracle.com/goldengate/c1230/gg-winux/GGCON/intr... ) or Postgresql to amqp ( https://livebook.manning.com/book/rabbitmq-in-depth/chapter-... ) and then write something that consumes that and writes it into CouchDB or MongoDB (which do you chose? why?)
Once you've got that working... keep it working for a year or two.
I think I agree with you almost fully but not quite. Systems design in the sense of 'designing systems' means that a lot of the time you are dealing with glue, but perhaps quite a bit of time is spent on the 'blueprint'. A good system design means that you can synthesise your learned knowledge with that of the body of knowledge to produce a new solution. So sure, you from experience know that a doesn't go with b, but if you include c, you can z. But sometimes you need to break things down further, to components you have haven't used, have never seen before, and only barely understand. This is where your CS first principles come in. You need a URL shortener. Should you create a hash of the url on demand when requested? Well maybe not, because you could get collisions, how about pre generating and picking them up at request time? Oh look, someone has written an article on this problem!
So much of system doesign is understanding what your 'actual' problem is, and then thinking it through, looking for what others have done, and then bringing it together with your team knowledge.
How did you like 6.824 specifically? I haven’t taken any systems courses as I’m not too interested in it, but I realize distributed systems is important in the industry as a SWE and was thinking of watching the videos. Any other courses you recommend on the topic?
This course is incredible. It's short, and it's a course aiming to teach people how to ace their systems design interview, yet (perhaps unknowingly) teaches you almost everything foundational you might need to know about systems design and the reasons behind each choice.
The courses go by a certain order after the core intro courses. For example, the 140's courses are more systems-y than say, the 150's which are theory courses.
Intro core systems include 106B, 107, 110, and the newly introduced 111.
