Architecture: How should Vitto's per-user per-space memory system be archi...

Documentation for Sessions

🏗️ Architecture: How should Vitto's per-user per-space memory system be archi...

Date: 2026-03-09
Time: 22:16:00 UTC
Session: gspace1-195.3
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto's per-user per-space memory system be architected for millions of users?

Task: Not specified

🎯 Decision Made

Chosen:

User Dossier model: one structured document per user in vitto-mind with nested per-space sections, hydrated from gograb-api platform data on first access. Hybrid write path: Dossier (primary) → user_agent_memories (sync) → vitto-memories (cache with 24h TTL). Pre-compiled briefs (~200 tokens) replace 60-read brute-force recalls.

Options Considered:

  1. Per-user databases in vitto cluster
  2. Per-user collections within vitto-mind
  3. Single collection with compound indexes
  4. User Dossier document model (chosen)

💭 Reasoning

Evaluated 4 alternatives: (1) Per-user databases — millions of DBs is operational nightmare, no cross-user queries, Atlas management impossible at scale. (2) Per-user collections — thousands of collections, index management overhead, no $lookup. (3) Single collection + compound indexes — vector search degrades at 10M+ docs (Atlas post-filters full index). (4) User Dossier document — single collection with per-user docs, nested spaces map, 16MB doc limit not a concern (~50KB per dossier), supports compound indexes, atomic updates, aggregation. The dossier model gives per-user isolation with per-space scoping while keeping everything queryable. Hydration from 6 gograb-api collections (users, user_hierarchy, user_preferences, user-channel-identities, user_agent_memories, usage_records) via HTTP ensures API-first access per S106.3 decision.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation