Redis

Purpose

Describe Redis’s role in Get2Dial: low-latency storage for ephemeral call context, dialer pacing counters, and agent presence.

Overview

Redis holds short-lived state that must be read and written on the call path. It is not the system of record; durable state lives in PostgreSQL. It is accessed through the internal/cache wrapper (go-redis v9), which supports a per-tenant ACL user scoped to keys matching ~t:<tenant>:*.

Real uses (key patterns from internal/dialer/):

Call context — t:<tenant>:call:<id>:ctx, used to backfill CDRs after the queue’s uuid_transfer strips g2d_* channel variables off the carrier leg.
Dialer pacing — t:<tenant>:campaign:<id>:livecalls, inflight counters and …:connectwindow:… for predictive connect-rate windows.
Agent presence / claims — t:<tenant>:agent:<id>:active_campaigns, …:active_lead, plus agent state with a 180s TTL heartbeat.

Configuration

REDIS_ADDR=redis-host:6379     # host:port, no scheme (default localhost:6379)
REDIS_USERNAME=                # optional per-tenant ACL user (ADR-011)
REDIS_PASSWORD=change-me
REDIS_DB=0

Examples

The pacer increments a campaign’s inflight counter when it originates and releases it exactly once (via a SET-NX marker) when the call connects or ends — so a single-agent progressive campaign never stalls on a stuck gauge.

Notes

Treat Redis data as reconstructible — losing it forces a recompute or a brief degraded window, never durable-state corruption.
Per-tenant ACLs make a cross-tenant key access fail with NOPERM rather than silently reading another tenant’s data.
Secure with a password and network isolation; never expose it publicly.