Two architectures, same traffic, 30× the bill
Monday, 10:00: two designs for the new availability service land on Karim's desk. Both handle 2,000 requests a second. One costs €6k a month, the other €48k.
Two designs can serve the same traffic, one at about €6,000 a month and one at €48,000. Neither is wrong. Here's how to choose.
- Problem
Two proposals serve the same 300 requests per second. One costs €1,000 a month, the other €30,000. Both teams say theirs is 'the right architecture'.
- Why the simple system fails
Copying a big company's architecture buys capabilities you don't need yet. Picking the cheapest one can quietly under-buy availability or latency your business depends on.
- Engineering concept
Every component buys a capability (availability, latency, isolation, team autonomy). Price each capability and compare it with what its absence would cost the business.
- Technology
Single-region managed stack vs multi-region Kubernetes with microservices, Kafka and a service mesh; expected-downtime cost; cost-per-request modelling.
- Trade-offs
The cheap design risks outages, slow global latency and team bottlenecks later. The expensive one risks burning runway and engineering time on problems you don't have.
The problem
2 min- Karim · CTODesign A: €6k a month. Design B: €48k. Both handle 2,000 req/s. I need a reason for every euro.
- Omar · On-call SREB runs in three regions at once. If Frankfurt goes down, it doesn't care.
- You · Engineer at StayHubSo B is the more professional design?
The big idea
4 minBuy capabilities, not architectures: price each one against what its absence costs you.
A small guesthouse hands out candles twice a year; a 900-room airport hotel runs diesel generators, because one dark hour strands hundreds of guests. Neither wastes money. Design B is a generator.
How it works
5 min- 1List the capabilities
A capability is something one design can do and another can't. B buys region survival, low latency far away, team independence and 30× headroom. Not throughput: A already handles 2,000 req/s.
- 2Translate targets into minutes
An availability target is the share of time a service works. 99.9% ≈ 43 min down a month; 99.99% ≈ 4.3. B saves about 39 minutes.
- 3Price an outage minute
StayHub earns ~€14M commission a month ≈ €320 a minute. Without the availability service, bookings stop: about €300 per minute.
- 4Compute the break-even
Break-even: where the extra spend equals the losses it prevents. €42k ÷ 39 min ≈ €1,080/min. Add B's 2 platform engineers (vs A's 0.3): ≈ €1,500/min. We're at €300.
- 5Price the other capabilities
Singapore guests (8% of bookings) wait 1.4 s for search: a real cost. 7 teams aren't blocked on deploys. Traffic grows ~70% a year, not 30×.
- 6Buy only what pays
Each capability can be bought alone. Keep the cheap design evolvable ( servers, clean modules) so the next purchase is a project, not a rewrite.
Watch a decision being made
4 minYou price Design B, Lina checks
Karim wants a recommendation: Design A (€6k/month) or Design B (€48k/month), both at 2,000 req/s.
- 1Count the whole cost
Infra €42k extra, plus two platform engineers (€20k) minus A's 0.3 engineer (€3k).
pythonextra = (48_000 - 6_000) + (20_000 - 3_000) # infra + people minutes_saved = 43.2 - 4.3 print(extra / minutes_saved) # ≈ 1,517 €/minWhy: Leaving people out makes B look about 30% cheaper than it really is.
- 2Compare with the real outage cost
€1,500 break-even vs €300 per minute: on availability, B doesn't pay for itself yet.
Why: Without the outage-minute number, "more nines" always sounds better.
- 3Buy one capability
Recommend A plus a read replica and app servers in Singapore (+€5k/month). Searches read locally; bookings still write to Frankfurt.
Why: It fixes the one measured pain for about a tenth of B's extra cost.
- 4Write the triggers down
Revisit when an outage minute costs more than ~€1,000, more than 10 teams contend for deploys, or Asia passes 25% of bookings.
Why: A written trigger turns "someday" into a decision that happens on time.
In real life
3 minNetflix: many services, many regions
- Has publicly described hundreds of microservices across several regions, able to shift traffic away from a failing one
- Thousands of engineers who must ship independently
Fits when a region outage is very costly and many teams need autonomy.
Prime Video monitoring: back to one service
- Publicly described (2023) merging a distributed pipeline into a single service
- Reported cutting that pipeline's infrastructure cost by about 90%
Fits when a workload doesn't need what it's paying for.
What goes wrong
3 minYou pay their bill without their outage cost or team count.
Start from your numbers: outage cost per minute, latency per region, teams, growth.
Each extra nine costs more and saves fewer minutes.
Stop where the next nine stops paying for itself.
Every write is copied and stored in each region.
Price writes, replicate only what must be global, .
Trade-offs
3 min| Option | Total per month | Fits when | Main risk |
|---|---|---|---|
| A: lean, one region | ~€9k with people | Affordable outage minutes, small team | A region outage means downtime |
| A + one capability | ~€14k with people | One measured pressure (Singapore latency) | Upgrading too late if nobody watches triggers |
| B: multi-region | ~€68k with people | Outage minute above break-even, global guests, many teams | Cost, a platform team, partial failures |
- Omar · On-call SREI'm the one paged when Frankfurt goes down. Region outages happen. I want B.
- Karim · CTO€42k a month plus two hires to save €12k of outages? That's about €700k a year.
- Omar · On-call SREAnd if the outage lands on a Saturday in August, it's not €300 a minute.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- The requirements in numbers before any design: availability, latency per region, 2,000 req/s. An agent asked to "design it properly" designs for requirements nobody set.
- What an outage minute is worth: ~€300 here. B pays off only above ~€1,500 with people.
- What counts in the cost: the invoice and the people to run it.
We're designing the availability service (about 2,000 req/s at peak). No code yet. Write docs/adr/availability-service.md comparing A (Frankfurt, 2 zones, managed Postgres with standby, Redis) and B (active-active in Frankfurt, Virginia and Singapore). For each: monthly cloud cost by line item, people time, availability and downtime minutes, search latency for EU and Singapore. Use €300 per outage minute, compute the break-even, and list revisit triggers. Mark each number quoted, measured or assumed.
- Redo the break-even: €42k ÷ ~39 minutes ≈ €1,080 a minute, far above our ~€300.
- People time is in the total, not just the invoice.
- Every expensive component in B maps to a capability; unmapped ones are candidates to drop.
- It recommends B as "more scalable" or "best practice", with no cost per outage minute.
- It treats "we might grow" as a reason to buy every capability now.
- It moves booking writes to Singapore to fix slow searches there.
Check yourself
2 minNext episode: the AI concierge pilot goes live in Lisbon, and its first week of model calls costs €5,040, a pace that would cost more each month than the availability service.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Interactive simulation, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Downtime per month at each target (30-day month): 99.9% → ~43 min, 99.95% → ~22 min, 99.99% → ~4.3 min. Each extra nine costs more than the last, and saves fewer minutes.
You price Design B, Lina checks
Karim wants a recommendation for the availability service: Design A (€6k/month) or Design B (€48k/month), both at 2,000 req/s. This time you lead; Lina checks each step.
- 1List what B buys
Region survival, low latency for far-away guests, team independence, 30× headroom. Throughput is not on the list: A already handles 2,000 req/s.
Why: You can't price a design as a package. Each capability has its own value, and you may need only one.
- 2Price an outage minute
StayHub earns ~€14M commission a month ≈ €320/min. Without the availability service, searches show no rooms and bookings stop, so a minute costs about €300 (a few guests come back later).
Why: Every availability decision hangs on this number. Without it, "more nines" always sounds better.
- 3Compute the break-even
B saves ~39 min/month (43 → 4.3). Extra infra €42k ÷ 39 ≈ €1,080/min. Add two platform engineers (€20k) minus A's 0.3 engineer (€3k): €59k ÷ 39 ≈ €1,500/min.
pythonextra = (48_000 - 6_000) + (20_000 - 3_000) # infra + people minutes_saved = 43.2 - 4.3 print(extra / minutes_saved) # ≈ 1,517 €/minWhy: Leaving people out makes B look about 30% cheaper than it really is.
- 4Price the other capabilities
Singapore guests (8% of bookings) wait 1.4 s for search: a real cost. Team independence: we have 7 teams (~40 engineers), nobody is blocked. Headroom: traffic grows ~70% a year, not 30×.
Why: One capability might be worth buying even when the whole package isn't.
- 5Buy one capability
Recommend A plus a read replica and app servers in Singapore (+€5k/month). Searches read locally; bookings still write to Frankfurt.
Why: It fixes the one measured pain for about a tenth of B's extra cost.
- 6Write the triggers down
Revisit when an outage minute costs more than ~€1,000, when more than 10 teams contend for deploys, or when Asia passes 25% of bookings.
Why: The context will change. A written trigger turns "we should revisit someday" into a decision that happens on time.
| Line item | A (€/month) | B (€/month) | What B buys with the difference |
|---|---|---|---|
| Compute | 1,500 | 17,000 | 3 regions, each with headroom to absorb a failed neighbour; mesh sidecars |
| Database | 2,800 | 15,000 | Multi-region replication, survives region loss |
| Messaging | 300 | 6,000 | Durable event log between many services |
| Observability | 600 | 7,000 | Tracing every hop across services and regions |
| Transfer, misc | 800 | 3,000 | Cross-region replication traffic, global routing |
| Total | ~6,000 | ~48,000 | |
| People (not on the bill) | ~0.3 engineer | 2 platform engineers | Operating the above |
Interactive simulation
Visual diagram
A smaller example than StayHub's: a young booking site at 300 req/s. Top: Architecture A (~€1k/month). Bottom: Architecture B (~€30k/month). Same traffic. Walk through where the money goes.
Analogy
- Hotels and backup powerGuesthouse relies on the gridArchitecture choicesDesign A: simple and cheap
- Hotels and backup powerCandles and an apology twice a yearArchitecture choicesRare outages you can afford
- Hotels and backup powerAirport hotel with diesel generatorsArchitecture choicesDesign B: multi-region protection
- Hotels and backup powerOne dark hour strands hundredsArchitecture choicesOutages that cost a fortune
- Hotels and backup powerEach buys the insurance its risk needsArchitecture choicesMatch the design to the context
Where the analogy breaks: a generator is easy to add later. Some architecture choices are much harder to change, so keep the simple design easy to grow.
Check your understanding
Practice ladder
Run the model at a different outage cost
Estimation Warm-upUse Lina's model: monthly cost = infra + people + (1 − availability) × 43,200 min × €/min.
- Design A: infra €6k, people €3k, 99.9%
- Design B: infra €48k, people €20k, 99.99%
It's peak season and Maya estimates an outage minute now costs €2,000 (packed weekends, partner penalties). Trace the model for both designs and say which one wins this month.
Finish the decision record
Decision PracticeLina's decision record for the availability service has two gaps. Fill in Options/trade-offs and Triggers.
- Problem: pick a design for the availability service (2,000 req/s).
- Requirements: search p95 < 500 ms in the EU and Asia; bookings must not be lost.
- Facts: A €6k + 0.3 engineer, 99.9%. B €48k + 2 engineers, 99.99%. Outage minute ≈ €300. Singapore search 1.4 s (8% of bookings). 7 teams (~40 engineers).
- Options and trade-offs: ___
- Decision: A + read replica and app servers in Singapore.
- Triggers to revisit: ___
The reviews service
Design PracticeThe reviews service shows guest reviews on hotel pages (read-heavy: 3,000 reads/s, 20 writes/s). The team proposes moving it to 3 regions active-active with a multi-region database, €22k/month, "so it never goes down". Today it runs in Frankfurt for €2.5k/month.
Facts: if reviews are missing, the hotel page still loads and guests can still book; Omar's data shows conversion drops by about 2% while reviews are missing. Reviews go down about 2 hours a year. Pages already show reviews from a CDN copy up to 10 minutes old.
Decide what to do, with numbers.
A region for Brazil?
Decision StretchMaya: "We launch in Brazil next quarter. Guests in São Paulo see 1.6 s searches today. Can we have a full StayHub region there?"
Facts: - A full region (app servers, database replica, search, cache) ≈ €35k/month plus ongoing on-call. - A read path only (app servers + read replica for search) ≈ €6k/month. - Brazil is forecast at 5% of bookings in year one. Bookings (writes) can go to Frankfurt (~200 ms each way). - No data-residency rule requires Brazilian data to stay in Brazil (legal checked).
Write a short decision: "We chose X over Y because…, accepting the risk of…", plus one trigger to revisit.
Explain it yourself
Your team must choose between a €6k/month and a €48k/month architecture for the same traffic. Explain how you'd decide, without saying either is 'better'.