🏗️ Architecture: How should group chat (whistle feature) be architected? Mult...

Date: 2026-03-14
Time: 12:27:13 UTC
Session: gspace1-218.2
Agent: architecture
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should group chat (whistle feature) be architected? Multiple options considered: separate GroupSession collection, extend ChatSession, or hybrid.

Task: Whistle group chat architecture — S218

🎯 Decision Made

Chosen:

Extend ChatSession with optional participants[] + link to GroupConversation in vitto-api. No new collections. ChatSession is the message store (adds 4 optional fields), GroupConversation handles orchestration intelligence. Same pattern as cross-channel bridge: ai-api persists, vitto-api orchestrates.

Options Considered:

1. Separate GroupSession collection (too much new infra)
2. Extend ChatSession only (chosen — simplest)
3. Three-layer: ChatSession + GroupSession + GroupConversation (over-engineered)

💭 Reasoning

Three-layer approach (GroupSession middleman) was over-engineered — added a join, a sync problem, and zero value. Separating membership from messages sounds clean but creates maintenance burden. The simplest approach that supports both intra-space (now) and open groups (future) is extending ChatSession with groupType field. intra-space uses spaceId, open uses spaceId:null. Same schema, same Socket.IO, same frontend. YAGNI won over architectural purity.

📁 Files Involved

• No files specified

🔗 Related

• Decision ID: dev_1773491233198_689gdiz
• Session: 218
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation