Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.

Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.

For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.

Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).

What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.

In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.

These are available to read completely free online, but I do plan to purchase the physical books some day.

[edit] I realize that I should probably give more context to my answer. The books on the site are basically interviews with the authors of the software and they discuss what choices they made as well as the advantages/tradeoffs of this approach. In other words, the direct answer to your question is to learn by reading what other people have written about their own successes and glean from that.

[edit 2] Your favorite LLM could also provide a list of books that are similar in spirit, but there's just something about the series that I linked to that I like.

When I'm building with AI now, it's much faster, yeah, but it's extremely difficult to learn these patterns, so I feel like slowing down the pace when working with LLMs (although very difficult), and researching things properly will allow you to develop these muscles, and bring benefits in the long run.