Caching strategy for a fast front-end search

Question

I'd like to implement a fast, smooth search. Searched items are not that many: ~100 max. Each item holds the amount of data a facebook event would hold. They will all show up on initial load (maybe an infite scroll). Data won't change frequently. No more than 100 concurrent users.

What's the best caching strategy for search results, given above conditions?

What's the most scalable strategy?

Stack

• Frontend: Nuxt (VueJS) + InstantSearch (no Algolia!)
• Backend: Spring boot
• Dockerized

Possible solutions

1. Extra caching service on the backend (e.g. reddis, memcached) + make UI go to sever on each search operation. This would basically spam the backend on each keystroke
2. Load all items into local storage (e.g. Vuex) and search there directly. This will increase the app's memory footprint and may turn out messy overtime.
3. A combination of the two?

Answer 1

Load all results into local storage, and search in-memory.

100 items really isn't much in terms of memory footprint. To calculate this, let's assume that one of your events looks like this:

{
   "id": "0baa2cb6-6834-48c1-9e90-e2b8627a293c",
   "name": "some name",

   ... and some other fields
}

Assume 15 fields per event, 20 chars per key and 20 chars per value, that gets you to ~650 bytes/event. Multiple this by 100 events, and you get 65KB. That isn't much!

If the payload for one event is considerably larger than what was assumed above, trim it down before you store in memory. Only store the bare minimum needed to render a search result.