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.
Latency <50ms global · 0 cold starts · pricing escalable · CPU isolated · WebCrypto nativo · DPA EU disponible
AWS Lambda · Vercel Edge · Fly.io
PostgreSQL battle-tested · Row-Level Security multi-tenant · pgvector embeddings · DPA RGPD + AEC Art. 28 firmable · backup point-in-time
AWS RDS · Neon · PlanetScale
HTTP-based (sin SDK lock-in) · idempotency keys · DLQ visible · retries con backoff · pricing per request
AWS SQS · Inngest · Trigger.dev
Mutex distribuido para evitar processing duplicate · HTTP-based · plan Free suficiente pre-revenue
Redis Cloud · Cloudflare KV (eventually consistent)
Único API oficial WhatsApp Business · escalable · templates pre-aprobados · webhooks fiables · DPA EU
Twilio WhatsApp · 360dialog · Ninguno (single point of failure aceptado)
GPT-4.1 mejor cost/quality 2026 · embeddings text-embedding-3-small competitivos · DPA disponible
Anthropic Claude · Gemini · Mistral · futuro Claude 4
Industry standard · PCI compliance gestionado · webhooks fiables · multi-currency · disputes manageable
Adyen · Mollie · Redsys (Spain-only)
Industry standard · source maps Workers OK · alertas Slack/email · session replays · DPA EU
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.
- 1Inbound WhatsAppPaciente envía mensaje a número WhatsApp Business clínica→ Meta envía webhook firmado HMAC-SHA256 a `/webhook-meta` Worker
- 2Webhook validationWorker valida firma HMAC + extrae payload + persiste raw event→ Persistencia inmediata `inbound_events` (RLS no-anon · audit trail completo)
- 3Enqueue processingQStash recibe job con idempotency_key + payload comprimido→ Mutex Redis lock per paciente_id (evitar processing concurrente same patient)
- 4RAG + LLM inferenceWorker consumer recupera contexto KB (pgvector similarity search) + history→ GPT-4.1 con system prompt brand voice + outputs guardrails (handoff triggers)
- 5Send response WhatsAppMeta Cloud API send template/free-form message + persist outbound log→ Si handoff trigger → emit Slack/email alert + skip auto-response (humano takes over)
- 6Observability + analyticsSentry capture errors · Cloudflare analytics tracks · Supabase aggregates KPIs→ Dashboard /admin clínica visible en tiempo real · alertas critical → founder phone
6 principios arquitectura
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.