Cost Per Request
The unit economics metric that tells you if the architecture scales financially, not just technically.
Why
An architecture that handles 10x traffic is useless if it costs 10x more to do so. Cost-per-request (total monthly cost ÷ requests served) is the metric that catches architectures with superlinear cost curves — e.g. a per-request DB query that becomes the dominant cost at scale. Tracking CPR during design lets you reject architectures that are technically scalable but financially unviable, which is the failure mode that kills more startups than technical outages. A CPR that stays flat as traffic grows is the hallmark of a well-designed system.
When
During capacity planning and monthly thereafter. Takes 30 min to compute. Skip only for internal tools with no growth expectations.
How
1. Total monthly cost (from cost model or actual bill) 2. Total requests served (from analytics/CDN logs, p50 month) 3. CPR = total cost ÷ total requests 4. Compute CPR at 1x, 10x, 100x current load — does it stay flat? - If CPR rises, find the superlinear component (DB queries, egress, locks) 5. Set a CPR budget (e.g. "$0.002/req") and alert if actual exceeds it 6. Compare CPR across architectural alternatives — the flattest curve wins
Example
API serving 10M requests/mo, total cost $4,000/mo → CPR = $0.0004 At 10x (100M req): - Compute scales linearly: $40,000 - But DB connection pool saturates → added read replicas: +$8,000 - Egress 10x: +$18,000 - Total $66,000 → CPR = $0.00066 (rising — not flat) Diagnosis: egress + DB replicas are superlinear. Fix: add caching layer (Redis) → 70% of reads cached → CPR back to $0.00042.
Common Problems
- ⚠Computing CPR only at current load — it looks fine and you miss the superlinear component that bankrupts you at 10x.
Best Practices
- ✓Graph CPR vs load on a log-log plot — a flat line is the goal; any upward bend is a financial scaling bug.
- ✓Tie CPR to pricing — if your product charges $0.001/req and CPR is $0.0008, your margin is 20% and fragile; aim for 5x ratio.