Per user feedback, split into two phases:
Phase 1 (this task): Merged deployment to reduce cost. All services in single topfans namespace, single gateway, external DB (RDS/ElastiCache), HPA for high-load services. Focus on getting off single VM and using K8s elasticity.
Phase 2 (future, not in this task): Per-group namespace isolation. Triggered by scale/isolation needs. Sketch included as future reference.
Removed from this spec (moved to Phase 2 or out of scope):
- per-group namespace architecture (was the original main design)
- ResourceQuota / LimitRange
- per-group gateway with cross-ns Dubbo
- application-layer group_id changes
- new services (admin/review/ai-*) implementation
Updated:
- Section 0: New 'Phased Strategy' section at top
- Section 2: Three candidates reframed for Phase 1 (don't migrate / single-namespace / per-group from day 1)
- Section 4: Detailed design is now single-namespace with all services merged
- Section 5: Single chart (topfans/) instead of two (topfans-shared + topfans-group)
- Section 6: Migration plan is Phase 1 only
- Section 10: Refinements trimmed to Phase 1-relevant items
- Section 11 (NEW): Phase 2 future design sketch for reference
Per user feedback: admin/review/ai-image-gen/ai-chat are completely new independent systems with their own codebases and DBs, not reusing existing services. They only have API-level calls between each other and to existing services. Section 1.3 table and 'key clarification' paragraph updated. Other 'shared' references in the document refer to the platform-architecture sense (shared services for all groups), not code reuse, so no other changes needed.
Three approaches analyzed (single-tenant, hybrid, full-isolation), with detailed pros/cons comparison. Recommended: shared platform services + per-group data services isolation via namespaces and Helm chart.
