You run a communications API of Twilio's shape, whose customers' businesses stop when you are degraded. An enterprise customer wants a contractual per-endpoint p99 latency SLA written into their renewal. Walk me through your answer.

What the interviewer is testing

Whether you understand what an SLA commits an engineering organisation to for years, and whether you can decline one specific thing while satisfying the need behind it. A candidate who simply agrees has not thought about the second year, and one who simply refuses has not thought about the renewal.

The clarifying questions that change the answer

• Which endpoints, and what does the customer do with them? A p99 on "send a message" is a bounded unit of work. A p99 on "list everything matching this filter" is unbounded by construction and cannot carry a latency commitment at any price.
• Measured where? At your edge, or in their client? If it is their client you have just taken on their network, their DNS and their runtime.
• Does the endpoint's latency include work you do not control — a carrier accepting a message, a downstream provider, a customer-supplied webhook? Any endpoint whose duration includes a third party cannot carry a latency SLA, and saying so early is far cheaper than discovering it during a credit dispute.
• What is the remedy? Service credits of a few percent of monthly spend are ordinary. Consequential damages change the risk profile of the entire contract and are a decision for people who are not in this conversation.
• Is the underlying need latency, or predictability? Very often the customer was burned by an unannounced degradation and wants notification and credit, not a number.

A strong answer's arc

Commit to what you control. Availability and error rate at your edge, per endpoint class, are defensible and measurable.

Commit to latency narrowly. Only on endpoints with bounded, self-contained work, and only on the portion inside your boundary: from request receipt at the edge to response emission, with third-party acceptance explicitly excluded.

Write the measurement method into the contract. A p99 computed over a calendar month and a p99 computed over five-minute buckets and then aggregated are different promises, and the second is far harder to meet. State the percentile, the window, the aggregation and how excluded intervals are handled, before agreeing the number.

Offer what they actually want: per-account real-time status, proactive notification of degradation affecting their traffic, and a committed incident communication timeline. In many renewals this closes the issue without a latency clause existing at all.

Say plainly what you will not sign: anything measured at their client, anything including a third party, anything with consequential damages.

What it costs internally if you sign

Every SLA'd endpoint becomes a release gate, and the measurement must be per account, because an aggregate p99 does not evidence a per-customer commitment. It also forces isolation: one noisy tenant must not be able to spend another tenant's latency budget, which means per-tenant concurrency limits and sometimes dedicated capacity. That is a pricing conversation, and it should happen before the signature rather than after the first breach.

Common weak answers

• "We comfortably meet it today, so yes." Today's p99 is not a commitment across a year of product change, and the first miss converts a technical conversation into a legal one.
• "We do not do latency SLAs." True for some endpoints and not others; an undifferentiated no loses the deal and an undifferentiated yes loses money.

What a strong answer adds

The measurement is the contract. Two organisations measuring the same percentile at different points, over different windows, with different exclusion rules, will disagree about whether the SLA was met — and that disagreement is expensive, slow and unwinnable. Agree the method first. The number is the easy part.