The 8 dimensions of architectural trade-offs

• Performance vs cost — More compute power costs more. Caching reduces latency but adds operational complexity and memory cost. In-memory databases (Redis) are fast but expensive at scale compared to SSD-backed databases.
• Consistency vs availability (CAP theorem) — In a network partition, you can return consistent data (possibly blocking/failing) or return available data (possibly stale). Financial transactions need consistency. Social media feeds can tolerate eventual consistency.
• Flexibility vs simplicity — A microservices architecture lets each service evolve independently. A monolith is dramatically simpler to build, deploy, and debug. Premature flexibility is a form of waste.
• Build vs buy — Managed services (RDS, DynamoDB, SQS) cost more per unit but eliminate operational overhead. Self-managed is cheaper at scale but requires expertise. The inflection point where build beats buy depends on your team's specialization.
• Short-term speed vs long-term maintainability — Technical debt is a trade-off: move faster now, pay back later. The question is always whether the interest rate is worth the principal. A quick hack that ships a $5M feature faster may be worth the debt. A quick hack in the auth system may not.
• Reliability vs cost — Multi-AZ = double infrastructure cost but near-zero downtime. Single-AZ = half cost, risk of 30-minute+ outage on AZ failure. Right answer depends on business criticality.
• Latency vs throughput — Batching requests increases throughput (more processed per second) but increases individual latency. Streaming processes immediately (low latency) but lower throughput per connection. Choose based on user-facing requirements.
• Security vs usability — MFA reduces account takeover risk but adds friction to login. Strict CSP headers prevent XSS but may break third-party integrations. Zero-trust networking prevents lateral movement but adds latency and complexity.