🏗️ Architecture: How should Redis integration be implemented across all 4 API...

Date: 2026-02-19
Time: 14:30:26 UTC
Session: gspace1-121.124
Agent: backend
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

How should Redis integration be implemented across all 4 APIs?

Task: Session 121: Redis implementation strategy

🎯 Decision Made

Chosen:

Create shared RedisModule in @libs-api/backend-core, import in all APIs

Options Considered:

1. Add Redis code to each API independently
2. Create shared RedisModule in @libs-api/backend-core, import in all APIs
3. Use NestJS CacheModule with Redis adapter

💭 Reasoning

DRY principle: shared RedisModule provides consistent connection handling, health checks, graceful fallback pattern (already proven in TaskQueueService), and ioredis configuration (including family=0 for Railway dual-stack networking). Each API imports the module and gets a RedisService. Implementation order: (1) Create shared RedisModule with graceful fallback, (2) Add to backend-vitto-api first (already has Redis), (3) Add to backend-api and backend-ai-api, (4) Add to backend-docs-api. All code changes use REDIS_URL env var with fallback to in-memory -- existing deployments unaffected until Redis is available. Railway private networking requires family=0 in ioredis connection.

📁 Files Involved

• libs/libs-api/backend-core/src/index.ts
• apis/backend-vitto-api/src/app/engine/task-queue.service.ts

🔗 Related

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

Auto-generated by MCP Smart Consolidation