27. Business Outcomes → Architecture: The Translation Layer

This is the section most guides skip, and it's what separates Staff+ and Principal-level answers from the rest.

27.1 The translation chain

Business outcome        →  Product metric        →  System requirement (SLO)    →  Architecture decision
───────────────────────────────────────────────────────────────────────────────────────────────────────────
Increase checkout          Conversion rate          Checkout p99 < 300 ms,         Inventory reads from cache,
revenue                                             99.99% availability            async fraud scoring with
                                                                                   fail-open for low-risk carts
Reduce churn of            Weekly active teams      Message delivery p99 < 500 ms, Persistent WebSocket gateway,
enterprise customers                                zero message loss              durable log before ACK,
                                                                                   per-tenant isolation (cells)
Enter EU market            Revenue from EU          Data residency, GDPR erasure   Region-pinned storage, tenant
                                                    ≤ 30 days                      → region routing, crypto-shredding
Cut infra cost 30%         Cost per order           Same SLOs at lower $/req       Tiered storage, right-sized
                                                                                   caches, spot for batch, kill
                                                                                   cross-region chatter (egress)
Ship features faster       Lead time, deploy freq   Independent deploys, safe      Service boundaries along team
                                                    rollback                       boundaries, feature flags,
                                                                                   contract tests

Every architectural choice on your whiteboard should trace back up one of these chains. If it doesn't, ask whether it belongs there.

27.2 Putting a number on latency and availability

Two widely cited data points: Amazon found that every 100 ms of added latency cost about 1% of sales, and Google found that half a second of extra search latency dropped traffic by about 20%. Exact numbers vary by product, but the direction is consistent: for consumer products, latency is revenue. For B2B platforms, the equivalent driver is usually availability, because of contractual SLAs.

Worked example: should we go multi-region?

Business: e-commerce site, $500M/year revenue online.
Revenue per minute (average)       = 500,000,000 / (365 * 24 * 60) ≈ $950/min
Peak-hour multiplier                ≈ 3x  → ~$2,850/min at peak

Current: single region, measured availability 99.9%
  → expected downtime ≈ 8.76 h/year ≈ 526 min/year
  → expected cost ≈ 526 min * ~$1,500/min (blended) ≈ $790k/year
     (+ unquantified: brand damage, support load, SLA credits)

Option A: multi-AZ hardening (already multi-AZ? then improve deploy safety)
  → target 99.95%: ~263 min/year → saves ~$395k/year; cost ~$150k/year
Option B: active-active multi-region
  → target 99.99%: ~53 min/year → saves ~$710k/year
  → cost: ~2x infra for the serving path (+$1.2M/year?), cross-region
     replication egress, 2-3 engineers for 2 quarters, permanent
     complexity (conflict handling, global consistency)

Conclusion: Option A first. Most outages come from bad deploys and
config changes, not region loss, so deploy safety (canaries, automated
rollback, cell-based rollout) buys more nines per dollar. Revisit B
when revenue or contractual SLAs justify it.

That conclusion, "most nines come from change management, not more hardware", is a Staff+-level insight. The arithmetic is how you defend it.

27.3 The cost of nines

Rule of thumb: each extra nine costs roughly an order of magnitude more in engineering effort. A strong senior candidate pushes back on "five nines" for anything that isn't money movement, identity/auth, or core infrastructure, because users can't tell 99.99% apart from 99.999% when their own ISP is at 99.9%.

27.4 Business levers and the architecture they imply

27.5 The five questions to ask about every component

When you add a box to the whiteboard, be ready to answer:

1. Why is it here? (Which requirement does it serve?)
2. What happens when it fails? (Blast radius, degradation mode)
3. How does it scale? (And what's the first bottleneck?)
4. What does it cost? (Roughly, and how does the cost grow?)
5. Who owns and operates it? (A team, a vendor, a managed service?)

27.6 🏗️ Flow: from business goal to a design decision

 ┌─────────────────┐   ┌──────────────────┐   ┌──────────────────────┐   ┌──────────────────────┐
 │ Business goal    │──▶│ Product metric    │──▶│ SLI + SLO + budget    │──▶│ Architecture options │
 │ "grow GMV 20%"   │   │ conversion, AOV   │   │ checkout p99<300ms    │   │ A / B / C            │
 └─────────────────┘   └──────────────────┘   │ avail 99.99%           │   └──────────┬───────────┘
                                               │ cost < $0.02/order     │              │
                                               └──────────────────────┘              ▼
 ┌──────────────────────────┐   ┌───────────────────────────┐   ┌─────────────────────────────┐
 │ Review loop: did metric   │◀──│ Ship behind flags, measure │◀──│ Decision record (ADR):       │
 │ move? did SLO hold? cost? │   │ A/B test + SLO dashboards  │   │ chosen option, trade-offs,   │
 └──────────────────────────┘   └───────────────────────────┘   │ one-way doors, revisit date  │
                                                                 └─────────────────────────────┘

The loop at the bottom matters. Architecture is a hypothesis about the business, and senior engineers and managers close the loop by checking whether the metric moved.

27.7 🌍 In production: business outcomes that shaped real architectures

Lesson from Slack: a product/business change can invalidate your partition key. When you choose a sharding key, ask the product team, "is there any feature on the roadmap that crosses this boundary?" That's a Staff+-level question.

27.8 ⚠️ Corner cases when translating requirements

• Averages hide the customers who matter. An overall p99 of 200 ms can hide p99 = 2 s for your largest enterprise tenant, whose queries touch 100× more data. Define SLOs per tier (free, pro, enterprise) or per critical journey.
• "Availability" depends on who measures it. Server-side success rate ignores DNS failures, TLS errors, CDN errors, and requests that never arrived. Use client-side or synthetic SLIs for the headline number.
• Requirements that conflict. Global search across all tenants vs strict EU data residency. Strong consistency vs < 50 ms writes from three continents. Surface the conflict and make the business choose; don't silently pick one.
• Hidden NFRs that show up after launch: deletability (GDPR erasure across backups, caches, logs, search indexes, ML training sets), auditability, explainability (why was this payment declined?), legal hold (which conflicts with deletion), and accessibility.
• Peak shape, not just peak size. A New Year's Eve messaging spike rises in seconds. A Black Friday spike is known weeks in advance. Autoscaling handles neither well; the first needs pre-provisioning, the second needs capacity reservations.
• Cost requirements change by stage. At a seed startup speed matters most, so unit cost can be high. A public company has margins under scrutiny, so unit cost is a board-level metric. Ask which stage you're designing for.