Course lesson 17 · Smart Routing Service
Speed things up with KV
The redirect service adds a KV cache to reduce repeated database round trips, especially for visitors far from the demonstrated D1 location. It first looks up the link ID in KV, validates cached JSON, and falls back to D1 on a miss or invalid cached value. A successful database lookup populates KV with a 24-hour expiration before returning the same link shape used by the routing helper.
Primary source: course video 17 · Supplied English subtitles · 00:12:06.
Understand the idea
- This is cache-aside behavior: read the cache first, query the database when necessary, then populate the cache.
- D1 remains the source of stored link configuration while KV supplies a copy suited to repeated reads.
- The cached string is JSON-parsed and checked with the shared Zod link schema, so downstream routing receives a known shape.
- KV is eventually consistent: writes may not be immediately visible near all readers, which matters for frequent updates or immediate-read requirements.
- An expiration TTL deletes a cache entry after the configured period; it is not the same as actively synchronizing every edit from D1.
What the course does
- Create a stage KV namespace, bind it as cache in the data service, and regenerate environment types.
- Build a helper that reads one ID from KV and returns either a validated link object or no usable cached result.
- Build a coordinator that falls back to the shared D1 query and returns not found if neither source yields a link.
- Serialize successful database results into KV with the demonstrated 24-hour expiration.
- Replace the direct database call in the route with this cache-aware helper.
- Deploy, compare first and repeated redirects, and optionally add cache-hit logs to inspect through the Worker dashboard.
Watch for
- The instructor explains eventual consistency but does not implement write-side invalidation in this lesson. Added advice: edits to a cached destination can remain stale; a 24-hour TTL alone does not provide immediate update visibility.
- A faster second browser request is an illustration, not a controlled latency benchmark.
- Remote-binding syntax and free-tier claims reflect the recording’s tooling.
Recall before revealing
After editing a link in D1, why might the redirect still use its previous destination?
Reveal the explanation
The routing service can continue using a cached copy until it is invalidated, replaced, or expires; KV visibility is also eventually consistent.
Try it
Diagram the cache hit, cache miss with a database record, and missing-link paths, then inspect logging for one repeated link request.
Check your result
You can explain which paths call D1, when KV is populated, and why freshness needs an explicit policy.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:00:00 — Database distance and eventual consistency
- 00:03:02 — Cache-first lookup order
- 00:05:00 — Validate cached JSON and coordinate fallback
- 00:08:01 — Set the 24-hour expiration
- 00:11:01 — Repeated-request observation and cache logging
Companion primary documentation: How Workers KV works. For recorded API names, commands, limits, and prices, check the version you use.