Week 3 · Foundation

Cache in front of Postgres

0:00 / 3:00

15 seconds

The same ticket, 400 times.

The copilot re-fetches ticket 1842 on every tool call. Northwind's DBA pages you.

AI layerGET ticketRedisTTL 60sPostgresOn miss
Lesson notesCache in front of Postgres: the short version+

Week 3 · Data audits & API trust boundary · about 3 minutes

What you will be able to do

Serve hot ticket reads from Redis with a TTL so the AI layer does not hammer the customer database.

The idea

Put Redis in front of hot reads. On a miss, load from Postgres, set a short TTL, return the value. On a write, invalidate or overwrite the key.

A cache without a TTL becomes yesterday's truth forever. A cache without invalidation serves closed tickets as open.

def get_ticket(ticket_id: str) -> dict:
    key = f"ticket:{ticket_id}"
    cached = redis.get(key)
    if cached:
        return json.loads(cached)
    row = db.fetch_ticket(ticket_id)
    redis.setex(key, 60, json.dumps(row))
    return row

def update_ticket(ticket_id: str, patch: dict) -> dict:
    row = db.update_ticket(ticket_id, patch)
    redis.delete(f"ticket:{ticket_id}")
    return row

Cache reads. Invalidate on writes. Expire everything.

Key takeaways

  • Read-through cache for hot ticket gets.
  • Always set a TTL.
  • Delete or refresh the key on writes.

Part of the Forward Deployed Engineer roadmap. New to the role? Start with what a Forward Deployed Engineer does.