I haven't had a structured path while learning architecture. I voraciously read (and re-read) articles on lots of different aspects or architecture and then try to piece it together in my mind into something implementable. There are so many implicit assumptions in arch articles, that they often merit going back to re-read later.
For example, you often hear load balancers mentioned for scalability. But that doesn't really "solve" any scalability issue... it just shifts the burden of scalability from your services to your database. And databases which are scalable (i.e. generally not SQL) have different constraints and problems in their usage for dev and ops. So you really have to take things one at a time and address the constraints important to your business (all the -ilities). I'll include one of my favorite arch videos below. There is a bit of philosophy at the front, but he gets into it later on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't had a structured path while learning architecture. I voraciously read (and re-read) articles on lots of different aspects or architecture and then try to piece it together in my mind into something implementable. There are so many implicit assumptions in arch articles, that they often merit going back to re-read later.
For example, you often hear load balancers mentioned for scalability. But that doesn't really "solve" any scalability issue... it just shifts the burden of scalability from your services to your database. And databases which are scalable (i.e. generally not SQL) have different constraints and problems in their usage for dev and ops. So you really have to take things one at a time and address the constraints important to your business (all the -ilities). I'll include one of my favorite arch videos below. There is a bit of philosophy at the front, but he gets into it later on.