Arquitectura
Instancia dedicada por tenant
Sección titulada «Instancia dedicada por tenant»Bongga no usa una base de datos compartida. El control-plane provisiona, vía Terraform,
un stack aislado por workspace: Postgres + RabbitMQ + api-gateway + flow-engine + ai-service
- dashboard-ui. Localmente usa el provider
kreuzwerker/docker(Podman); en producción, DigitalOcean.
landing (bongga.dev) ──► signup ──► control-plane ──► Terraform ──► stack del tenant │ │ops.bongga.dev (ops-portal) ────────────┘ ▼ {slug}.bongga.dev (Traefik) │ api-gateway ─ valida JWT (HS256) → SET ROLE bongga_app + workspace_id GUC ├──► flow-engine (RabbitMQ → ejecuta nodos del canvas; DLQ) └──► ai-service (RAG + LLM con la API key del cliente — BYOK)Componentes
Sección titulada «Componentes»- control-plane — plano de operación y sistema de registro: provisioning, lifecycle (provision/suspend/resume/deprovision/resize), auth central, billing/suscripciones.
- Traefik — enruta
{slug}.bongga.deval stack del tenant yops.bongga.deval control-plane. - Mensajería — RabbitMQ con dead-letter queue: los mensajes envenenados se reintentan con límite y se mandan a DLQ en vez de reintentar infinito.
- Observabilidad — OTel Collector + Prometheus + Loki + Tempo + Grafana (stack local en
docker-compose). La telemetría es opt-in para no inundar logs cuando no hay collector.
Clean Architecture
Sección titulada «Clean Architecture»Cada servicio Go/Python sigue capas estrictas:
domain/ entidades, value objects, interfaces puras — cero dependencias externasapplication/ casos de uso — orquesta el dominioinfrastructure/ adaptadores: HTTP, DB, RabbitMQ, APIs externasLas integraciones externas (canales, IA, voz, pagos) son plug-and-play vía Strategy + Factory + Adapter: agregar un proveedor es un adapter nuevo, sin tocar la lógica.