You will understand what caching is, why it exists, and how to add it to a Spring Boot service — so repeated work costs almost nothing.
Every time a user searches "binary tree questions" on EngineerPrep, the app runs the same pgvector similarity query, scores the same rows, and serializes the same JSON response. That work takes real time and real money — a Bedrock embedding call, a database round-trip, CPU to rank results. Do it a hundred times for the same query and you've paid a hundred times for the same answer. Your gut says "optimize the query." But a faster query still runs a hundred times. There's a simpler fix hiding in plain sight. The question this lesson answers: how do you make your app remember an answer so it never has to compute it twice?
A cache is a place that stores an answer so you can reuse it instead of computing it again. Think of a sticky note on your monitor. The first time your manager asks "what's the company Wi-Fi password?", you look it up in the IT portal, find it, and write it on the sticky note. The second time they ask, you just glance at the note. Same answer, zero effort. That sticky note is a cache. The IT portal is your database. In software, a cache is usually a fast in-memory store — meaning data lives in RAM, not on disk, so reads are much faster than going back to the original source. Here's the vocabulary you'll see everywhere: - Cache hit — the answer is already stored; return it immediately. - Cache miss — the answer isn't stored yet; do the real work, then save the result. - Cache key — the question you're asking (e.g. "binary tree questions" ). Each unique question gets its own slot.…
Step 1 — The very first request arrives. A user types "binary tree questions" and hits Search. The request lands in the QuestionSearchService . The service checks the cache: is there already an answer for this key? There isn't. This is a cache miss . The slot is empty. Step 2 — The real work happens. The service calls the pgvector query on PostgreSQL, ranks the results, and builds the response. This takes about 400 ms. The user sees their results. Step 3 — The answer is saved. Before returning the response, the service writes it into the cache under the key "binary tree questions" . Think of it as placing the sticky note on the monitor. The slot is now filled. Step 4 — The same request arrives again. A second user searches the exact same phrase. The request lands in QuestionSearchService . The service checks the cache. The slot is filled — this is a cache hit .…