Section 7: Where the Design Bears Weight - Candidate-Driven Deep Dives

Executive Summary: This section covers the pivotal interview transition where the candidate chooses the deep-dive territory. We select the four areas where this design genuinely bears load — identity verification, consistency semantics, serverless cold starts, and failure containment — and dive into each with mechanism, working code, concrete numbers, and the interviewer pushback each one attracts. The section's reusable lesson: the choice of where to dive is scored as heavily as the diving, and the winning pattern for every dive is mechanism, number, trade-off.

Fifty minutes in, the dynamic of the room inverts. The interviewer caps their marker, leans back, and hands you the wheel: "Where would you like to go deeper?" Candidates underestimate this moment catastrophically. It is not a courtesy — it is the sharpest instrument in the interviewer's kit, because your choice of territory reveals what you believe actually matters in production. Wander into a low-stakes corner — bikeshedding JSON field names, polishing the CSS of the color input — and the signal reads Senior. Walk directly to the places where this system would genuinely fail at 2 a.m., and the signal reads Staff.

Key Insight: Every deep dive that follows lands with the same three-beat pattern — the mechanism (how it works, on the page), the number (what it costs or protects, measured), and the trade-off (what you accepted to get it). Carry that pattern into any interview, whatever the system; it is the difference between naming a concept and owning it.

For the color picker, four walls carry the load:

Deep Dive One: Identity - The Wall That Must Never Crack

Everything rests on one claim: the userId is real. A fast, durable, beautifully modeled system that serves user A's data to user B is simply a broken system with good manners. The mechanism is OIDC token validation, and it deserves code rather than hand-waving:

// Every request crosses this gate before any business logic runs.
// Public keys come from the provider's JWKS endpoint, cached and
// refreshed on rotation — validation is pure local cryptography.
async function verifyBearerToken(req: Request): Promise<Identity | null> {
    const token = extractBearer(req.headers.get("Authorization"));
    if (!token) return null;

    const claims = await jwtVerify(token, cachedProviderKeys, {
        issuer: "https://auth.internal.example.com",   // reject foreign mints
        audience: "color-picker-service",              // reject sibling-app tokens
        clockTolerance: 5,                             // seconds of expiry grace
    });
    if (!claims) {
        telemetry.warn("token_rejected", { reason: "signature_or_claims" });
        return null;                                   // caller answers 401
    }
    return { userId: claims.sub };                     // identity from sub — nowhere else
}

Four checks, in order, on every request: the signature proves the token was minted with the provider's private key and never altered; the issuer rejects tokens from another tenant; the audience rejects tokens minted for a different service — a real attack, replaying a valid token stolen from a careless sibling app; the expiry bounds a stolen token's blast radius to minutes. Cached keys make the whole gate cost well under a millisecond.

The Pushback: "Why not just accept a userId parameter? The frontend knows who's signed in."
Because the frontend is the user's software, not yours. Everything a client sends — headers, body, scriptable cookies — is attacker-controlled, so a client-supplied ID is an impersonation API: one curl with someone else's identifier and isolation evaporates. The signed token differs in kind, not degree: the client carries it but cannot mint or alter it without the provider's private key. Architectural Imperative: Trust boundaries are drawn where signatures are verified — never where parameters are parsed.