Section 10: Pulling on Every Thread - Interviewer Deep-Dive Challenges

Executive Summary: The design is on the board and Sections 8 and 9 have defended search and trust. Now come seven escalations: a listing missing from search, an indexer half an hour behind, a 10x Sunday spike in one city, "why not just PostGIS", an attacker hunting a seller's home, scammers who adapt, and a listing that goes viral. Each gets mechanism, number and trade-off, then the senior line. Most answers leave the architecture alone.

The interviewer leans back. "The board's working. Now let's make Sunday night go badly." Each checks whether your numbers and decisions survive an incident.

Challenge 1: "My listing isn't in search"

"Maya posted ten minutes ago. Daniel can't find the bike. Support has the ticket. Walk me through it."

What they're really asking: Can you debug your own consistency model, or do you just say "eventual consistency" and stop there?

Start with the contract. Maya's own views read from Postgres, so the listing appeared for Maya the moment it was posted. Search promises p95 under 60 seconds from publish, so ten minutes is well past the SLO. Triage runs cheapest check first:

The most likely answer is the dullest one. About 2% of new listings are held for human review, around 40K a day, and a held listing stays pending_review until someone looks at it. Maya's app should already say "Under review." If it's active, check pipeline lag, then compare the Elasticsearch document's version with the row's. Last, rerun Daniel's query: maybe the bike is on page three.

The senior line: "Read-your-writes means Maya sees the listing's real status. 'Not in search' is a question about status, lag or version, and each one has a metric I can check before I touch any code."

Quick check before moving on: