Architecture: How should cross-channel chat persistence work? WhatsApp mes...

Documentation for Sessions

🏗️ Architecture: How should cross-channel chat persistence work? WhatsApp mes...

Date: 2026-03-14
Time: 04:24:41 UTC
Session: gspace1-217.3
Agent: backend
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

How should cross-channel chat persistence work? WhatsApp messages are invisible in web UI because they're stored in a separate DB (agent-sessions in vitto-api) from web chat (chat_sessions in ai-api).

Task: Cross-channel chat persistence — make WhatsApp/Slack messages visible in web UI


🎯 Decision Made

Chosen:

Bridge pattern: vitto-api POSTs channel messages to ai-api's existing /sessions/:id/messages endpoint after processing. ai-api remains the single persistence layer for ALL messages. agent-sessions stays as working memory only. No new sync layer, no migration, no frontend changes to ChatBackendSyncService.

Options Considered:

  1. Unify all sessions into vitto-api (single store)
  2. Keep both stores with separate bridge service
  3. Bridge via BackendAiClientService (chosen)
  4. Event-driven sync via message queue

💭 Reasoning

The two APIs have correct separation of concerns: ai-api = persistence + real-time (Socket.IO), vitto-api = intelligence + orchestration. The bug wasn't architectural — WhatsApp just bypassed the persistence layer. Adding a bridge POST (~50 lines) solves cross-channel visibility without a grand redesign. Socket.IO in ai-api automatically broadcasts to web clients. Frontend ChatBackendSyncService, reconciliation, and retry queue all work unchanged. Considered alternatives: (1) Unify to single store in vitto-api — rejected because massive migration, break all frontend sync. (2) Build separate bridge service — rejected because unnecessary abstraction, BackendAiClientService already has the pattern.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation