Pragmatism
Preferring the simplest architecture that satisfies the requirements, and treating additional structure as a cost that must be justified.
The working rule: the simplest architecture that meets the requirements usually wins, because simplicity buys understandability, and understandability buys everything else — faster changes, faster diagnosis, fewer places for a bug to hide, and a shorter ramp for the next engineer.
Pragmatism is not the same as cutting corners. It is refusing to pay for capability you do not need, while paying willingly for capability you do. A message broker in a system with one producer and one consumer is not pragmatic engineering; neither is skipping a backup because it is Friday.
The diagnostic question for any proposed component: which requirement does this satisfy, and what happens if we leave it out? Anything without a crisp answer is speculative, and speculative complexity is the kind that never gets removed.