In the cache-aside pattern, what happens when the requested data is not found in the cache?
Think about who is responsible for loading data into the cache when it is missing.
In the cache-aside pattern, the application checks the cache first. If data is missing, it loads data from the database, stores it in the cache, then returns it.
Given the following sequence in a cache-aside pattern using Redis:
1. Application checks Redis key 'user:123'.
2. Key is missing.
3. Application queries database and gets user data: {"id":123, "name":"Alice"}.
4. Application stores this data in Redis under 'user:123'.
5. Application reads 'user:123' from Redis.
What is the output of the final Redis read?
Consider what data was stored in Redis and what is returned when reading that key.
After storing the user data as a JSON string in Redis, reading the key returns the stored JSON string representing the user.
Which Redis command correctly stores the user data JSON string '{"id":123, "name":"Alice"}' under the key 'user:123'?
Remember the Redis command to set a key's value.
The Redis command to store a value under a key is SET. GET retrieves a value. STORE and PUT are not valid Redis commands.
To prevent stale data in a cache-aside pattern, which approach optimizes cache expiration for user data in Redis?
Think about automatic ways to keep cache fresh without manual intervention.
Setting a TTL on cached keys ensures data expires automatically, reducing stale data risk and manual cache management.
An application uses the cache-aside pattern with Redis. After updating user data in the database, the cache is not updated, causing stale data to be served. What is the most likely cause?
Consider the responsibilities of the application in cache-aside pattern after database writes.
In cache-aside, the application must explicitly update or invalidate cache after database changes. Redis does not sync automatically.