## Interview Prompt You inherit a web ticketing backend whose tests reveal incorrect REST behavior, stale cached availability, and broken pagination. Walk through how you would diagnose the failures and repair the API. Cover resource modeling, status codes, cache invalidation, deterministic pagination, concurrency around ticket sales, and a test strategy that lets you isolate failures instead of rerunning an opaque full suite. ### Constraints & Assumptions - Clients may retry create and update requests. - Inventory changes concurrently while users browse paginated listings. - Cached reads may lag briefly, but a purchase must never oversell inventory. - The existing implementation can be changed incrementally rather than rewritten wholesale. ### Clarifying Questions to Ask - Which endpoint or invariant fails first in a minimal reproduction? - Is pagination offset-based or cursor-based, and what ordering is promised? - Which data is authoritative when cache and database disagree? ### What a Strong Answer Covers - A reproducible debugging sequence using logs, focused tests, and invariant checks. - Correct distinctions among POST, PUT, and PATCH plus idempotency behavior. - Database-enforced inventory correctness with cache treated as an acceleration layer. - Stable pagination ordering and cursor design that tolerates concurrent inserts. - Regression tests for retries, stale cache, page boundaries, and race conditions. ### Follow-up Questions - How would you detect a cache-invalidation event that was lost? - What changes if a customer can hold a ticket for five minutes before payment? - How would you preserve API compatibility while correcting an ambiguous response shape?