Tradeoffs

Every design decision involves tradeoffs. Understanding them is key to good system design.

Fundamental Tradeoffs

1. Consistency vs Availability (CAP)
2. Latency vs Throughput
3. Complexity vs Simplicity
4. Cost vs Performance
5. Flexibility vs Optimization
6. Short-term vs Long-term

Tradeoff Matrix

Tradeoff	Option A	Option B	Choose A When
Consistency vs Availability	Strong consistency	High availability	Correctness critical
Latency vs Throughput	Low latency	High throughput	Real-time systems
Complexity vs Simplicity	Feature-rich	Simple	Long-term maintainability
Cost vs Performance	Cheap	Fast	Budget constrained
Cache vs Freshness	Cached data	Real-time data	Stale data acceptable
Normalize vs Denormalize	Normalized	Denormalized	Write-heavy vs read-heavy
SQL vs NoSQL	ACID	Scalability	Transactional vs flexible
Sync vs Async	Synchronous	Asynchronous	Real-time vs background

Specific Tradeoffs

Caching:

Cache everything → Fast reads, stale data possible
Cache nothing → Fresh data, slow reads

Solution: Choose TTL based on freshness requirements
- Stock prices: 0 seconds (no cache)
- Product catalog: 5 minutes
- User profiles: 1 hour

Database Design:

Normalize (3NF) → No duplication, complex joins
Denormalize → Fast reads, data duplication

Solution: Start normalized, denormalize hot paths

API Design:

RESTful → Standard, well-understood
GraphQL → Flexible queries, complex
gRPC → Fast, typed contracts

Solution: REST for public APIs, GraphQL for complex clients, gRPC for internal services

In system design interviews, communicating tradeoffs effectively is as important as making good decisions.

The Tradeoff Communication Pattern

1. State the options
2. Explain the tradeoffs
3. Justify your choice
4. Acknowledge limitations

Example:
"For caching, I have two options:
1. Redis (fast, complex, expensive)
2. Local cache (simpler, less scalable)

I'll choose Redis because:
- We need distributed caching across servers
- The added complexity is justified by scalability

Limitations:
- Adds network latency
- Requires cache invalidation strategy

Common Interview Scenarios

Scenario: Database Choice

"I'm choosing between SQL and NoSQL.

SQL (PostgreSQL):
+ ACID transactions
+ Complex queries
- Harder to scale horizontally

NoSQL (Cassandra):
+ Easy horizontal scaling
+ High write throughput
- No complex joins
- Eventual consistency

I'll choose PostgreSQL because:
- We need ACID for financial data
- Query complexity is high
- We can scale with read replicas

For the analytics service, I'd use Cassandra
because it's write-heavy and can tolerate
stale data."

Scenario: Synchronous vs Asynchronous

"For the notification system:

Synchronous:
+ Simpler
+ Immediate feedback
- Slower response
- Blocks on notification delivery

Asynchronous:
+ Faster response
+ Better reliability
- More complex
- Delayed notification

I'll choose async because:
- Notifications don't need to block user action
- Better reliability with retry logic
- User experience is better with fast response

Tradeoff Presentation Tips

1. Be explicit: Name the tradeoff clearly
2. Use data: Reference numbers when possible
3. Show alternatives: Present at least 2 options
4. Justify decision: Explain why you chose what you did
5. Acknowledge limits: Mention what you sacrificed

Use a structured framework to make and document design decisions.

Decision Framework

1. Identify the decision to make
2. List options
3. Evaluate criteria
4. Score options
5. Make decision
6. Document rationale

Evaluation Criteria

Technical Criteria:
- Performance (latency, throughput)
- Scalability (horizontal, vertical)
- Reliability (fault tolerance)
- Security (authentication, encryption)
- Maintainability (code, operations)

Business Criteria:
- Cost (infrastructure, operational)
- Time to implement
- Team expertise
- Vendor lock-in
- Regulatory compliance

Weighted Decision Matrix

Decision: Database Technology

Criteria (Weight)    | PostgreSQL | Cassandra | DynamoDB
---------------------|------------|-----------|----------
Performance (30%)    |     8      |     9     |    9
Scalability (25%)    |     6      |     9     |    9
Consistency (20%)    |     9      |     6     |    7
Cost (15%)          |     8      |     7     |    6
Team Expertise (10%) |     9      |     5     |    7

Weighted Score:      |   7.65     |   7.65    |  7.75

Decision: DynamoDB (highest score)
Alternative: PostgreSQL (if consistency is higher priority)

ADR Template

# ADR 001: Use Redis for Caching

## Status
Accepted

## Context
We need to cache frequently accessed data to reduce database load.

## Decision
Use Redis as the caching layer.

## Options Considered
1. Redis - In-memory, fast, complex
2. Memcached - Simple, limited features
3. Local cache - Simple, not distributed

## Rationale
- Redis provides data structures we need
- Supports pub/sub for invalidation
- Team has experience with Redis

## Consequences
+ Fast reads (< 1ms)
+ Distributed caching
+ Rich data structures
- Adds operational complexity
- Requires cache invalidation strategy

Common Design Decisions

Decision	Options	Framework
Database	SQL, NoSQL, NewSQL	CAP, PACELC
Caching	Redis, Memcached, Local	Consistency vs Performance
Messaging	Kafka, RabbitMQ, SQS	Throughput vs Latency
API	REST, GraphQL, gRPC	Simplicity vs Flexibility
Scaling	Vertical, Horizontal	Cost vs Scalability