Architecture Deep Dive — Scalable Expense & Multi-User System

saved 05 May 2026
active
Core problem: LLM is currently both orchestrator AND executor. This kills trust because hallucinations get written to real data. PROPOSED ARCHITECTURE: 1. API-first backend - Every action (log expense, add to list, create event) is a pure REST/GraphQL API call - LLM wraps results only — reads responses, formats them, never guesses - All writes return verified_state — LLM echoes it verbatim 2. User registry service - username (internal), display_name (shown everywhere), linked_tabs, group_memberships, scopes - Resolves at log time — "Giulia" typed anywhere → resolves to giuliatomas → writes to correct tab - Scales to any number of travellers, no hardcoding 3. Multi-tab expense routing - tab_targets param: ["uzbek_trip", "personal"] — one log hits both - Each group has its own expense tab config - Couple tab is just another group, not a special case 4. LLM role = orchestrator only - LLM calls API, gets back JSON verified_state - Formats it for user — never invents confirmations - Ambiguity (couple vs group?) → asks user before calling API, never assumes 5. Next steps - Build user registry with username → display_name resolution - Abstract all tool calls behind a single API gateway - Add tab_targets to every expense log call - Move verified_state enforcement to API layer (not just prompt) - Add audit log — every write stamped with who, when, what tool, what was returned SCALING PATH: - Any trip: create group → add members → they get scoped access → expenses auto-route to trip tab - Settlement at end: one API call, full HTML report - No username leaking, no auto-assumptions, no silent failures
project · Systemarchitectureexpensesscalingdevllmapi