🏗️ Architecture: Should Redis be deployed for all 4 APIs or just Vitto?

Date: 2026-02-19
Time: 14:30:19 UTC
Session: gspace1-121.123
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Should Redis be deployed for all 4 APIs or just Vitto?

Task: Session 121: Redis for all 4 APIs analysis

🎯 Decision Made

Chosen:

Redis for all 4 APIs via 1 shared instance with logical databases

Options Considered:

1. Redis only for backend-vitto-api (current state)
2. Redis for all 4 APIs via 1 shared instance with logical databases
3. Separate Redis instances per API

💭 Reasoning

Analysis found: 90+ in-memory Maps/Sets across all 4 APIs losing state on restart. 6 WebSocket gateways with no cross-instance coordination. 5 separate rate limiters that are per-instance only. Security-sensitive tokens (magic links, OAuth) in volatile memory. AI cost controls that fail silently in multi-instance. Redis logical databases (db 0-3) provide isolation without overhead of multiple instances. One instance is simpler to manage, monitor, and costs ~$5-10/month on Railway. backend-api needs Redis for: ThrottlerModule, magic links, OAuth cache, WebSocket state. backend-ai-api needs Redis for: ThrottlerModule, distributed locks (already has code), WebSocket rate limiting, session recovery. backend-docs-api needs Redis for: ThrottlerModule, WebSocket pub/sub. backend-vitto-api already has Redis for BullMQ but should expand to: ChannelRateLimiter, PromptCache, ResponseCache, CircuitBreaker.

📁 Files Involved

• apis/backend-api/src/app/auth/magic-link.service.ts
• apis/backend-api/src/app/mcp-gateway/mcp-oauth.controller.ts
• apis/backend-ai-api/src/app/orchestration/distributed-lock.service.ts
• apis/backend-vitto-api/src/app/engine/task-queue.service.ts
• apis/backend-vitto-api/src/app/security/rate-limiting/channel-rate-limiter.service.ts

🔗 Related

• Decision ID: dev_1771511418971_i3f58du
• Session: 121
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation