Cache-aside pattern with Redis (sequence diagram)
This sequence diagram shows an API using the cache-aside pattern with Redis to serve a product request. It follows one request through a cache miss, a database read and a cache write. It is for students learning caching and for developers designing read-heavy APIs.
Example: Sequence diagram for an API using the cache-aside pattern with Redis: click to open it in the editor and change it.
The participants
| Participant | Role in the pattern |
|---|---|
| Client | Sends the HTTP request and receives the response |
| API | Owns the caching logic: checks the cache, reads the database, fills the cache |
| Redis | Fast key-value cache that stores products under keys like product:42 |
| Database | Source of truth for product data |
Step-by-step message flow
- GET /product/42: the Client calls the API (synchronous).
- Get product:42: the API asks Redis for the cached product first.
- Cache miss: Redis returns nothing because the key is not cached.
- SELECT product: the API falls back to the Database.
- Product row: the Database returns the product data.
- Set product:42 (TTL 10m): the API writes the row into Redis with a 10-minute expiry.
- 200 OK: the API returns the product to the Client.
The key idea of cache-aside (also called lazy loading) is that the API, not Redis, controls the cache. Redis never talks to the Database directly. Data is cached only after someone asks for it, and the TTL makes sure stale entries expire on their own.
This diagram shows the miss path only. On the next request within 10 minutes, step 2 would return the product and the API could skip steps 4–6.
How to adapt it for your project
- Rename the endpoint and key (for example GET /user/7 and user:7) to match your resource.
- Add an alt or opt block showing the cache-hit branch next to the miss branch.
- Change the TTL to fit how often your data changes.
- Add a write path where updates delete or overwrite the Redis key to avoid serving stale data.
- Swap Redis for Memcached or another cache. The message order stays the same.
Tip: Use a consistent key format like entity:id, as the diagram does with product:42. It makes invalidation and debugging much easier.
Frequently asked questions
What is the cache-aside pattern?
Cache-aside is a caching strategy where the application checks the cache first. On a miss, it reads from the database and writes the result into the cache. In this diagram the API does all of that with Redis.
What happens on a cache miss in this diagram?
Redis replies 'Cache miss', so the API runs SELECT product on the Database. It then stores the returned row in Redis as product:42 with a 10-minute TTL and returns 200 OK to the Client.
Why does the diagram set a TTL on the cached product?
The 10-minute TTL makes the cached entry expire automatically. This limits how long stale data can be served if the product changes in the Database.
Make your own sequence diagram with AI →