🏗️ Architecture: What is the 3-database architecture for multi-tenant AI data...

Date: 2026-02-05
Time: 23:02:56 UTC
Session: editor2-92.19
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

What is the 3-database architecture for multi-tenant AI data isolation?

Task: Session 93: Define 3-database architecture for multi-tenant AI

🎯 Decision Made

Chosen:

DB1: ai-agents (global) — T1 workspace-scoped decisions/sessions, golden knowledge, builder_profiles, agent registry. DB2: space-agents_{spaceSlug}{shortId} (per space, many) — T2+T3 AI decisions, user_profiles, user_interactions, patterns, preferences, embeddings. DB3: space{spaceSlug}_{shortId} (per space, backend-api controlled — NOT touched by backend-ai-api). Routing rule: spaceId present → DB2, absent → DB1. Simple.

Options Considered:

1. Single database with tenant field filtering
2. Per-space database isolation via useDb()
3. Separate MongoDB clusters per tier
4. Collection-level isolation within one DB

💭 Reasoning

AI data must be isolated per space for privacy and data ownership (T2 owns T3's data in B2B2C model). The existing space-database.utils.ts already defined the naming convention (space-agents_{spaceId}) and collection structure but was NEVER USED before Session 93. DB1 (ai-agents) remains the global store for T1 developer workflow and cross-space golden knowledge. DB3 is controlled by backend-api and is not touched by the AI system. The SpaceAIDatabaseService uses Mongoose connection.useDb() with caching, mirroring the proven McpProjectService pattern.

📁 Files Involved

• apis/backend-ai-api/src/app/agents/utils/space-database.utils.ts
• apis/backend-ai-api/src/app/agents/services/space-ai-database.service.ts
• libs/libs-api/backend-core/src/lib/config/database-names.config.ts

🔗 Related

• Decision ID: dev_1770332576184_n15yi4s
• Session: 92
• Workspace: editor2

Auto-generated by MCP Smart Consolidation