Tradeoffs in System Design

                    Consistency
                        ▲
                       /│\
                      / │ \
                     /  │  \
                    /   │   \
                   /  CA│CP  \
                  /     │     \
                 /      │      \
                ▼───────┴───────▼
          Availability ───── Partition
                              Tolerance

Network Partition Occurs:
┌──────────┐         X         ┌──────────┐
│  Node A  │─────────X─────────│  Node B  │
│  Data: 1 │         X         │  Data: 1 │
└──────────┘         X         └──────────┘
                     X
Client writes "2" to Node A...

Choice 1 - Consistency (CP):
  Node A rejects write until partition heals
  System unavailable but consistent

Choice 2 - Availability (AP):
  Node A accepts write, Node B has stale data
  System available but inconsistent

User Profile Service:

Reads: AP (serve stale data, high availability)
  └── User sees slightly old profile, acceptable

Writes: CP (ensure consistency)
  └── Profile update must succeed correctly

Payment Service:

All operations: CP (never lose money)
  └── Prefer unavailability over inconsistency

                Is there a partition?
                        │
              ┌─────────┴─────────┐
              │                   │
             Yes                  No
              │                   │
         ┌────┴────┐         ┌────┴────┐
         │         │         │         │
      Choose A  Choose C  Choose L  Choose C
         │         │         │         │
        PA        PC        EL        EC

Scenario: E-commerce product catalog

During normal operation (no partition):
  Option 1: Strong consistency (EC)
    - Every read sees latest price
    - Higher latency (coordination required)
    
  Option 2: Low latency (EL)
    - Reads might see 5-second-old price
    - Sub-millisecond response

Most e-commerce: Choose EL (latency) for reads
  - Slightly stale price acceptable
  - User experience > perfect consistency

Strong                                                    Weak
  ├─────────────────────────────────────────────────────────┤
  │                                                         │
Linearizable  Sequential  Causal  Read-your-  Eventual  
              Consistency         writes
              
  ◄──── Higher latency, Lower throughput ────────────────►
  ◄──── Easier to reason about ──────────────────────────►
  ◄──── More coordination required ──────────────────────►

Timeline:
T1: Client A writes X=1 ──────────[  write  ]───────────
T2:                      Client B reads X ──[read]──
                                            Must see X=1

Client A: Write X=1, Write Y=2
Client B: Write X=3

Valid orderings:
1. X=1, Y=2, X=3 → Final: X=3, Y=2
2. X=1, X=3, Y=2 → Final: X=3, Y=2
3. X=3, X=1, Y=2 → Final: X=1, Y=2

All clients must see same ordering.

Client A: Write X=1
Client B: Reads X=1, then Writes Y=2 (caused by reading X)

Guarantee: Anyone seeing Y=2 will also see X=1
No guarantee about concurrent writes from Client C

Client A: Write X=1
Client A: Read X → Must return 1

Other clients might still see old value.

T0: Write X=1 to primary
T1: Read from replica → might return old value
T2: Read from replica → might return old value
...
Tn: Read from replica → returns 1 (eventually)

Latency: Time for single request
  Request ──────[Processing]──────▶ Response
          └────── 50ms ──────┘

Throughput: Requests handled per unit time
  ───────────────────────────────────────▶
  │ │ │ │ │ │ │ │ │ │    = 10 req/sec

Scenario: Log ingestion

Low Latency Approach:
  Log entry → Immediately write to disk
  Latency: 5ms per entry
  Throughput: 200 entries/sec

High Throughput Approach:
  Log entries → Buffer 100 → Batch write
  Latency: 500ms per entry
  Throughput: 10,000 entries/sec

Technique: Adaptive batching

if queue_size > threshold OR wait_time > max_wait:
    flush_batch()

# Small batches during low traffic (low latency)
# Large batches during high traffic (high throughput)

                    Cost
                     │
    Expensive but ◄──┼──► Cheap but
    Fast/Reliable    │    Slow/Risky
                     │

1. Right-sizing:
   Over-provisioned: 8 CPU, 32GB → using 20%
   Right-sized: 2 CPU, 8GB → using 80%
   Savings: 75%

2. Reserved capacity:
   On-demand: $100/month
   Reserved (1 year): $60/month
   Savings: 40%

3. Tiered storage:
   Hot data (SSD): Recent 30 days
   Cold data (HDD): Older data
   Archive (Glacier): Rarely accessed

Simple Architecture:
┌──────┐     ┌────────┐     ┌──────┐
│Client│────▶│Monolith│────▶│  DB  │
└──────┘     └────────┘     └──────┘
  Easy to understand, deploy, debug
  Hard to scale specific parts

Flexible Architecture:
┌──────┐     ┌─────┐     ┌─────┐     ┌─────┐
│Client│────▶│ API │────▶│Svc A│────▶│DB A │
└──────┘     │ GW  │     └─────┘     └─────┘
             └──┬──┘     ┌─────┐     ┌─────┐
                └───────▶│Svc B│────▶│DB B │
                         └─────┘     └─────┘
  Can scale independently, technology diversity
  Complex deployment, debugging, monitoring

YAGNI (You Aren't Gonna Need It):

❌ "We might need microservices someday"
   → Start with monolith, extract when needed

❌ "Let's add Kafka for future event streaming"
   → Start with simple queues, migrate when scale demands

❌ "We need a plugin architecture for extensibility"
   → Add extension points when actually needed

✅ Design for today's requirements
✅ Make it easy to change later
✅ Add complexity when justified by real needs

Build:
- Development time
- Ongoing maintenance
- Security updates
- Scaling expertise
- On-call burden
- Opportunity cost

Buy:
- Vendor lock-in
- Per-usage costs at scale
- Limited customization
- Dependency on vendor roadmap
- Integration effort

Synchronous:
┌──────┐  Request   ┌──────┐  Request   ┌──────┐
│Svc A │───────────▶│Svc B │───────────▶│Svc C │
│      │◀───────────│      │◀───────────│      │
└──────┘  Response  └──────┘  Response  └──────┘
  A waits for B, B waits for C
  Total latency = A + B + C

Asynchronous:
┌──────┐  Event     ┌───────┐           ┌──────┐
│Svc A │───────────▶│ Queue │──────────▶│Svc B │
└──────┘            └───────┘           └──────┘
  A continues immediately
  B processes when ready

1. State the tradeoff clearly
   "We're choosing between X and Y"

2. Explain the context
   "Given our requirements of..."

3. Discuss both options
   "Option A gives us... but costs..."
   "Option B provides... but sacrifices..."

4. Make a recommendation
   "For this use case, I'd choose... because..."

5. Acknowledge limitations
   "This means we accept... as a tradeoff"