# Harden a URL-Caching HTTP Service for Production You inherit a working HTTP service that accepts URL-related requests and keeps cached URL records in process memory. The core happy path exists, but the service needs production hardening. Explain how you would evolve it in two safe iterations. Cover global exception handling, correct HTTP 400 and 500 behavior, telemetry for business and infrastructure signals, API versioning, and replacing process-local cached state with a shared cache or durable database when scale requires it. Do not invent business behavior that is not part of the existing contract; focus on engineering boundaries and migration. ### Clarifying Questions to Ask - Which validation failures are client errors, and which domain conflicts have separate status codes? - Must cached URL records survive restart? - Is the cache an optimization or the only source of truth? - Which clients must remain compatible during version changes? - What sensitive data may appear in URLs and logs? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would you prevent cache stampedes? - When should a 404, 409, 422, or 503 be used? - How would you migrate keys without taking the service offline? - Which metric labels could create dangerous cardinality?