Components Overview¶
The Sartiq platform is built from three main application components, each with distinct responsibilities. This section provides technical deep-dives into each component's architecture.
Component Summary¶
| Component | Role | Tech Stack |
|---|---|---|
| Web Application | User interface | Next.js 14, React 18, TypeScript |
| Backend API | Business logic, orchestration | FastAPI, Python 3.12, Celery |
| Compute Server | AI inference orchestration | FastAPI, Celery, Python |
| Internal Tools | Subject creation, video generation | Varies |
For deployment details (where each component runs), see Infrastructure.
Architecture Diagram¶
flowchart TB
subgraph Frontend [Web Application]
Webapp[Web App]
end
subgraph Backend [Backend Service]
API[API]
BE_Workers[Workers]
BE_DB[(Database)]
BE_Redis[(Redis)]
end
subgraph Compute [Compute Service]
ComputeAPI[Compute API]
CS_Workers[Workers]
CS_DB[(Database)]
CS_Redis[(Redis)]
end
subgraph External [External]
AI[AI Providers]
end
subgraph Storage [Content Delivery]
Store[(Storage)]
CDN[CDN]
end
Webapp <--> API
Webapp <-.-> CDN
API --> BE_Workers
API <--> BE_DB
API <--> BE_Redis
API --> ComputeAPI
ComputeAPI --> CS_Workers
ComputeAPI <--> CS_DB
ComputeAPI <--> CS_Redis
CS_Workers --> AI
AI --> Store
ComputeAPI --> API
Store --> CDN
Data Stores¶
Each service maintains its own data stores for isolation and independent scaling.
| Service | Database | Cache/Queue |
|---|---|---|
| Backend | Users, products, shootings, generations | Cache, sessions, pub/sub |
| Compute Server | Tasks, workflows, provider state | Task queues, job results |
Communication Patterns¶
Synchronous (Request/Response)¶
- Webapp → Backend: REST API calls for CRUD operations
- Backend → Compute: HTTP requests for workflow submission
- Webapp → Backend: WebSocket connection for real-time updates
Asynchronous (Event-Driven)¶
- Backend → Workers: Task queue for background jobs
- Compute → Workers: Task queue for AI inference
- Compute → Backend: Redis event stream for task lifecycle events
- Backend → Compute: REST API to fetch task results on completion
- Backend → Webapp: Pub/sub → WebSocket notifications
Data Flow Overview¶
sequenceDiagram
participant User
participant Webapp
participant Backend
participant Redis
participant Compute
participant AI
participant Storage
Note over User,Storage: Product Upload
User->>Webapp: Upload product
Webapp->>Backend: POST /products
Backend->>Storage: Save images
Backend-->>Webapp: Product created
Note over User,Storage: Generation
User->>Webapp: Start generation
Webapp->>Backend: POST /generations
Backend->>Compute: POST /tasks
Compute-->>Backend: Task ID
Compute->>AI: Generate content
AI-->>Compute: Result
Compute->>Storage: Save content
Compute->>Redis: Emit task.completed
Redis-->>Backend: Event received
Backend->>Compute: GET /tasks/{id}/result
Backend-->>Webapp: WebSocket
Webapp-->>User: Display result
Component Details¶
Web Application¶
The frontend application providing the user interface for managing products, configuring shootings, and reviewing generated content.
Key Responsibilities:
- Product and asset management UI
- Shooting configuration interface
- E-Commerce Generator (main generation interface)
- Gallery for reviewing generated content
- Real-time progress updates via WebSocket
Read the Web Application deep-dive →
Backend API¶
The central orchestration layer handling business logic, data management, and coordination between all system components.
Key Responsibilities:
- REST API for all platform operations
- Business logic and validation
- Database operations via SQLModel/SQLAlchemy
- Background job processing via Celery
- Real-time updates via WebSocket and pub/sub
- Integration with Compute Server
Read the Backend API deep-dive →
Compute Server¶
The AI inference orchestration layer managing communication with multiple AI providers and executing complex generation workflows.
Key Responsibilities:
- Provider abstraction for 11+ AI services
- Workflow orchestration (multi-step DAG execution)
- Task queuing and prioritization
- Result processing and storage
- Event emission to Redis for task lifecycle updates
Read the Compute Server deep-dive →
Internal Tools¶
Supporting applications used internally for specialized tasks.
Identiq - Subject creation and identity management Movieq - Video generation platform
Technology Decisions¶
Why FastAPI?¶
- Async support for high concurrency
- Automatic OpenAPI documentation
- Pydantic integration for validation
- Type hints throughout
Why Celery?¶
- Proven distributed task queue
- Redis broker integration
- Task prioritization and routing
- Retry and error handling
Why Next.js?¶
- Server-side rendering for SEO
- App Router for modern React patterns
- API routes for BFF pattern
- Excellent TypeScript support
Related Documentation¶
- Data Flows - How data moves through components
- Infrastructure - Deployment details and cloud providers
- API Documentation - Endpoint reference