Architecture Overview
DgiDgi is a multi-tenant SaaS platform built on a modern cloud-native architecture. This document provides a high-level overview of the system architecture, key components, and design principles.
Design Principles
- Multi-Tenant by Design: Complete tenant isolation at every layer
- Cloud-Native: Built for Cloudflare, Supabase, and Fly.io
- Edge-First: Global edge deployment for low latency
- Security-First: Defense in depth with multiple security layers
- Scalable: Horizontal scaling with stateless services
Infrastructure Stack
| Layer | Provider | Purpose |
|---|---|---|
| Edge & CDN | Cloudflare | Edge workers, DNS, static hosting, R2 storage |
| Database | Supabase | PostgreSQL with Row-Level Security |
| Compute | Fly.io | API servers, background workers |
| Queue | Upstash | Redis-based job queues |
| Auth | Clerk | Authentication and user management |
High-Level Architecture
Component Overview
Edge Layer (Cloudflare)
The edge layer handles all incoming traffic with global distribution:
- Edge Workers: Route requests to appropriate backends, handle CORS, rate limiting
- Pages: Host static SPA applications (client, platform, docs, marketplace)
- KV Storage: Distributed key-value store for rate limits and caching
- R2 Storage: S3-compatible object storage for files and attachments
- DNS: Managed DNS with automatic SSL certificates
Compute Layer (Fly.io)
The compute layer runs stateless services that can scale horizontally:
- API Server: Handles REST API requests, WebSocket connections
- Worker Pool: Processes background jobs (agent execution, LLM calls)
- Health Monitoring: Automatic restarts and load balancing
Data Layer (Supabase)
The data layer provides persistent storage with built-in security:
- PostgreSQL: Primary database with 100+ tables
- Row-Level Security: Tenant isolation at the database level
- Connection Pooling: Efficient connection management
- Migrations: Version-controlled schema changes
Queue Layer (Upstash)
The queue layer manages asynchronous job processing:
- Job Queues: Priority-based queues (high, normal, low)
- Dead Letter Queue: Failed job tracking and retry
- Pub/Sub: Real-time event distribution
Multi-Tenant Architecture
Every component is designed for multi-tenant isolation:
| Layer | Isolation Mechanism |
|---|---|
| API | JWT tokens with tenant ID claim |
| Database | Row-Level Security policies |
| Storage | Tenant-prefixed object keys (tenants/{id}/) |
| Queues | Tenant ID in job metadata |
| LLM Calls | Tenant-specific API keys and quotas |
| Runtime | Isolated sandbox containers |
Request Flow
A typical API request flows through the system as follows:
Scaling Characteristics
| Component | Scaling Model | Limits |
|---|---|---|
| Edge Workers | Auto-scale globally | Unlimited |
| API Servers | Horizontal (Fly machines) | Configurable |
| Workers | Horizontal (Fly machines) | 2-10 instances |
| Database | Vertical (Supabase plan) | Connection pooling |
| Redis | Managed (Upstash) | Auto-scale |