Performance, reliability, security, and cost are the forces that shape every architecture
“Use microservices” or “pick Postgres” is not a decision. It’s a solution. Architecture starts with qualities you care about, then works backward to solutions.
These are the most common decision drivers. You don’t need all of them — but you must know which ones matter most in your context.
| Attribute | Definition | Typical Tradeoff |
|---|---|---|
| Performance | Speed, latency, throughput | Complexity, cost |
| Reliability | Uptime and fault tolerance | Development speed |
| Scalability | Ability to handle growth | Operational overhead |
| Security | Protection of data and access | Usability, speed |
| Maintainability | Ease of change | Initial build speed |
| Cost | Infra + engineering time | Performance, scale |
| Compliance | Legal/regulatory constraints | Flexibility |
Full access
Unlock all 12 lessons, templates, and resources for Software Architecture & Decision Patterns. Free.
Rule: If you haven’t ranked these, your architecture will be shaped by whoever shouts loudest.
You can’t maximize all qualities at once. Good teams do tradeoff math:
Write the tradeoff in plain language. It’s your architectural contract.
Abstract goals don’t drive decisions. Targets do.
Examples:
Once targets exist, teams can choose designs that hit them.
Q: Why is “We should use Kafka” a poor architectural decision statement?
Because it jumps to a solution without naming the decision driver. Kafka might improve throughput and decoupling, but it adds operational complexity and changes failure modes. The real decision statement should be: “We need to decouple order processing from user requests to reduce latency and improve reliability.”
Pick one product or system you know. Create a quality attribute table:
Example:
Scenario: Your CEO wants “the fastest app in the market,” but your infra budget was just cut 30%. What do you do?
Make the tradeoff explicit: performance vs cost. Propose a target like “P95 < 300ms for top 5 endpoints” and show cost implications. Then negotiate which endpoints deserve premium performance and where a small slowdown is acceptable. Architecture is about visible tradeoffs, not wishful thinking.
| Idea | Remember This |
|---|---|
| Decision drivers | Quality attributes shape the architecture |
| Tradeoffs | You can’t maximize everything |
| Targets | Measurable goals enable good design |
| Communication | State the driver before the solution |
Next: Boundaries, Cohesion, and the Modular Monolith