Caching and Redis Interview Questions

What should you prepare for Caching and Redis interviews?

Where should I start?

Start with cache design, which appeared in 26 of 114 interviews. Questions cover more than what Redis is. Check whether you can describe where you would use a cache and how you would manage its data.

• Can you explain when caching is worth using and when you would choose Redis?
• Which Redis data structures and commands would you use?
• What would your cache keys contain, and how would you fill the cache?
• When would entries expire, and what would happen after a database update?
• How would you test invalidation and keep protected content away from unauthorized users?

What code should I be ready to write?

Coding tasks appeared in 7 of 114 interviews. The LRU cache task with O(1) get and put operations appeared in 5 of 114 interviews. Can you build it with a hash map and a linked list, rather than just name those structures?

• What does your getter do when it retrieves an entry?
• How does put handle an existing key?
• What happens at the capacity limit, and how do you update the linked list?
• How would you make an in-memory cache thread-safe?

Also check whether you can code an application cache for repeated requests with the same input and output. This was another task in these interviews.

What should I check for frontend or mobile work?

Frontend and mobile caching appeared in 22 of 114 interviews. Check client caching as well as Redis.

Can you avoid duplicate requests, explain GraphQL normalization, and describe when a framework revalidates cached data? For mobile apps, can you handle offline data and image caching?

For HTTP caching, can you identify cacheable requests and explain Cache-Control and ETag? Can you trace stale content through browser caches and CDNs after an asset update or deployment rollback?

How would I check a cache in production?

Can you verify that caching works and say how you would measure its effectiveness? Check whether you can size resources, diagnose Redis memory pressure, and prevent cache stampedes. If Redis fails, how would you recover it or fill it again?

For distributed design, choose a use case covered in these interviews: sessions, rate limiting, idempotency, likes, chat, or messaging. What would Redis do in that design? If data changes across services, how would you keep those updates reliable?

Who gets asked Caching and Redis

The 20 most asked Caching and Redis questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. What is Redis, and how would you use it in an application?

   Asked in 5 of 114 interviews · last asked Oct 12 · Tooling · Junior

   Show answer

   Redis is a fast, in-memory data store that supports structures like strings, hashes, and lists. I would use it to cache frequently read data, store sessions, or track rate limits. For caching, the application checks Redis first, reads the database on a miss, and caches the result with an expiry time.

   • Caching reduces database work and response time, but cached data can become stale.
   • Set expiry times and update or remove cached values when source data changes.
   • Redis can persist data to disk, but durability depends on configuration.
   • Plan for memory limits and Redis failures; a cache should not be the only copy of important data.

   What the interviewer checks: The interviewer checks whether you understand Redis, its common uses, and basic cache trade-offs.

   Other ways it was asked

   • “How can Redis be used in an application?”
   • “What is Redis, and how is it used in networked applications?”
   • “What is Redis, and why do we need to use it in our application?”

2. How would you design and implement application caching, and when would you use Redis?

   Asked in 5 of 114 interviews · last asked Oct 12 · Concept · Mid-level

   Show answer

   I would cache frequently read data that is slow to fetch and can tolerate some staleness. With cache-aside, the app checks the cache, then loads and caches missing data with a TTL. I would invalidate affected entries after writes. I would use Redis when multiple app instances need a shared, fast cache.

   • Choose cache keys that include relevant user, tenant, and query details to prevent incorrect results or data leaks.
   • Set TTLs based on acceptable staleness, and limit memory use with an eviction policy.
   • Handle cache failures safely, and prevent many requests from rebuilding the same missing entry at once.
   • Measure cache hit rate, response time, and database load to check whether caching helps.

   What the interviewer checks: The interviewer checks whether you can improve speed while managing stale data, shared access, and cache failures.

   Other ways it was asked

   • “How would you implement caching in an application, and when would you use it?”
   • “How would you implement caching in an application?”
   • “How would you design a caching strategy, including how you would use Redis?”

3. How would you implement an LRU cache with O(1) get and put operations?

   Asked in 5 of 114 interviews · last asked Sep 10 · Write code · Mid-level

   Show answer

   Use a hash map and a doubly linked list. The map finds entries, and the list tracks which entry was used least recently. Each successful get or put moves the entry to the most recent end; when full, inserting a new key evicts the least recent entry. Operations take O(1) average time because hash lookups are average O(1).

   • Each cached key maps to exactly one list node; cache size never exceeds capacity.
   • Successful reads and updates both refresh recency.
   • List moves and removals take O(1); space usage is O(capacity).
   • Python's OrderedDict supports this design; the example returns -1 for misses and handles zero capacity.

   PythonCopy

   from collections import OrderedDict
   class LRUCache:
       def __init__(self, capacity): self.capacity, self.items = max(0, capacity), OrderedDict()
       def get(self, key):
           if key not in self.items: return -1
           self.items.move_to_end(key)
           return self.items[key]
       def put(self, key, value):
           self.items[key] = value; self.items.move_to_end(key)
           if len(self.items) > self.capacity: self.items.popitem(last=False)

   What the interviewer checks: The interviewer checks whether you can combine fast lookup with correct recency tracking and eviction without scanning entries.

   Other ways it was asked

   • “How would you design and implement an LRU cache?”
   • “Design and implement an LRU cache with get(key) and put(key, value) operations.”
   • “Design an LRU cache with get(key) and put(key, value) operations that run in O(1) time.”

4. What is caching, and where is it used in an application?

   Asked in 4 of 114 interviews · last asked Oct 12 · Concept · Junior

   Show answer

   Caching stores a copy of data or a computed result so later requests can reuse it faster. Applications use caches in browsers, CDNs, application memory, or shared stores like Redis. A cache hit returns the saved value; a cache miss requires fetching or computing it. Cached data can become stale, so it needs expiration or updates.

   • Use caching for frequently read data or expensive work that can be reused.
   • Caching reduces response time and load on databases or other services.
   • Caches use extra storage and need rules for keeping data fresh.

   What the interviewer checks: The interviewer checks whether you understand cache hits, cache misses, common cache locations, and the risk of stale data.

   Other ways it was asked

   • “What is caching, and how does it work?”
   • “What is caching, and when would you use it?”
   • “What is caching?”

5. How would you keep cached data synchronized with database updates?

   Asked in 3 of 114 interviews · last asked Oct 14 · Scenario · Mid-level

   Show answer

   I would update the database first, then delete the affected cache entries after the transaction commits. The next read would load fresh data from the database and cache it again. I would also set a TTL and retry failed cache deletions, because database writes and cache changes are not one atomic operation.

   • Invalidate every affected cache entry, including cached lists or search results.
   • Use reliable retries or durable update events if cache deletion fails.
   • Concurrent reads can cache old data again; invalidation alone does not guarantee consistency.
   • TTL limits staleness, but does not make updates immediately visible.

   What the interviewer checks: The interviewer checks whether you handle normal updates, failed invalidation, and races without promising perfect consistency.

   Other ways it was asked

   • “How would you keep a cache synchronized with a database?”
   • “What should happen if a student's name changes in the database while a caching layer still contains the old name?”
   • “If you add a cache like Redis in front of the database for get user by ID, what rules would you use to keep cached data from going stale after updates?”

6. How would you verify that caching works and measure its effectiveness?

   Asked in 3 of 114 interviews · last asked Sep 22 · Scenario · Mid-level

   Show answer

   I would test cache misses, hits, expiry, and invalidation, and check that returned data is correct. Then I would compare realistic workloads with and without caching. I would track hit rate, request latency, database load, cache errors, memory use, and evictions to confirm that caching helps without serving unacceptably stale data.

   • Verify repeated reads use the cache, and updates or expiry refresh data as designed.
   • Measure hit rate as hits divided by hits plus misses, ideally per cached operation.
   • Compare cold and warm caches under similar load; check median and tail latency and database queries.
   • Monitor memory, evictions, and errors; a high hit rate alone does not prove better performance.

   What the interviewer checks: The interviewer is checking whether you can verify cache correctness and measure real benefits for the workload.

   Other ways it was asked

   • “How would you ensure your cache is working correctly, and what metrics would you monitor?”
   • “How can you monitor cache usage and gain insight into it within an application?”
   • “How would you determine whether caching is effective for this workload and how do you measure it?”

7. How would you cache protected content without serving it to unauthorized users?

   Asked in 2 of 114 interviews · last asked Jul 16 · Scenario · Senior

   Show answer

   Check who the user is and whether they still have access before serving protected content, even on cache hits. Bypass shared page and CDN caches unless access is checked before every cached response. Use `Cache-Control: private, no-store` for protected responses. Cache objects internally, but check access before returning them and separate user-specific data.

   • A cache key or an unguessable URL is not an access check.
   • CDN rules must respect cache headers and must not override them for protected responses.
   • Include user or tenant identity in cache keys when the content differs by user or tenant.
   • Invalidate cached access decisions when permissions change; a TTL alone leaves a window for revoked access.

   What the interviewer checks: The interviewer is checking whether caching can bypass access checks or leak content across users.

   Other ways it was asked

   • “How should you handle caching when users should only see content they have purchased or been granted access to?”
   • “How would you configure page caching, a CDN, and object caching so protected membership pages are never served to the wrong user?”

8. How would you flush or selectively invalidate cached data in an application using Redis?

   Asked in 2 of 114 interviews · last asked Jul 20 · Design · Senior

   Show answer

   I invalidate specific Redis keys with DEL after the database update commits. For groups of keys, I use SCAN with an application prefix, then delete matches. FLUSHDB clears the selected Redis database; FLUSHALL clears all databases on that server. I use TTLs as a backup to limit how long stale data remains.

   • Use application prefixes to avoid deleting another application's keys.
   • Prefer SCAN over KEYS in production; KEYS can block Redis on large datasets.
   • Avoid flushing shared databases: flush commands remove more than just your application's cache.
   • Scanning and deleting is not atomic; concurrent requests can recreate stale entries.

   What the interviewer checks: The interviewer checks whether you can invalidate the right data without blocking Redis or deleting unrelated data.

   Other ways it was asked

   • “How would you flush or invalidate an application's cache?”
   • “How would you control cache invalidation in Redis?”

9. How should LRU put handle existing keys, capacity limits, and linked-list updates?

   Asked in 2 of 114 interviews · last asked Aug 13 · Write code · Senior

   Show answer

   For an existing key, replace its value and move its node to the most recently used end without changing the size. For a new key, add a node and a map entry. If capacity is exceeded, remove the least recently used node from both the list and the map.

   • Reuse an existing node; do not create duplicates or evict another key when updating.
   • When unlinking, connect the previous node to the next node in both directions.
   • When inserting, set both node links and neighboring links; update head or tail if not using sentinels.
   • A cache with zero capacity must keep no entries.

   What the interviewer checks: The interviewer checks whether you preserve recency order, capacity, and agreement between the map and linked list.

   Other ways it was asked

   • “In a bounded LRU cache, what should the setter do when adding or updating an entry?”
   • “When setting a value in an LRU cache, how should you handle a key that already exists?”
   • “When implementing an LRU cache, how do you handle put(key, value) when the key already exists versus when capacity is exceeded, and what pointer updates are required?”

10. How does HTTP caching work, which requests are cacheable, and how do Cache-Control and ETag affect it?

    Asked in 2 of 114 interviews · last asked Oct 7 · Concept · Mid-level

    Show answer

    HTTP caches store responses and reuse them while they are fresh. GET and HEAD are usually cacheable, but storage also depends on response headers and status. Cache-Control sets storage and freshness rules. ETag identifies a response version; the client sends it in If-None-Match, and a 304 Not Modified response lets it reuse the cached body.

    • max-age sets freshness in seconds; stale responses generally need validation or replacement.
    • no-cache allows storage but requires validation before reuse; no-store forbids storage.
    • private prevents shared-cache storage; public allows shared caches, such as CDNs, to store responses.
    • POST caching requires explicit freshness and Content-Location matching the request URL; support is uncommon.

    What the interviewer checks: The interviewer checks whether you distinguish cache storage, freshness, and validation, rather than assuming every request is cached.

    Other ways it was asked

    • “How does client-side HTTP caching work, and are all requests cached?”
    • “How does HTTP caching work with `Cache-Control` and `ETag`?”

11. How do you fetch, cache, and refresh server data with React Query or SWR?

    Asked in 2 of 114 interviews · last asked Sep 7 · Tooling · Mid-level

    Show answer

    React Query and SWR fetch server data through hooks and cache it by key. I provide a key and fetch function, then handle loading and error states. They can refresh data in the background. After changes, I invalidate affected React Query queries or use SWR’s mutate to update or refresh cached data.

    • Include filters, page numbers, and other request inputs in the cache key.
    • In React Query, staleTime controls freshness; stale data is not immediately deleted.
    • Refresh on window focus, reconnect, or an interval is configurable; defaults differ between libraries.
    • Make the fetch function throw on failed HTTP responses so the hook can report errors.

    What the interviewer checks: The interviewer checks whether you can manage cached server data and keep it fresh after changes.

    Other ways it was asked

    • “How do you manage server state with React Query and SWR?”
    • “How do you fetch, cache, and reload API responses with React Query?”

12. How do you persist and unpersist cached data in Spark or Databricks?

    Asked in 2 of 114 interviews · last asked Aug 19 · Tooling · Mid-level

    Show answer

    Use cache() or persist() to cache a Spark DataFrame or RDD on executors. Caching is lazy: an action computes and stores the data. Use persist() to choose a storage level, then call unpersist() when the cached data is no longer needed.

    • Cache data you will reuse; caching adds storage and computation costs.
    • Storage levels control whether cached data uses memory, disk, or both.
    • Default storage levels differ between DataFrames, RDDs, APIs, and Spark versions.
    • unpersist() removes cached blocks, not source data; blocking=True waits for removal in PySpark.

    PythonCopy

    from pyspark import StorageLevel
    
    df = spark.table("events").persist(StorageLevel.MEMORY_AND_DISK)
    try:
        print(df.count())  # Computes and caches the data.
        print(df.filter("event_type = 'click'").count())
    finally:
        df.unpersist(blocking=True)

    What the interviewer checks: The interviewer is checking whether you understand lazy caching, storage choices, reuse, and cleanup.

    Other ways it was asked

    • “How do you persist a data structure on a Spark worker and unpersist it after the operation?”
    • “How do you cache a DataFrame in Databricks, and how do you manage its lifecycle?”

13. What types of cache are available in Snowflake, and how do they work?

    Asked in 2 of 114 interviews · last asked Sep 22 · Concept · Mid-level

    Show answer

    Snowflake has three main cache types: query result, warehouse data, and metadata. The result cache stores query results for 24 hours and can reuse them for eligible queries. Each warehouse caches data it reads on local SSD storage. The metadata cache holds table information and statistics, which can answer some queries without scanning data.

    • Result reuse generally requires a matching query, unchanged source data, and valid permissions.
    • The result cache is separate from warehouses, so reuse can avoid running a warehouse.
    • Warehouse data caching speeds up later reads; suspending the warehouse loses this cache.
    • Metadata is managed by cloud services and can support operations such as simple row counts.

    What the interviewer checks: The interviewer checks whether you distinguish cached results, cached data, and metadata, including when each avoids work.

    Other ways it was asked

    • “What is caching in Snowflake, and how many types of caching are there?”

14. What is KV caching, and how does it work in LLM inference?

    Asked in 2 of 114 interviews · last asked Oct 6 · Concept · Mid-level

    Show answer

    KV caching stores attention keys and values for tokens an LLM has already processed. Each new token attends using cached keys and values plus its own, which are also cached. This avoids recomputation for earlier tokens. This speeds up generation but uses more memory as the context grows.

    • Processing the prompt fills the cache; generating tokens extends it.
    • Each attention layer keeps its own cached keys and values.
    • Attention over earlier tokens still runs; caching does not remove that work.
    • Longer contexts and more simultaneous requests increase cache memory use.

    What the interviewer checks: The interviewer checks whether you understand what attention reuses and the speed-versus-memory trade-off.

    Other ways it was asked

    • “Can you explain the KV cache?”

15. What should your application do when Redis becomes unavailable?

    Asked in 2 of 114 interviews · last asked Sep 6 · Scenario · Senior

    Show answer

    If Redis is only a cache, the application can read from the database, but it must limit fallback traffic. Use short timeouts and a circuit breaker to stop repeated Redis calls. Serve stale data when safe, or reject excess requests. If Redis holds sessions, locks, or other critical state, reject affected operations rather than bypass required checks.

    • Cache failures can degrade performance; failures involving critical state may require rejecting requests.
    • Limit database fallback traffic to prevent overload.
    • Bound retries and add delays with jitter to avoid a retry storm.
    • After recovery, handle missed invalidations and refill the cache gradually.

    What the interviewer checks: The interviewer checks whether you can preserve correctness and prevent a Redis outage from overloading other services.

    Other ways it was asked

    • “What should a system do if Redis goes down?”
    • “Redis goes down briefly—what are your failure mode options, and how do you keep the system safe?”

16. How would you design a distributed Redis rate limiter that handles race conditions, window choices, and outages?

    Asked in 2 of 114 interviews · last asked Sep 9 · Design · Senior

    Show answer

    I would use one Redis key per user, shared by all servers, with a sliding window allowing 100 requests in any 60 seconds. A Lua script checks and updates the limit atomically. Fixed windows use less memory but allow bursts across boundaries. During outages, I would reject requests for strict limits or use a weaker local fallback.

    • Sliding window script: ZREMRANGEBYSCORE removes expired entries; ZCARD checks usage; ZADD records allowed requests; PEXPIRE handles cleanup.
    • Use Redis TIME for timestamps and unique request IDs as sorted-set members to avoid merging requests.
    • For fixed windows, run INCR and conditional EXPIRE together in Lua; separate calls risk missing expiry.
    • Redis failover can lose recent writes; strict limits need stronger consistency or conservative rejection.

    What the interviewer checks: The interviewer checks whether you can enforce shared limits atomically and explain window accuracy and outage trade-offs.

    Other ways it was asked

    • “How would you implement a distributed rate limiter using Redis or another store, and what exact atomic operations would you rely on to avoid race conditions?”
    • “Design a rate limiter that allows each user to make at most 100 requests per minute. Can it support multiple servers, handle Redis outages and race conditions, and choose between fixed and sliding windows?”

17. Where would you store a selected team identifier—in a cache or in cookies?

    Asked once · last asked Sep 7 · Scenario · Mid-level

    Show answer

    I would store the selected team ID in a cookie if the server needs it, or local storage for browser-only use. A server-side cache can store it in a session, but it may be evicted. The server must check that the user can access the selected team.

    • Cookies are sent automatically with matching requests; local storage values are not.
    • Treat the stored ID as a preference, not proof of access.
    • Use a database if the selection must persist across devices.
    • A cache should not be the only copy of a preference that must survive eviction.

    What the interviewer checks: The interviewer checks whether you separate user preferences from access control and choose storage based on how it is used.

    Other ways it was asked

    • “Where would you store a selected team identifier: in a cache, cookies, or local storage?”

18. What is the difference between a cache and a Java Map, and when would you use each?

    Asked once · last asked Apr 23 · Concept · Junior

    Show answer

    A Java Map stores key-value pairs; a cache stores reusable data to avoid slow or costly work. Caches often add expiry and automatic removal when full. Use a Map for data your code manages directly, and a cache for data you can reload or calculate again.

    • The Map interface does not require expiry, size limits, or thread safety.
    • A cache can run inside your application or in a separate service, such as Redis.
    • Cache entries may be missing or outdated; handle misses and decide how to keep data fresh.

    What the interviewer checks: The interviewer checks whether you understand storage versus caching, including entry removal and handling missing or outdated data.

19. How can caching improve a website's performance?

    Asked once · last asked Jun 5 · Concept · Mid-level

    Show answer

    Caching improves website performance by reusing stored data or content instead of fetching or creating it again. This makes responses faster and reduces work for servers and databases. Cached content must be refreshed or removed when it becomes outdated.

    • Browser and CDN caches can serve files without contacting the main server.
    • Application caches, such as Redis, can avoid repeated database queries or expensive calculations.
    • Cache hits usually respond faster; cache misses require fetching or creating the requested content.
    • Expiration and cache invalidation help limit outdated content.

    What the interviewer checks: The interviewer is checking whether you understand how caching reduces repeated work and why keeping cached content fresh matters.

20. When addressing a performance problem, how would you decide between using Redis, optimizing SQL queries, or changing the data model?

    Asked once · last asked Sep 18 · Scenario · Senior

    Show answer

    I would measure where the time goes before choosing a fix. I would optimize SQL for slow queries or missing indexes, and change the data model if its structure makes common operations expensive. I would use Redis for repeated reads when some stale data is acceptable, with a clear plan to keep the cache current.

    • Use query plans and realistic load tests to find the bottleneck and verify improvements.
    • Fix inefficient queries before adding a cache that introduces more moving parts.
    • Data model changes can speed reads but add migration work or make writes more expensive.
    • Redis adds memory costs and needs a freshness strategy and a plan for cache misses.

    What the interviewer checks: The interviewer is checking whether you use measurements and weigh trade-offs instead of treating Redis as a universal fix.

Related interview questions

• Software Engineer interview questions
• Data Engineer interview questions
• AI Engineer interview questions
• DevOps Engineer interview questions
• Machine Learning Engineer interview questions
• Data Structures and Algorithms interview questions
• OOP and Design Patterns interview questions
• System Design interview questions
• Microservices interview questions
• REST API interview questions
• Kafka and Message Queues interview questions
• Operating Systems interview questions
• Computer Networks interview questions
• Git interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every Caching and Redis interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

114 interviews, 89 candidates, Dec 2025 to Oct 2026. Updated every month with new interviews.