Cloud Architecture
Advanced 16 min read Cloud Architecture

Design Tradeoffs & Constraints

Choose tradeoffs on purpose — with worksheets

Every architecture is a set of tradeoffs. Learn to argue them explicitly: consistency vs availability, cost vs resilience, latency vs consistency, control vs managed, time-to-ship vs rigor. Constraints (budget, team, compliance, SLA) turn 'ideal' into 'feasible with a KPI.'

tradeoffconstraintCAPPACELCconsistencylatencycostcontrol
Prerequisites: Reference Architectures
Before we start

What you will learn

  • Name the classic tradeoff axes (consistency, cost, latency, control)
  • Turn constraints into a decision matrix
  • Document tradeoff decisions (ADR-style) so they survive
In 60 seconds

Design = optimize under constraints. Axes: CAP-style (consistency vs availability under partitions), PACELC (even without partitions, latency vs consistency), cost vs resilience, managed vs control, speed vs rigor. Constraints (budget, SLA, team, compliance) prune the solution space; a decision matrix + ADR records the choice and the re-evaluation triggers.

Introduction

What is this?

CAP: partition-tolerant systems choose C or A; PACELC adds 'else-if-not-partitioned: latency or consistency' (Async replicas choose latency; sync choose consistency). Other axes: cost vs resilience (more nines = more $), managed vs control (serverless vs raw VMs), time-to-market vs engineering rigor (MVP vs platform). Constraint inputs: budget cap, compliance (residency/audit), SLA (RTO/RPO/latency), team size/skills, existing vendor commitments. Practice: decision worksheet (options × constraints → score), ADR (Context, Decision, Consequences, Trigger-to-revisit), review gates. The tradeoff isn't 'badness to minimize' — it's choosing which failure you accept (the least-principle: prefer the failure you can answer for).

Motivation

Why do you need it?

  • Unconsidered tradeoffs become surprises: the async DB 'just works' until the read-back proves stale.
  • An ADR with a re-eval trigger survives team churn — the decision doesn't evaporate.
  • Explicit constraint scoring kills the 'ideal-architecture prize' that never ships.
  • Choosing accepts the tradeoff consciously: one failure you can answer is better than two you can't.
Think about it

Mental model

Imagine

A family budgeting a house under a fixed salary: you can't have the open plan AND the basement office AND the garage

Think of

Design constraints

The floor plan (architecture) gets scored against budget, space, and deadlines; the compromises are written down so the family agrees on why — same as an ADR, same as 'which failure we prefer'.

Mechanics

How it works

  • List the constraints: budget, SLA (latency/RTO/RPO), compliance, team, timeline.
  • Draw the axis options (sync vs async, managed vs control, cost vs nines).
  • Council the worksheet: which options survive the constraints; which fail-ables are acceptable?.
  • Write the ADR: Context/Decision/Consequences/Trigger.
  • Attach a review gate: the trigger re-opens the decision when constraints change.

Tradeoff worksheet.

Constraints
Axes
Score options
ADR
Re-eval trigger
Hands-on

Examples

ADR snippet

ADR snippet
# ADR-017: order reads prefer availability over strict consistency
# Context: p99 200ms, multi-AZ read replicas, seasonal spikes
# Decision: reads served from async replicas (eventual); writes go primary (sync).
# Consequences: read-after-write lag risk; mitigated by read-through cache + idempotent writes.
# Trigger to revisit: user-facing 'read-after-my-write' complaints, or reads > sync-needed.

The ADR commits the chosen tradeoff with its consequence and the trigger that re-opens it — the decision survives turnover.

Real world

In production

  • PACELC framing for DB choice: reads async for latency unless strong-needed.
  • Cost-vs-resilience matrix for DR/HA tiering (warm vs active per SLA).
  • Every major design gets an ADR with constraints+trigger; review triggers quarterly.
Guidelines

Best practices

  • Write constraints FIRST in any design doc; scoring against them is honest.
  • Use ADRs for every non-trivial pick; include the trigger-to-revisit.
  • Prefer accepting the failure you can answer for (least-principle).
  • Re-evaluate on constraint change (budget cut, SLA bump, new law).
  • Review tradeoff axes as a group: options are rarely one-axis; label the axes.
Watch out

Common mistakes

  • Choosing async for latency and forgetting to instrument the staleness availability.
  • ADR without trigger — the decision fossilizes despite suiting nothing anymore.
  • Scoring constraints as 'nice-to-have' so 'ideal' design sails through with no tradeoff.
  • Pretending there's no tradeoff ('we'll have consistency AND latency'): there always is.
When things break

Debugging tips

  • Read-after-write surprise → find the async-replica read path (the decision ADR named it); route flagged reads to sync if needed.
  • ADR trigger fired but nothing reopened → the review gate wasn't calendared; schedule quarterly tradeoff review.
  • Team disagrees on a past decision → the ADR's 'Consequences' should make the 'why' legible — if not, the ADR was too vague.
  • Cost exploded on a tradeoff pick → the cost-vs-resilience line wasn't scored; re-run the matrix with real numbers.
Interviews

Interview checkpoint

Practice

Hands-on lab

Score a Tradeoff and Write its ADR
30 min · intermediate
In progress
Objectives
  • Turn a workload into constraint rows
  • Score options against them
  • Write an ADR with a trigger

Score a Tradeoff and Write its ADR

30 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

PACELC adds the honesty that, even without partitions, you choose between:

2

What tells you an ADR is actually being used?

Go deeper

Official documentation

ADR best practices
docs
AWS DA video: CAP
docs
Azure tradeoff catalog
docs