Constraints
Time, users, data, the technologies you know and the ones you must use, budget and legal — the questions whose answers shape the architecture before any diagram.
Seven questions decide the design more than most requirements do: how much time, how many users, how much data, which technologies I know, which I must use, what budget, what law. Ask them before the diagram, because a design made without them is made for a project that does not exist.
The three quantities that shape a design most — how long you have, how many people will use it, how much data there is and how it grows — and the habit of answering them with a number and a source instead of with "a lot" or "not much".
Two technology constraints that look alike and are opposites: what the team already knows, and what the situation imposes. The first is a soft constraint that decides most choices by default; the second is a hard one that has to be understood rather than resented — and the "we must use X" that is neither is the one to challenge.
The two constraints engineers most often leave to someone else and most often get surprised by. Budget decides how many pieces the system may run and how; law decides what may be stored, where, for how long and who may see it. Both are design inputs, and both are cheapest when found before the schema exists.
Given the same requirements, two different sets of constraints produce two different correct architectures. The store with six weeks, two developers and tens of users is a monolith on one server; the same store with a partner sending a launch spike and a platform team is something else. Neither is the "right" architecture — each is the right one for its constraints.