Arquitectura técnica · evidence pack CTO/DPO

Stack edge-first multi-tenant EU

8 componentes · todos battle-tested · stack edge-first sub-50ms · multi-tenant RLS strict · EU-resident por defecto · idempotent · observable. Evidence pack para CTO/DPO clínicas Enterprise.

8 componentes principales

Stack actual producción. Cada componente listed con role · vendor · ubicación · por qué elegido · alternativas evaluadas. Sin black box · total transparencia técnica.

Cloudflare Workers
API edge runtime + cron + queues consumer
Vendor
Cloudflare (account `aiempire26`)
Ubicación
Edge global · DC más cercano al usuario
Por qué elegido

Latency <50ms global · 0 cold starts · pricing escalable · CPU isolated · WebCrypto nativo · DPA EU disponible

Alternativas evaluadas

AWS Lambda · Vercel Edge · Fly.io

Supabase PostgreSQL
Database principal + pgvector + RLS + Realtime
Vendor
Supabase (org AI Empire · plan Pro)
Ubicación
EU West (Frankfurt) · RGPD compliant
Por qué elegido

PostgreSQL battle-tested · Row-Level Security multi-tenant · pgvector embeddings · DPA RGPD + AEC Art. 28 firmable · backup point-in-time

Alternativas evaluadas

AWS RDS · Neon · PlanetScale

Upstash QStash
Queue durable + scheduled jobs + retries
Vendor
Upstash (eu-central-1)
Ubicación
EU Central · Frankfurt
Por qué elegido

HTTP-based (sin SDK lock-in) · idempotency keys · DLQ visible · retries con backoff · pricing per request

Alternativas evaluadas

AWS SQS · Inngest · Trigger.dev

Upstash Redis
Distributed mutex + rate-limit + cache
Vendor
Upstash Redis (eu-west-1 · `empire-mutex`)
Ubicación
EU West · Ireland
Por qué elegido

Mutex distribuido para evitar processing duplicate · HTTP-based · plan Free suficiente pre-revenue

Alternativas evaluadas

Redis Cloud · Cloudflare KV (eventually consistent)

Meta WhatsApp Cloud API
Canal mensajería paciente principal
Vendor
Meta (account `joconar6`)
Ubicación
EU + global
Por qué elegido

Único API oficial WhatsApp Business · escalable · templates pre-aprobados · webhooks fiables · DPA EU

Alternativas evaluadas

Twilio WhatsApp · 360dialog · Ninguno (single point of failure aceptado)

OpenAI API
LLM principal (GPT-4.1 + embeddings)
Vendor
OpenAI (account `aiempire26` · Tier 1)
Ubicación
US · EU residency opt-in
Por qué elegido

GPT-4.1 mejor cost/quality 2026 · embeddings text-embedding-3-small competitivos · DPA disponible

Alternativas evaluadas

Anthropic Claude · Gemini · Mistral · futuro Claude 4

Stripe Payments
Pagos + suscripciones + connectors
Vendor
Stripe (`acct_1SyAX1C7ONXDNigb`)
Ubicación
EU · UK · global
Por qué elegido

Industry standard · PCI compliance gestionado · webhooks fiables · multi-currency · disputes manageable

Alternativas evaluadas

Adyen · Mollie · Redsys (Spain-only)

Sentry
Error monitoring + performance + RCA
Vendor
Sentry (`de.sentry.io` org)
Ubicación
EU · Germany
Por qué elegido

Industry standard · source maps Workers OK · alertas Slack/email · session replays · DPA EU

Alternativas evaluadas

DataDog · Better Stack · LogRocket

Data flow · request lifecycle

6 pasos desde paciente envía WhatsApp hasta respuesta bot/handoff. Diagrama mental para entender end-to-end · útil para CTO/security reviews.

  1. 1
    Inbound WhatsApp
    Paciente envía mensaje a número WhatsApp Business clínica
    Meta envía webhook firmado HMAC-SHA256 a `/webhook-meta` Worker
  2. 2
    Webhook validation
    Worker valida firma HMAC + extrae payload + persiste raw event
    Persistencia inmediata `inbound_events` (RLS no-anon · audit trail completo)
  3. 3
    Enqueue processing
    QStash recibe job con idempotency_key + payload comprimido
    Mutex Redis lock per paciente_id (evitar processing concurrente same patient)
  4. 4
    RAG + LLM inference
    Worker consumer recupera contexto KB (pgvector similarity search) + history
    GPT-4.1 con system prompt brand voice + outputs guardrails (handoff triggers)
  5. 5
    Send response WhatsApp
    Meta Cloud API send template/free-form message + persist outbound log
    Si handoff trigger → emit Slack/email alert + skip auto-response (humano takes over)
  6. 6
    Observability + analytics
    Sentry capture errors · Cloudflare analytics tracks · Supabase aggregates KPIs
    Dashboard /admin clínica visible en tiempo real · alertas critical → founder phone

6 principios arquitectura

Edge-first · sub-50ms latency
Cloudflare Workers ejecuta en DC más cercano al usuario. Sin cold starts · sin lambda startup · respuesta sub-50ms global. Pacientes españoles tocan DC Madrid o París.
Multi-tenant RLS strict
Supabase Row-Level Security: cada query verifica clinica_id automáticamente. Zero cross-tenant data leak posible. Tests automáticos verifican cada migration que policy RLS sigue activa.
Durable workflow · zero message loss
QStash queue durable + idempotency keys + retries con backoff. Si processing falla, se reintenta. Si retry agota, va a DLQ visible en /status. Cero mensajes perdidos · ever.
EU-resident data por defecto
Supabase EU West (Frankfurt) · Upstash EU Central · Sentry EU Germany · Cloudflare DPA EU. Solo OpenAI tiene componente US (opt-in EU residency en roadmap).
Idempotent external calls
Toda llamada externa (Meta · OpenAI · Stripe · Cal.com) usa idempotency key (UUID-v4 derived from inbound event). Doble processing → mismo result · sin side effects duplicados.
Observable end-to-end
Sentry captura excepciones · Cloudflare logs HTTP · Supabase logs queries · UptimeRobot polling 60s · alertas Slack/email founder en <2min. Visibility total sin debug print().
Doctrine + ADRs · 41 decisions documentadas

Cada decisión arquitectural significativa está documentada como ADR (Architecture Decision Record) en el repo público. 41 ADRs cubren: cron schedule architecture · brand voice quality gate · memory MCP policy · hardening sprint · pillar pages strategy · enterprise trust pages · calculator suite strategy.

Si tu CTO/security team quiere revisar las decisiones específicas que tomamos (y por qué descartamos alternativas) lo encuentran en docs/architecture/DECISIONS.md · el archivo más leído por auditores externos.

Cumulative metrics públicas en EXECUTION_LOG.md: lo que se ha hecho · lo que está en curso · lo que está bloqueado pre-tracción. Cero "stealth mode" · cero info bajo NDA innecesario.

¿Quieres deep-dive técnica?

Si tu CTO/security team necesita revisar arquitectura específica (RLS implementation · pgvector RAG flow · cost-cap LLM · breaker Meta · SLA contractual), reservamos 60min sesión técnica. Compartimos repo bajo NDA si encajas Enterprise tier.