Assignment 2: Cache it — add Redis and measure the difference

Goal: Prove to yourself that caching is worth it. Take the app from Assignment 1, add Redis as a cache-aside layer, and measure the response time with and without the cache so you can talk about the result.

Where: The same app/Nginx host from Assignment 1, plus Redis (install it on the app host or a lab VM you choose). Keep using your per-app database from Assignment 1.

Tasks

1. Install Redis and confirm it answers: sudo apt install -y redis-server, sudo systemctl enable --now redis-server, then redis-cli ping (expect PONG).
2. Add a slow read. In your app, add an endpoint that does a deliberately slow-ish database read (e.g. a query, or add a small artificial delay) and returns the result. This is your "no cache" baseline.
3. Implement cache-aside. Before hitting the database, the app checks Redis for the key (e.g. GET notes:all). On a miss, read the database, then store the result in Redis with a TTL (e.g. SET notes:all <value> EX 30). On a hit, return straight from Redis.
4. Measure both paths. Use curl -w "%{time_total}\n" -o /dev/null -s http://<host>/your-endpoint (or ab/hey if you know them). Record: first request (miss, populates cache) vs subsequent requests (hits).
5. Watch the cache work. In one terminal run redis-cli MONITOR (or repeatedly redis-cli GET notes:all and redis-cli TTL notes:all) while you hit the endpoint, and observe the key appear and its TTL count down.
6. Show expiry/invalidation. Wait for the TTL to expire (or redis-cli DEL notes:all) and show the next request is slow again (a miss), then fast again. Briefly note in your write-up how you'd invalidate the cache when the underlying data changes.

Deliverable

A short markdown write-up with: the Redis install confirmation (PONG), the relevant cache-aside code snippet, a small table of measured response times (cold miss vs warm hit), and the redis-cli output showing the key and its TTL. State the TTL you chose and why.

Acceptance criteria — you're done when:

• Redis is installed and redis-cli ping returns PONG.
• Your app implements cache-aside: check Redis first, fall back to the database on a miss, and populate Redis with a TTL.
• You captured measured response times for a cache miss vs a cache hit, and the hit is clearly faster.
• You demonstrated the cached key and its TTL via redis-cli (GET + TTL, or MONITOR).
• You showed that after the key expires/is deleted, the next request misses (slow) then repopulates the cache (fast again).
• Your write-up states the chosen TTL, why, and how you'd invalidate the cache on data change.

Hints

• "Cache-aside" = app logic, not magic: look in cache → miss → read DB → write to cache → return. Re-read section 1 of the Redis lesson.
• Pick a TTL that fits how stale the data may be: 30s is fine for a demo; sessions live longer.
• Namespacing keys (e.g. notes:all, user:1:name) keeps things tidy — it's a convention.
• If hits aren't faster, check you're actually returning from Redis on a hit and not always querying the DB.
• redis-cli MONITOR streams every command Redis receives — great for seeing your GET/SET in real time (don't leave it running in production).
• Remember a cache is disposable: if you flush Redis, the app should still work (just slower) by refilling from the database.
• Blocked for >~30 min after re-reading the lessons? Bring what you've tried to your mentor.