Architecture: How to implement unified chat persistence with MongoDB sync,...

Documentation for Sessions

🏗️ Architecture: How to implement unified chat persistence with MongoDB sync,...

Date: 2026-03-03
Time: 15:33:11 UTC
Session: gspace1-166.4
Agent: backend
Confidence: 90%
Status: ✅ Documented


📋 Decision Context

Question:

How to implement unified chat persistence with MongoDB sync, retry queue, reconciliation, and Conversation Genome for LLM context compression?

Task: Session 166.3: Flash persistence storage improvements + Chat MongoDB sync + Conversation Genome


🎯 Decision Made

Chosen:

Created @libs-ai/chat-sync library with ChatBackendSyncService (persistent retry queue via autoFlashState, fire-and-forget appendMessages, bidirectional reconciliation). Wired into both VittoChatPersistenceService and PanelSessionPersistenceService. Added POST /:id/messages and POST /:id/reconcile endpoints to backend-ai-api sessions controller. Created ConversationGenomeService with compile/hydrate/semanticRecall for 10-30x LLM context token reduction.

Options Considered:


💭 Reasoning

Vitto chat had ZERO backend persistence (root cause: sessionId never passed in POST body). Panel chat had no retry queue (messages silently lost on failure) and no reconciliation (IndexedDB and MongoDB could drift). The Conversation Genome is the innovation layer — a compact structured representation of entire conversations that replaces raw message history in LLM prompts, achieving massive token reduction while improving context quality. Uses cheap model (Haiku) for compilation, heuristic incremental updates between compilations, and vector-based semantic recall for retrieving relevant old snippets.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation