Availability & SLAs

The problem

Adda went dark for 20 minutes last Tuesday. In the incident review, someone finally asks the only question that matters: "Was that bad?" Marketing thinks any downtime at all is a catastrophe — millions of people now open Adda the way they open a light switch. Tanvir, who caught the 3am page, thinks 20 minutes to recover a wedged database is honestly a miracle. Fahim, still user #1, just wants to know if it'll happen again tonight. Nobody can agree, because nobody ever wrote down what "good enough" means.

That's the night Ria hires Mou — Adda's first real SRE. Mou listens to the whole argument, then says the thing that reframes the room: without a number, every outage is just a shouting match. You can't tell whether to spend six months making Adda bulletproof or whether you're already gold-plating. Reliability work has no finish line until someone draws one — and drawing it is now Mou's job.

A first attempt

The room's instinct is "let's aim for 100% uptime." It sounds responsible. Mou has seen it burn a team before.

The last stretch of reliability is astronomically expensive. Going from Adda's one server to two doubled availability cheaply. Going from 99.9% to 99.99% means redundant data centers, automatic failover, chaos testing, and a follow-the-sun on-call rotation covering every timezone Adda now lives in. Each extra "nine" roughly multiplies cost and complexity while removing an order of magnitude less downtime. Chasing 100% spends infinite money to erase a finite, shrinking risk — and no budget on Earth stops a backhoe from cutting a fiber line outside the data center.

So "as available as possible" isn't a target Mou will accept. It's a way to burn Adda's runway forever.

The insight

Availability is a business decision expressed as a number, not an engineering ideal. Mou's rule: pick a target that matches what Adda's users actually need, promise it, measure it, and spend exactly enough to hit it — not one taka more.

That number is usually written in "nines." Here is what each nine buys you, as allowed downtime:

Notice the jump Mou circles on the whiteboard: three nines gives Adda 43 minutes a month to deploy, restart, and recover. Four nines gives barely 4 minutes — a single bad deploy blows the whole budget.

How it works

Mou introduces three acronyms that turn the target into something the team can operate against.

The relationship between the three, and where the error budget sits:

        stricter  ──────────────────────────►  looser
        SLI target        SLO           SLA
   e.g. 99.95% measured │ 99.9% goal │ 99.5% promised
        │               │            │
   ─────┴───────────────┴────────────┴──────────── 100%
        └─ engineering ─┘└─ margin ──┘
              ▲
        error budget = 100% − SLO = 43 min / month

Adda's real numbers

Adda's API now does 10,000 requests per second. That's about 25.9 billion requests a month passing through Mou's watch.

• A 99.9% SLO means Adda is allowed to fail 0.1% of them: ~25.9 million failed requests, or about 43 minutes of total outage-equivalent.
• Tighten to 99.99% and that budget shrinks 10x to ~4.3 minutes. One 6-minute deploy hiccup and the month is already broken.
• A single dependency at 99.9% caps Adda's ceiling: chain three independent services at 99.9% each and the theoretical max is 0.999³ ≈ 99.7%. Dependencies multiply, so Adda's own target must account for everyone it calls — the payment provider, the notification service, all of it.

When to use it

Practice

Recap

• Availability is a business number, not an ideal — Mou picks a target that matches user need and stops there.
• SLI = what you measure, SLO = your stricter internal goal, SLA = the looser external promise with penalties.
• The error budget (100% − SLO) is downtime you're allowed to spend; it turns "ship vs. stabilize" into a math problem instead of an argument.