HomeBack to recipes
RecipesDataCache Invalidation Pipeline

TL;DR

Cache Invalidation Pipeline is a data workflow that chains Redis + Supabase to automate a common task. When a Supabase row changes, the corresponding Redis cache key is automatically invalidated to keep your API fresh. Once configured, it saves ~4 hours/week of support tickets about stale data, plus elimination of coordinated deploy flushes and runs through Claude Code, Cursor, Windsurf or any MCP-compatible AI agent.

🔴🟢
DataIntermediate

Cache Invalidation Pipeline

When a Supabase row changes, the corresponding Redis cache key is automatically invalidated to keep your API fresh.

15 min setup, sub-second cache invalidation2 MCPs requiredSaves ~4 hours/week of support tickets about stale data, plus elimination of coordinated deploy flushes

How it works

🔴Redis
🟢Supabase
Automated
1Supabase realtime trigger fires on row update2Extract table name and row ID3Build Redis cache key pattern+2 more steps

Partial support — 1 of 2 MCPs hostable

Hosted execution needs every MCP on the whitelist. Use the local CLI for this recipe until the missing MCPs are added.

Not yet hostable:

🔴Redis
mcpizy recipe install redis-supabase-cache-invalidation

Why this combo?

Supabase Realtime fires the moment a row changes; Redis holds the cached API responses for that data. Connecting them means stale cache is never served — changes propagate instantly through your entire stack without any manual TTL tuning.

Without this workflow

Update a row in Supabase. Users see stale data for up to 5 minutes due to cache TTL. Support tickets arrive. Clear cache manually.

With MCPizy

Row updated → Redis cache invalidated in milliseconds → next request hits fresh data. Zero stale responses.

Business value

Concrete ROI — not marketing fluff.

Time saved

~4 hours/week of support tickets about stale data, plus elimination of coordinated deploy flushes

  • Removes 'my order shows wrong status' support tickets — cache is always fresh, support volume drops 10-20%
  • Enables aggressive caching (long TTLs) without staleness risk — API p95 latency drops 3-5x with zero tradeoffs
  • Prevents overselling on e-commerce: inventory counts reflect reality in <100ms, avoiding costly overbook refunds
  • Replaces fragile cron-based cache warmers with event-driven invalidation — on-call wakes up less

Workflow steps

  1. 1
    Supabase realtime trigger fires on row update
  2. 2
    Extract table name and row ID
  3. 3
    Build Redis cache key pattern
  4. 4
    Invalidate matching keys via DEL / UNLINK
  5. 5
    Log invalidation for observability

Use cases

  • Invalidate product page cache the instant a price changes in the database
  • Keep user profile API responses fresh when account data updates
  • Real-time invalidation for inventory counts that must reflect live stock
  • Selective cache busting by table and row ID, not broad TTL flushing

MCPs required

🔴

Redis

Redis MCP Server

View
🟢

Supabase

Supabase MCP Server

View

Agent prompt (copy into Claude Code)

This prompt is the workflow. Paste into Claude Code, Cursor, or Windsurf.

You are a cache-invalidation agent. Subscribes to Supabase Realtime.

Setup: subscribe to postgres_changes on tables in cache-map.yaml (table → key_patterns[]).

On each row change event (INSERT/UPDATE/DELETE):
1. Read event.table + event.record (and event.old_record if UPDATE)
2. For each key_pattern configured for this table, interpolate with row fields:
   - product:{id} → product:42
   - user:{id}:profile → user:7:profile
3. Call redis.unlink(keys=[...]) — UNLINK is non-blocking vs DEL
4. Also invalidate wildcard patterns via redis.scan + redis.unlink batches (100 at a time)
5. Log the invalidation: table, row_id, keys_invalidated_count, duration_ms to Supabase cache_invalidation_log

Never error out — log failures and continue (cache freshness is best-effort).

Trigger & credentials

How this workflow fires and what env vars you need.

.env.example
Event-drivenTrigger
Supabase Realtime: postgres_changes subscription on mapped tables (INSERT, UPDATE, DELETE)
🔴Redis· 1 var
REDIS_URL

Redis connection URL

e.g. redis://default:password@redis-host:6379

🟢Supabase· 2 vars
SUPABASE_URLGet key

Project URL

e.g. https://abcd.supabase.co

SUPABASE_SERVICE_ROLE_KEYGet key

Service role key (realtime requires server key)

e.g. eyJhbGci...

One-command deploy

Install everything — MCPs, prompt, env template — in a single call.

$ mcpizy recipe install redis-supabase-cache-invalidation

✓ Installs all 2 MCP servers
✓ Writes prompt to ~/.mcpizy/prompts/redis-supabase-cache-invalidation.md
✓ Generates .env.example in current directory
✓ Ready to paste into Claude Code

Requires mcpizy CLI v1.1+ — install via npm i -g mcpizy.

Quick install (MCPs only)

15 min setup, sub-second cache invalidation
$ mcpizy install redis && mcpizy install supabase

More Data recipes

🔥🟢

Web Scraping to Database

Schedule a Firecrawl scrape of any website and store the structured results directly in a Supabase table for analysis.

🔍🟢

Search Results Indexing

Run Tavily searches on scheduled topics and index the results in Supabase for trend analysis and content research.

🕸️🐙

Knowledge Graph from Code

Parse your GitHub repos and build a Neo4j knowledge graph of files, functions, imports, and authors for code intelligence.

🦆☁️

Data Lake Queries

Query Parquet files directly from S3 using DuckDB without any ETL. Results are returned in seconds for ad-hoc analytics.

Frequently asked questions

What is this workflow?

Cache Invalidation Pipeline is a data automation that uses Redis + Supabase together via the Model Context Protocol. When a Supabase row changes, the corresponding Redis cache key is automatically invalidated to keep your API fresh.

How long does setup take?

Setup takes around 15 min setup, sub-second cache invalidation. You install the required MCP servers with `mcpizy install redis && mcpizy install supabase`, connect your accounts, and the workflow is ready to run.

How much time does this workflow save?

Once running, this workflow saves ~4 hours/week of support tickets about stale data, plus elimination of coordinated deploy flushes. The concrete business value: Removes 'my order shows wrong status' support tickets — cache is always fresh, support volume drops 10-20%; Enables aggressive caching (long TTLs) without staleness risk — API p95 latency drops 3-5x with zero tradeoffs.

Which MCP servers do I need for this?

You need 2 MCP servers: Redis (mcpizy install redis), Supabase (mcpizy install supabase). All are installable in one command via the MCPizy CLI and configured in your `.claude.json` or `.cursor/mcp.json`.

Does this work with Claude Code, Cursor, and Windsurf?

Yes. The workflow runs with any MCP-compatible AI agent — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code with Copilot, and custom agents built on the MCP SDK. The MCP servers are identical across clients; only the config file path (`.claude.json` vs `.cursor/mcp.json`) changes.

Start building this workflow

Install the required MCPs from the marketplace and automate this in 15 min setup.

$ mcpizy install redis && mcpizy install supabase

🔴Install Redis🟢Install Supabase

Free to install. Connect your accounts and this workflow runs itself.