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.
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.
MIT 6.824: Distributed Systems https://www.youtube.com/watch?v=cQP8WApzIQQ&list=PLrw6a1wE39...
CMU The Databaseology Lectures https://www.youtube.com/watch?v=GkgDDs9EJUw&list=PLSE8ODhjZX...
You essentially learn systems by looking at lots and lots of examples of how good real world systems are designed.
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.
Intro core systems include 106B, 107, 110, and the newly introduced 111.
Happy learning!