The Scenario:

You've shipped a RAG-based support chatbot. It works fine in testing. Two weeks after launch, it's live for 50,000 users.

One night, latency spikes from 800ms to 11 seconds. Users are abandoning mid-conversation. Your vector DB is healthy. Your LLM provider status page shows no incidents.

You have 15 minutes before your manager pings you on Slack. Walk me through exactly what you check, in order, and why.

The Answer:

Most candidates freeze here not from lack of knowledge, but because they've never been trained to think in this order.

1. Isolate the layer first. Check retrieval latency and generation latency separately. If retrieval is fast but generation is slow, it's not your vector DB.

2. Rule out the boring stuff before the exotic stuff. Cold cache after a deploy? Autoscaler lagging behind a traffic spike? A cron job or batch ingestion job hammering the same DB? These cause most "mystery" spikes.

3. Check for silent throttling. LLM providers often rate-limit per-token or per-org without a status page incident. Look at response headers, not just the status page.

4. Check for one noisy neighbor. Is one tenant, one query pattern, or one runaway retry loop eating shared capacity? A single misbehaving client can look like a global outage.

5. Check what changed in the last 24 hours. New prompt version, new embedding model, new chunk size, a config push, most incidents trace back to something that shipped recently.

6. Only then, suspect the vector DB or LLM provider itself. In most real incidents, the bug is on your side of the fence.

That order, isolate, rule out the boring, check for throttling, check for noisy neighbors, check recent changes, then suspect the vendor, is what interviewers are actually listening for. Not the right answer. The right sequence.