Cost Is a First-Class Constraint

The Constraint Everyone Forgets Until the Invoice

Architecture diagrams show boxes; cloud bills show dollars. Cost behaves exactly like latency or availability — a measurable, designable, tradeable quantity — and belongs in every decision at the same rank. A system that is fast, available, and unprofitable has failed its actual requirements.

 EVERY BOX HAS A MONTHLY PRICE

 Client → CDN ──── egress + requests        $X
         → LB   ──── LCU hours              $Y
         → App×N ── compute instances       $Z (scales with traffic)
         → Postgres ── instance + storage   $W (scales with data)
         → Redis  ── node size              $V
 
 total = f(traffic, retention, redundancy) — and each multiplier
 is an ARCHITECTURE choice, not an ops afterthought

Where the Money Actually Goes

Typical cloud spend distribution for a scaling product (illustrative):

Component	Share	Why it grows
Compute (app servers)	~40%	Scales with peak traffic provisioned
Data transfer/egress	~20%	Per-byte pricing; sneaky multiplier across AZs
Databases	~15%	Instance class + replicas + storage growth
Storage/objects	~10%	Retention policies decide slope
Cache/queues/misc	~15%	Often over-provisioned early

Egress deserves special suspicion: data transfer between AZs or out to the internet is priced per GB and can exceed compute costs for media-heavy systems. Cross-AZ chatter caused by careless replica reads is a classic silent burn.

Unit Economics: The Design-Level Metric

The question that turns cost into architecture:

 cost per request / per user / per stored object

 example (illustrative): feed read
   cache hit path:    CDN+Redis          ≈ $0.00001
   cache miss path:   fan-out to 1k posts joined in Postgres ≈ $0.001
   100x difference — so cache hit ratio IS the cost model,
   and cache design becomes a financial decision

When unit cost × projected volume exceeds revenue per unit, no amount of engineering polish saves the business — the architecture must change.

Cost-Driven Design Moves

Lever	Effect
Retention policies (delete cold data)	Flattens storage slope permanently
Compression + columnar formats	Direct multiple on storage + scan costs
Reserved/scheduled capacity vs autoscale	30–60% off steady baseline compute
CDN offload of static + cacheable content	Cheaper bytes + origin protection
Batching writes, async processing	Amortizes expensive operations
Right-sizing off peak-average gap	Kills idle capacity waste

The Interview Angle Increasingly Tested

Senior loops now routinely ask “what does this cost?” A defensible answer needs only order-of-magnitude honesty:

• State assumptions: instance types, counts, traffic.
• Rough-multiply: “20 app instances ≈ $1.5k/month, RDS ≈$2k, egress at 50TB ≈ $4k — call it$10k/month at this scale.”
• Tie back to drivers: “if budget halved, first lever is trimming peak headroom and moving heavy reports off the transactional DB.”

Exact numbers are unnecessary; knowing which levers exist and what they move is the tested skill.

Interview Framing

Treat cost as the fourth dimension alongside latency, availability, consistency. Designs that mention where money concentrates (egress, cross-AZ chatter, over-provisioned peaks) and name their cheapest acceptable configuration signal production maturity beyond diagram fluency.