[shagie]

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.

That's how you learn system design.

[phist_mcgee]

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.