Modelo C4

El modelo C4 describe un sistema en cuatro niveles de zoom — Contexto → Contenedor → Componente → Código — más una vista de Despliegue. Cada nivel añade detalle sin perder el hilo del nivel anterior.

Nivel 1 — Contexto del sistema

Quién usa MyBotBox y con qué se comunica.

flowchart TB
    Builder([Builder<br/>designs & runs workflows])
    Admin([Org Admin<br/>members · permissions · billing])
    MBB[["MyBotBox<br/>visual AI workflow platform"]]
    Firebase[Firebase<br/>auth + realtime]
    LLM[LLM Providers<br/>17 adapters]
    Integrations[90+ Integrations<br/>Slack · Gmail · GitHub · …]
    Stripe[Stripe<br/>subscriptions + usage]

    Builder --> MBB
    Admin --> MBB
    MBB --> Firebase
    MBB --> LLM
    MBB --> Integrations
    MBB --> Stripe

Nivel 2 — Contenedores

Las unidades desplegables que conforman la plataforma.

flowchart TB
    User([Builder])
    Edge[Route 53 → Firebase Hosting<br/>edge rewrite]

    subgraph CR ["Cloud Run — Next.js"]
        Web[Web App<br/>editor · dashboard · SSR]
        API[API Routes<br/>workflows · auth · billing]
        Exec[Executor<br/>DAG + 30 handlers]
    end

    Tasks[Cloud Tasks + 6 Functions<br/>async + polling]
    PG[(Cloud SQL<br/>PostgreSQL 17 + pgvector)]
    Redis[(Memorystore Redis<br/>rate-limit + cache)]
    GCS[(Cloud Storage)]
    Auth[Firebase Auth]
    FS[(Firestore<br/>realtime collab)]

    User --> Edge --> Web
    Web --> API
    API --> Exec
    API --> Tasks --> Exec
    API --> PG
    Exec --> PG
    API --> Redis
    API --> GCS
    Web --> Auth
    Web --> FS

Despliegue — Google Cloud

Dónde se ejecutan los contenedores. Los entornos de staging y producción son proyectos GCP separados; Firebase Hosting actúa como frontal de cada servicio Cloud Run.

flowchart TB
    User([User browser])
    DNS[AWS Route 53]
    FH[Firebase Hosting<br/>__session cookie only]

    subgraph STG ["Staging · ystudio-core · us-central1"]
        SRUN[Cloud Run: mybotbox-app<br/>min 1 · 80 concurrency]
        SVPC[VPC connector]
        SREDIS[(Memorystore Redis 7)]
        SSQL[(Cloud SQL · PostgreSQL 17)]
        STASK[Cloud Tasks + 6 Functions]
        SSEC[Secret Manager]
        SGCS[(Cloud Storage)]
    end

    subgraph PRD ["Production · mybotbox-prod · us-central1"]
        PRUN[Cloud Run: mybotbox-app]
        PSQL[(Cloud SQL · mybotbox-db)]
    end

    User --> DNS --> FH
    FH --> SRUN
    FH --> PRUN
    SRUN --> SVPC --> SREDIS
    SRUN --> SSQL
    SRUN --> STASK --> SRUN
    SRUN --> SSEC
    SRUN --> SGCS
    PRUN --> PSQL

Nivel 3 — Componentes (pipeline de seguridad de solicitudes)

Cada solicitud a la API pasa por las mismas validaciones reutilizables antes de que se ejecute cualquier lógica de negocio. Consulta Pipeline de solicitudes para ver el recorrido completo.

flowchart LR
    Caller([Caller]) --> MW[Middleware<br/>session · CSP]
    MW --> Guards[API Guards<br/>auth + workspace access]
    Guards --> Authn[Auth<br/>Firebase verify]
    Guards --> RBAC[RBAC<br/>entity-scoped grant]
    Guards --> RL[Rate Limiter<br/>sliding window]
    Guards --> Handler[Route Handler<br/>Zod-validated]
    Handler --> Exec[Executor]

Nivel 4 — Código (los dos contratos)

El nivel más bajo: los contratos de tipos a los que todo se conecta. Cada servicio externo es un puerto con adaptadores intercambiables elegidos según el entorno; cada bloque es un handler detrás de una única interfaz a la que el executor despacha.

classDiagram
    direction LR

    class EmailProvider {
        <<port>>
        +send(message) Result
    }
    class SendgridAdapter
    class ResendAdapter
    class AzureAdapter
    EmailProvider <|.. SendgridAdapter
    EmailProvider <|.. ResendAdapter
    EmailProvider <|.. AzureAdapter

    class BlockHandler {
        <<port>>
        +canHandle(block) bool
        +execute(ctx, block) BlockOutput
    }
    class AgentHandler
    class FunctionHandler
    class ApiHandler
    class RouterHandler
    BlockHandler <|.. AgentHandler
    BlockHandler <|.. FunctionHandler
    BlockHandler <|.. ApiHandler
    BlockHandler <|.. RouterHandler

Añadir un nuevo proveedor o tipo de bloque es aditivo — implementa el puerto, registra el adaptador, y los puntos de llamada existentes permanecen sin cambios. Esto es lo que mantiene la plataforma intercambiable y autoalojable.