Hash tables in caching (Redis, Memcached) in Data Structures Theory - Step-by-Step Execution

Concept Flow - Hash tables in caching (Redis, Memcached)

Start: Request for Data

↓

Compute Hash Key from Data Key

↓

Look Up Hash Table Bucket

↓

Key Found

↓

Return Cached

↓

Send Data

↓

Send Data

When data is requested, a hash key is computed to quickly find the data in the cache. If found, it returns immediately; if not, it fetches from the database and stores it in the cache.

Execution Sample

Data Structures Theory

cache = {}
key = 'user123'
hash_key = hash(key)
if hash_key in cache:
    return cache[hash_key]
else:
    data = fetch_from_db(key)
    cache[hash_key] = data
    return data

This code checks if data for 'user123' is in cache using a hash key; if not, it fetches from the database and caches it.

Analysis Table

Step	Action	Hash Key Computed	Cache Lookup Result	Cache State	Output
1	Compute hash for 'user123'	hash('user123')=42	N/A	{}	N/A
2	Check if 42 in cache	42	No	{}	N/A
3	Fetch data from DB for 'user123'	42	No	{}	Data from DB
4	Store data in cache with key 42	42	No	{42: 'Data from DB'}	N/A
5	Return cached data for key 42	42	Yes	{42: 'Data from DB'}	Data from DB
6	Request again for 'user123'	hash('user123')=42	Yes	{42: 'Data from DB'}	Data from DB
7	Return cached data immediately	42	Yes	{42: 'Data from DB'}	Data from DB

💡 Cache hit on step 5 and 7 returns data immediately; no further DB fetch needed.

State Tracker

Variable	Start	After Step 2	After Step 4	After Step 7
cache	{}	{}	{42: 'Data from DB'}	{42: 'Data from DB'}
hash_key	N/A	42	42	42
Output	N/A	N/A	Data from DB	Data from DB

Key Insights - 3 Insights

Why do we use a hash key instead of the original key directly?

Using a hash key converts the original key into a fixed-size number, allowing very fast lookup in the cache's internal structure, as shown in execution_table steps 1 and 2.

What happens if the key is not found in the cache?

The system fetches data from the database and then stores it in the cache for future use, as seen in execution_table steps 3 and 4.

Why does the cache state change only after fetching from the database?

Because the cache only stores data after confirming it is not already present, ensuring fresh data is cached, demonstrated in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cache state after step 2?

A {42: 'Data from DB'}

B None

C {}

D {'user123': 'Data from DB'}

💡 Hint

Check the 'Cache State' column for step 2 in the execution_table.

At which step does the cache get updated with new data?

A Step 4

B Step 2

C Step 5

D Step 7

💡 Hint

Look for the step where 'Store data in cache' action happens in the execution_table.

If the hash function returned a different value for the same key, what would happen?

A Cache hits would increase

B Cache misses would increase

C Cache state would remain unchanged

D Data would never be fetched from DB

💡 Hint

Consider how cache lookup depends on consistent hash keys as shown in variable_tracker for 'hash_key'.

Concept Snapshot

Hash tables in caching use a hash function to convert keys into fixed-size hash keys.
These hash keys allow fast lookup in the cache.
If data is found (cache hit), it returns immediately.
If not found (cache miss), data is fetched from the database and stored in cache.
This speeds up repeated data access by avoiding slow database calls.

Full Transcript

When a data request comes in, the system computes a hash key from the original key. This hash key is used to quickly check if the data is in the cache. If the cache contains the data (cache hit), it returns the data immediately. If not (cache miss), it fetches the data from the database, stores it in the cache using the hash key, and then returns the data. This process speeds up data retrieval by reducing database queries. The cache state changes only after fetching new data, ensuring fresh data is stored. Consistent hash keys are crucial for correct cache lookups.