Two decades ago, when I was learning to code, the career path for engineers was to eventually become a "software architect". The architect was to be the god among mortals who would "design" large systems and dictate how these things fit together.
Fast-forward a few years and it turned out the "architects" were the biggest waste of of time and money. The best system designs came from the low-level engineers who were actually building the individual components.
In my humble opinion, the best way to learn big system design is to just put in your 10,000 hours of coding. The principles necessary for multi-thread concurrency are not so different from multi-datacenter concurrency. I suspect there are 1,000s of subtle design patterns that one can perhaps never fully articulate.
Two decades ago, when I was learning to code, the career path for engineers was to eventually become a "software architect". The architect was to be the god among mortals who would "design" large systems and dictate how these things fit together.
Fast-forward a few years and it turned out the "architects" were the biggest waste of of time and money. The best system designs came from the low-level engineers who were actually building the individual components.
In my humble opinion, the best way to learn big system design is to just put in your 10,000 hours of coding. The principles necessary for multi-thread concurrency are not so different from multi-datacenter concurrency. I suspect there are 1,000s of subtle design patterns that one can perhaps never fully articulate.
Just my $0.02. Good luck!