Skip to content
Course contents

Practice

Questions where the answer is a judgement, not a return value. Try each one properly before opening the worked answer — the gap between your reasoning and the answer is the useful part.

3 questions

  1. 01core

    A product manager asks for "sub-second page loads." Turn that into an SLO an engineer could be held to, and explain what each clause is doing.

    The request is unfalsifiable as stated. Sub-second for whom, measured where, over what period, and for which pages? Write the version you would put in a document, then justify every part of it.

    Show a worked answer

    A defensible version:

    99% of GET /orders responses complete within 800ms, measured at the edge load balancer, over a rolling 28-day window, excluding requests that return 4xx.

    Clause by clause:

    • 99%, not “all”. An absolute guarantee has no error budget, so any single slow request is a breach and the objective becomes something everyone agrees to ignore. A percentile makes the target survivable and therefore real.
    • 800ms, not one second. The stated goal is the user’s experience, which includes their network and render time. Budgeting the whole second at the server leaves nothing for the parts you do not control.
    • GET /orders, not “page loads”. Different endpoints have genuinely different costs. One number across all of them will be dominated by whichever is busiest and will say nothing useful about any of them.
    • At the edge load balancer. Names where the clock starts and stops. Server timings exclude your own queueing, which is exactly the part that degrades first under load.
    • Rolling 28 days. Long enough that one bad afternoon does not condemn the quarter, short enough that a bad month cannot hide behind a good one. Rolling rather than calendar avoids the reset that makes the first of the month a free-for-all.
    • Excluding 4xx. A client sending malformed requests should not consume your reliability budget. Note this cuts both ways: excluding 5xx would let you meet the SLO by failing fast, so those stay in.

    A weaker but still acceptable answer names a percentile, a threshold, and a measurement point. An answer without all three cannot be checked.

  2. 02core

    A team-chat product stores messages in channels. Reads dominate writes 40:1. Which load parameter would you plan against, and what would you need to measure to be sure?

    Name the number whose doubling would force a design change, and say what you would measure to confirm it is the right one.

    Show a worked answer

    The tempting answer is the read:write ratio, and it is the wrong one. 40:1 tells you reads matter more than writes; it does not tell you what makes any single read expensive.

    The parameter that actually governs the design is the number of members in the largest channels, together with message volume in those channels, because those two decide the cost of the fan-out on every message.

    • A 12-person channel is cheap under any design.
    • A 30,000-person company-wide announcement channel is a different system: one message means 30,000 unread counters to update, 30,000 potential push notifications, and 30,000 clients holding a live connection that must be told.

    To confirm it, measure the distribution of channel membership, not the mean: p50, p99, and the maximum. Then measure messages per second in the top ten channels specifically. If the top of that distribution is far from the middle, the design has to be bimodal — cheap fan-out for ordinary channels, something else for the large ones — exactly as social feeds do for celebrity accounts.

    A secondary parameter worth naming: concurrent connections per channel, since live delivery cost scales with connected members rather than total members.

    The answer to reject is any single average. “The average channel has 23 members” is true and useless: it describes none of the channels that will break you.

  3. 03warmup

    A deploy at 14:05 raised the error rate to 100% on one endpoint. Rollback at 14:40 fixed it. The change had passed review and CI. Where is the fault, and what would you change?

    Say which category of fault this is, then name what you would change so the next one costs five minutes instead of thirty-five.

    Show a worked answer

    The fault is a software fault, delivered by a human process — and the failure is an operability failure.

    Separating those three is the exercise:

    • The fault is a bug in the deployed code. It is systematic: every instance had it, which is why the error rate went to 100% rather than to a third.
    • The trigger was a human process that let it reach production. Review and CI passed, so the useful question is what they do not cover — most often, the behaviour only appears against production-shaped data or config.
    • The failure — thirty-five minutes of a broken endpoint — is mostly about detection and recovery, not about the bug. A bug that reaches production and is rolled back in ninety seconds is a non-event.

    What to change, roughly in order of value:

    1. Detection. Thirty-five minutes suggests a human noticed rather than an alert. An error-rate alert per endpoint, tied to deploys, turns this into minutes.
    2. Automatic rollback on a deploy-scoped error spike. The machine is faster than the on-call engineer, and this failure shape — fine before 14:05, broken after — is the easiest one to detect automatically.
    3. Progressive delivery. Ship to 5% of traffic first. The same bug then costs 5% of one endpoint for two minutes.
    4. Ask what CI could not see. If the bug needed production data shape or config to appear, that gap is the real finding, and it will produce the next incident too.

    The answer to avoid is “the engineer should have tested more carefully.” It ends the investigation one step early and leaves every part of the system that allowed a 35-minute outage exactly as it was.