AI-Assisted Coding: Add a Read-Through Cache for a Product GET API in an Existing Repo

This round uses an AI-assisted coding format. You receive an existing project repository and a written task: implement a read-through cache for a GET API so that serving it accesses `ProductRepository` less often. You work with an AI coding assistant, and at the end you explain your overall approach. The interviewer says almost nothing during the round, so you have to drive it yourself. The source does not describe the repository's language, framework, endpoints or data store. For practice, assume a typical layered service: an HTTP endpoint that returns one product by its ID calls a service method, which calls `ProductRepository`, backed by a database, on every request. The repository may also have methods that create, update or delete products. These details are illustrative; in the real round you would find them in the code. In the reported round, the candidate was told afterward that they should have understood the problem and its context better before prompting the assistant, and that the delivered solution did not solve the problem. Treat both points as central to what is being assessed. ### Clarifying Questions - Does the repository already contain a cache abstraction or a shared cache I should reuse, or is an in-process cache expected? - How stale may a product returned by the GET API be, and which code paths change products? - Does the service run as one instance or several? - Should repeated requests for a product that does not exist also avoid hitting the repository? - Is there a memory limit, or an expected number of distinct products? - Is there an existing test suite, and a way to run the service locally? ### Part 1 — Understand the problem and the codebase before prompting Before asking the assistant to write any code, what do you read, run and decide? Describe how you locate the GET path through the code, what you check about how its objects are created and shared, and how you turn what you learned into a prompt, or a sequence of prompts, that the assistant can carry out correctly. ```hint Follow one request Trace a single GET request from the route to the repository call, and note which of the objects along the way live for one request and which live for the whole process. ``` #### What This Part Should Cover - Reading the task and the relevant code path before prompting - A way to observe the problem before changing anything - Write paths and object lifetimes that affect caching - Prompts that carry the context and constraints the assistant needs ### Part 2 — Implement the read-through cache Implement the cache. Decide where it sits relative to `ProductRepository` and the service, what the cache key is, how entries expire or are evicted, what happens when a product changes, how missing products and repository errors are handled, and what happens when many requests for the same uncached product arrive at once. ```hint Who needs to know Decide which single layer should know that a cache exists, and which layers should not have to change at all. ``` #### What This Part Should Cover - Placement of the cache and how it is wired into the application - Read-through behavior, key design, expiry and a size bound - Consistency with writes, and handling of not-found results and errors - Thread safety and concurrent misses for the same key ### Part 3 — Prove it works and explain the approach Show that the change actually reduces repository access for the GET API without changing its behavior, then explain your overall approach to the interviewer. ```hint Evidence over assertion Decide which observable number should change because of your work, and measure it through the same entry point a real request uses. ``` #### What This Part Should Cover - Tests that go through the real GET path and count repository calls - Tests for expiry, invalidation and concurrent requests - A clear explanation of the design, its trade-offs and its limits ### What a Strong Answer Covers - Understanding before prompting, and prompts grounded in the actual code - Critical review of the assistant's changes instead of accepting them as written - A cache that measurably solves the stated problem through the real request path - Correct consistency, eviction and concurrency behavior, with the trade-offs named - A concise, structured explanation at the end ### Follow-up Questions - The service now runs as several instances. What goes wrong with your cache, and how would you fix it? - A product's price changes in the database without going through this service. How stale can the API become, and what would you do about it? - How would you monitor the cache in production, and what hit rate would make you question whether it is worth keeping? - The assistant proposes caching the whole HTTP response instead. When is that better or worse than your design?