Architecture Discussion
Initial brainstorming session on how to structure the NeuraSutra ecosystem.
Context
NeuraSutra is an application for designers to iterate over cloth/fabric design using generative AI, with a management system for managers and tech people to oversee designers.
Stakeholders
| Role | Responsibility |
|---|---|
| Clients | Make requests for fabric designs (new or based on existing) |
| Managers | Point of contact for clients, approve/reject requests, create requirement documents |
| Designers | Use AI to iterate over designs based on requirements |
| AI | Helper for managers (future: could replace managers and communicate directly with clients) |
Flow Overview
- Client makes request
- Manager intercepts and does due diligence
- Manager creates requirement document
- Designers iterate with AI
- Manager approves designs
- Client provides feedback
- Loop continues until final approval
Key Insight: Design creation is NOT a single image - it's multiple images assembled together with versioning.
The Core Challenge
We're building a multi-tenant collaborative design platform with:
- Different user roles with vastly different needs
- Complex design workflows (not just single images, but assembled compositions with versioning)
- AI as both a tool AND a potential autonomous agent
- Real-time collaboration needs (feedback loops)
- External integrations (Telegram, WhatsApp)
Proposed Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ NEURASUTRA ECOSYSTEM │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ UNIFIED BACKEND (Django) │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ │
│ │ │ Auth & │ │ Project │ │ Design │ │ AI Pipeline │ │ │
│ │ │ RBAC │ │ Manager │ │ Engine │ │ Orchestrator │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────────┘ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ │
│ │ │ Workflow │ │ Messaging │ │ Billing │ │ Notification │ │ │
│ │ │ Engine │ │ (Internal) │ │ & Usage │ │ Service │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ REST/WebSocket │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ MICROSERVICES LAYER (FastAPI - Optional) │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐ │ │
│ │ │ Image Process │ │ AI Generation │ │ File Conversion │ │ │
│ │ │ (CPU heavy) │ │ Queue Worker │ │ (BMP, Loom files) │ │ │
│ │ └─────────────────┘ └─────────────────┘ └─────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────┼───────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ UNIFIED │ │ CLIENT │ │ BOTS │ │
│ │ PORTAL │ │ PORTAL │ │ (TG/WA) │ │
│ │ (Vite PWA) │ │ (Vite PWA) │ │ │ │
│ │ │ │ (Separate) │ │ │ │
│ │ - Admin │ │ │ │ │ │
│ │ - Manager │ │ │ │ │ │
│ │ - Designer │ │ │ │ │ │
│ └─────────────┘ └─────────────────┘ └─────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FUTURE: DESIGN STUDIO (Electron) │ │
│ │ Native app for designers - heavy image manipulation │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Key Architectural Decisions
1. Backend: Django Monolith + FastAPI Sidecars
| Django (Core) | FastAPI (Sidecars) |
|---|---|
| Auth, RBAC, User management | Image processing queues |
| Project/Order management | AI generation workers |
| Workflow state machine | File format conversion |
| Billing, audit trails | Real-time WebSocket proxies |
| Admin interface (Django Admin) | Heavy computational tasks |
Why not pure microservices? Small team. Monolith-first with clear module boundaries is faster to build and easier to debug. FastAPI sidecars handle CPU-bound tasks that would block Django.
2. Frontend: Three Apps (Not Four)
| App | Users | Reasoning |
|---|---|---|
| Internal Portal (Single PWA) | Admin, Manager, Designer | Same codebase, role-based UI rendering. Shared components (project viewer, design canvas, chat). Reduces duplication. |
| Client Portal (Separate PWA) | Clients | Different auth flow, simpler UI, possibly white-labeled. Security boundary - clients shouldn't accidentally see internal routes. |
| Design Studio (Electron, Future) | Designers | Heavy canvas operations, offline support, native file system access |
3. The Design Engine - Core IP
Designs are compositions of multiple parts (body, border, pallu for sarees). Data model:
Project
└── Requirement (from manager)
└── Design (version 1, 2, 3...)
└── Composition
├── Part: "body"
│ └── Iteration 1 (AI generated)
│ └── Iteration 2 (regenerated)
│ └── Iteration 3 (approved ✓)
├── Part: "border"
│ └── ...
└── Part: "pallu"
└── ...
Each Iteration has:
- Generated images (stored in MinIO)
- Parameters used for generation
- Status (pending_review, approved, rejected)
- Reviewer feedback
4. AI Agent Architecture
Design for AI eventually replacing managers:
# Conceptual - AI as a participant in the workflow
class WorkflowParticipant:
"""Can be Human or AI"""
def can_approve(self, task_type): ...
def process_request(self, request): ...
class HumanManager(WorkflowParticipant): ...
class AIManager(WorkflowParticipant): ... # Future
# Workflow engine doesn't care who's processing
workflow.assign_task(task, participant=current_manager)
Open Questions
Design Versioning Complexity
- When a client requests changes to "the border", do we create a new version of the entire design, or just branch the border part?
- How do we handle "go back to version 3 but keep the pallu from version 5"?
Real-time Collaboration
- Do multiple designers work on the same project simultaneously?
- Do managers need to see designer work in real-time, or is it review-based?
Client Communication Flow
- Telegram/WhatsApp: Is this for notifications only, or full request creation?
- Can clients upload reference images via WhatsApp that go directly into the system?
AI Generation Queue
- "2 images per design part" - is this fixed or configurable?
- How long does generation take? Do users wait, or is it async notification?
File Output Formats
- BMP/loom-ready files - always the final step, or can clients request different formats?
- Who handles the technical specs (thread count, DPI)?
Recommended Applications
| # | Application | Tech | Purpose |
|---|---|---|---|
| 1 | neurasutra-core | Django | Main backend - all business logic |
| 2 | neurasutra-workers | FastAPI + Celery/Dramatiq | AI generation, image processing queues |
| 3 | neurasutra-portal | Vite + React/Vue | Internal portal (Admin/Manager/Designer) |
| 4 | neurasutra-client | Vite + React/Vue | Client-facing portal |
| 5 | neurasutra-bot | Python (python-telegram-bot / whatsapp-web.js) | Messaging integrations |
| 6 | neurasutra-studio (Future) | Electron + Canvas/WebGL | Native design tool |
Tech Stack Summary
Proposed Stack
- Backend: Django (main) + FastAPI (utilities/workers)
- Frontend: Vite + PWA (Progressive Web App)
- Future Desktop: Electron/Chromium-based design tool
- Bots: Telegram/WhatsApp for client communication
- Storage: MinIO (S3-compatible) for images
- Database: PostgreSQL (main) + MongoDB (tags/metadata - optional)
- Queue: Celery/Dramatiq with Redis
Portals
- Admin Portal (internal)
- Managers Portal (internal)
- Designers Portal (internal)
- Client Portal (external, separate)
Internal portals can be unified into a single PWA with role-based UI.