Home›Redis in 5 Days›Day 2
Day 2 of 5
⏱ ~60 minutes
Redis in 5 Days — Day 2

Caching Patterns

Cache database query results, set TTL expiration, implement cache invalidation, and measure hit rates.

The Cache-Aside Pattern

Also called lazy loading. Check the cache first. If found (cache hit), return it. If not (cache miss), fetch from the database, store in cache, return to caller.

Node.js cache-aside
import { createClient } from 'redis';
const redis = createClient();
await redis.connect();

async function getUser(id) {
  const cacheKey = `user:${id}`;

  // 1. Check cache
  const cached = await redis.get(cacheKey);
  if (cached) {
    console.log('Cache HIT');
    return JSON.parse(cached);
  }

  // 2. Cache miss → query database
  console.log('Cache MISS');
  const user = await db.query('SELECT * FROM users WHERE id = $1', [id]);

  // 3. Store in cache with TTL
  await redis.setEx(cacheKey, 3600, JSON.stringify(user));

  return user;
}

// Invalidate cache when user is updated
async function updateUser(id, data) {
  await db.query('UPDATE users SET ...');
  await redis.del(`user:${id}`);  // invalidate
}
Write-through pattern
// Write to cache AND database together
async function createPost(data) {
  const post = await db.create(data);
  const cacheKey = `post:${post.id}`;
  await redis.setEx(cacheKey, 1800, JSON.stringify(post));
  // Also invalidate the list cache
  await redis.del('posts:all');
  return post;
}
💡
Cache keys should be namespaced and predictable: resource:id or resource:filter:value. Example: user:123, posts:page:2, products:category:electronics. This makes bulk invalidation possible with SCAN.
📝 Day 2 Exercise
Add Caching to an API
  1. A
  2. d
  3. d
  5. R
  6. e
  7. d
  8. i
  9. s
  11. c
  12. a
  13. c
  14. h
  15. i
  16. n
  17. g
  19. t
  20. o
  22. a
  23. n
  25. E
  26. x
  27. p
  28. r
  29. e
  30. s
  31. s
  33. r
  34. o
  35. u
  36. t
  37. e
  38. .
  40. C
  41. h
  42. e
  43. c
  44. k
  46. c
  47. a
  48. c
  49. h
  50. e
  52. f
  53. i
  54. r
  55. s
  56. t
  57. .
  59. O
  60. n
  62. m
  63. i
  64. s
  65. s
  66. ,
  68. f
  69. e
  70. t
  71. c
  72. h
  74. f
  75. r
  76. o
  77. m
  79. y
  80. o
  81. u
  82. r
  84. d
  85. a
  86. t
  87. a
  88. b
  89. a
  90. s
  91. e
  92. ,
  94. c
  95. a
  96. c
  97. h
  98. e
  100. t
  101. h
  102. e
  104. r
  105. e
  106. s
  107. u
  108. l
  109. t
  111. w
  112. i
  113. t
  114. h
  116. 1
  117. 0
  118. -
  119. m
  120. i
  121. n
  122. u
  123. t
  124. e
  126. T
  127. T
  128. L
  129. .
  131. A
  132. d
  133. d
  135. a
  137. D
  138. E
  139. L
  140. E
  141. T
  142. E
  144. e
  145. n
  146. d
  147. p
  148. o
  149. i
  150. n
  151. t
  153. t
  154. h
  155. a
  156. t
  158. i
  159. n
  160. v
  161. a
  162. l
  163. i
  164. d
  165. a
  166. t
  167. e
  168. s
  170. t
  171. h
  172. e
  174. c
  175. a
  176. c
  177. h
  178. e
  180. e
  181. n
  182. t
  183. r
  184. y
  185. .

Day 2 Summary

  • Cache-aside: check cache → miss → fetch DB → store in cache. Most common pattern.
  • Always set a TTL. Caches without expiration become stale data graveyard.
  • Invalidate the cache entry when the underlying data changes.
  • Namespaced keys: user:123, posts:page:2. Consistent naming enables bulk operations.
→
← Previous
Day 1: Redis Data Types
Next →
Day 3: Sessions and Auth
→
Finished this lesson?