Two engineers are designing a notification system. One says: “We should write notifications to the database synchronously, then send them. That way we never lose a notification.” The other says: “We should use a message queue. Writing to the queue is faster, and we can retry failed sends without blocking the caller.”
They argue for twenty minutes. Both are correct. Neither has named what they are disagreeing about.
The first engineer is prioritising Consistency over Performance — they want to guarantee that a notification will never be lost (correctness) at the cost of higher write latency. The second is prioritising Latency over Durability — they want fast writes at the cost of the small window in which a queue failure could lose a notification before delivery.
These are both valid positions. They are not competing opinions — they are different points on the same tradeoff dial. Once you name the tradeoff, the discussion becomes: what does our product require? What does our SLO say? That is a one-minute conversation, not a twenty-minute argument.
The ten architecture tradeoffs are the vocabulary for every design decision. You have been making these choices implicitly since you wrote your first distributed system. What follows makes them explicit.