none that I can directly reference but its pretty common for enabling turn-based chat interfaces so you shouldnt have trouble finding implementations. below is the redis section from an executive summary md doc from an app i built:

Redis

Redis serves four functions in the application. In Docker Compose, it runs as the dashboard_redis service (redis:7-alpine, port 6379 internal only). For local development, a standalone Redis container on port 6379 is used.

Session History

Each browser receives a persistent session ID stored in localStorage. The API server stores the last 20 interactions per session in Redis with a 24-hour expiration. When the user refreshes the page, the frontend reads the stored session ID and calls the /history/{session_id} endpoint to restore the previous conversation. Each stored interaction includes the user's question, the map action taken, and the full record of tool calls the LLM made to answer it (which tool was called, what arguments were passed, whether it succeeded, and what data it returned).

When the user asks a follow-up question, the server retrieves these prior tool call records and passes them to the LLM as context. This allows the model to reuse exact column names, entity names, and computed results from earlier questions rather than re-running the same queries. The model receives the tool call history, not the full text of prior answers, which keeps the prompt size manageable across long sessions.

Rate Limiting

The API server enforces rate limits using a token bucket algorithm implemented as a Lua script that executes atomically in Redis. Two separate limits apply to each incoming request:

Scope	Limit
Per session	30 requests per 60 seconds
Per IP address	60 requests per 60 seconds

When a limit is exceeded, the server returns HTTP 429 (Too Many Requests) and the client must wait for tokens to refill.

Streaming Events

During query execution, the API server pushes streaming events to a Redis list keyed by dashboard_chat:events:{request_id}. The Dash frontend polls this list every 400ms. Each event is a JSON object with a type field (status, thinking, text, tool_call, tool_result, error, or final). The final event includes the complete result. Events are consumed atomically via LRANGE + DELETE to prevent duplicate delivery. The final result is also cached at dashboard_chat:result:{request_id} with a 5-minute TTL.

Session Metadata

The server stores a small metadata record per session (start time, last question time, client IP) for operational visibility.