Skip to content

Redis¶

Redis plays three roles in dichit-backend: cache, queue broker, and real-time pub/sub.

Topology¶

Concern	Keyspace / usage
Caching	frequent reads (see caching.md)
BullMQ	queue jobs + job state
WebSocket pub/sub	`ws:global` channel fan-out

flowchart LR
    API["App"] --> RD[(Redis)]
    RD --> C["Cache (get/set with TTL)"]
    RD --> BQ["BullMQ queues"]
    RD --> PS["Pub/Sub (ws:global)"]
    W["WS instances"] --> PS

Configuration¶

From environment-variables.md:

Variable	Purpose
`REDIS_HOST` / `REDIS_PORT`	endpoint
`REDIS_PASSWORD`	auth
`REDIS_TLS_ENABLED`	TLS for managed Redis
`REDIS_CONNECT_TIMEOUT`	connect timeout (ms)
`REDIS_MAX_RETRIES_PER_REQUEST`	retry budget

Connection is via ioredis. Local Redis comes from docker-compose.local.yml (port 6379).

Pub/sub and scaling¶

Real-time events are published once and delivered by every instance (see websocket-architecture.md):

sequenceDiagram
    participant A as Publisher instance
    participant R as Redis (ws:global)
    participant B1 as Subscriber 1
    participant B2 as Subscriber 2
    A->>R: publish(event)
    R-->>B1: event
    R-->>B2: event

BullMQ also relies on Redis for queue semantics, so Redis is a hard dependency for background jobs and real-time features.

Failure characteristics¶

Redis down → caching degrades (depending on getCache/setCache fallbacks), queues pause, pub/sub fan-out stops.
Follow runbooks/redis-down.md when it happens.