Proyectos
Casos de estudio de ingeniería.
Sistemas backend, arquitecturas en AWS, plataformas de voz y frameworks de integración que he diseñado, lanzado y operado. Cada caso de estudio cubre contexto, enfoque y resultado.
Operaciones de Homelab
Stack autohospedado detrás de Traefik + Authentik
Mi homelab en casa: Docker Compose, Traefik v3, Step-CA para certificados internos, Authentik forward-auth, más de 18 servicios. Proyecto de fin de semana que de alguna manera se convirtió en producción para mi hogar.
Este Sitio — Portafolio como Producto
Aplicación Next.js 14 con asistente RAG, pipeline i18n de LLM y currículum PDF multilingüe
## Problema Un currículum afirma la senioridad; no puede demostrarla. Quería un portafolio que fuera en sí mismo un sistema de producción: cada función una muestra de trabajo verificable que un reclutador pueda clicar, leer e interrogar. ## Mi rol Todo: producto, diseño, backend, frontend y operaciones — diseñado, construido y operado en solitario. ## Restricciones - El despliegue serverless no debe agotar las conexiones de Postgres, y las páginas públicas deben permanecer cacheables ISR detrás de estrictos encabezados de seguridad. - El contenido se envía en inglés, español y alemán sin necesidad de autorizar cada publicación tres veces. - El asistente de IA responde únicamente a partir de mi contenido real, dentro de un presupuesto diario de costos, y debe resistir la inyección de comandos. ## Arquitectura Next.js 14 App Router con TypeScript y Prisma sobre Postgres. El asistente es de recuperación aumentada: el contenido del sitio se fragmenta y se incrusta en pgvector, se recupera por pregunta y se responde con modelos de OpenAI — con defensas contra inyección de comandos, límites de tasa por IP, un presupuesto diario de tokens y reindexación impulsada por cron. Un pipeline de traducción LLM genera las locales en español y alemán con detección de obsolescencia basada en hash. La superficie de administración se encuentra detrás de credenciales de NextAuth más claves de WebAuthn bajo un CSP basado en nonce. El PDF del currículum se renderiza del lado del servidor con PDFKit en los tres idiomas. La búsqueda del blog utiliza la búsqueda de texto completo de Postgres; cada ruta emite metadatos canónicos/hreflang, JSON-LD, imágenes de Open Graph por ruta, un sitemap, RSS y llms.txt. ## Resultado El sitio que estás leyendo: un blog multilingüe y estudios de caso, un asistente de IA basado en mi propia escritura, y un currículum PDF listo para reclutadores — todo generado a partir de una única base de código y operado en producción. ## Lo que haría diferente Diseñaría el enrutamiento i18n desde el principio — adaptarlo significó que cada página pública ahora existe en dos árboles de rutas. Y pondría las métricas del proyecto en el esquema en lugar de en prosa para que puedan renderizarse como chips destacados.
Marco de Integración Omnicanal — Estudio de Caso de Trabajo
Un backbone de Factory Method para Slack, Teams, Google Chat y Webex en Espressive
## Problema Cada canal de chat empresarial — Slack, Microsoft Teams, Google Chat, Webex — comenzó como una integración a medida. Cuando el código de cumplimiento se ramifica en el canal, estás manteniendo N productos que se desvían bajo la presión de los plazos. ## Mi rol Diseñé e implementé el marco de integración basado en el Método de Fábrica y las utilidades de prueba compartidas en las que se basa cada adaptador de canal. ## Restricciones - Los canales difieren en modelos de autenticación, formas de carga útil y límites de tasa; las diferencias debían permanecer dentro de los adaptadores. - Las integraciones en vivo existentes debían seguir funcionando mientras el marco las reemplazaba por debajo. - Los patrones de seguridad por defecto (autenticación, MFA, manejo de secretos) eran requisitos indispensables para los clientes empresariales. ## Arquitectura Los adaptadores de canal normalizan cada mensaje entrante en un sobre común; un Método de Fábrica instancia el adaptador correcto por canal; el código de cumplimiento opera sobre intenciones y entidades y nunca se ramifica en el canal. Las utilidades de prueba compartidas proporcionan a cada nuevo adaptador el mismo conjunto de conformidad desde el primer día. ## Resultado Slack, Microsoft Teams, Google Chat y Webex funcionan en una sola infraestructura, y cada nuevo canal cuesta menos que el anterior. Cero vulnerabilidades críticas mantenidas en estas integraciones empresariales durante dos años. ## Lo que haría diferente Definir el esquema de intención compartido desde el primer día y versionarlo como una API; fusionar definiciones de intención divergentes más tarde es el camino costoso. Construir el adaptador al final: primero obtener el sobre compartido y la historia de pruebas correcta.
Agente de Voz IVR — Estudio de Caso Laboral
Conectando conversaciones asíncronas de chatbots en flujos IVR de Amazon Connect en Espressive
## Problema El agente de soporte virtual de Espressive fue construido para chat asíncrono, donde una respuesta de dos segundos se siente rápida. Una llamada telefónica es un canal en tiempo real y bloqueante: los que llaman escuchan cada salto en la tubería como silencio. La plataforma necesitaba un canal de voz sin reescribir el backend del chatbot existente. ## Mi rol Arquitecté y lideré la integración de principio a fin: enrutamiento de intenciones, orquestación de conversión de voz a texto/texto a voz a través de Amazon Connect, Amazon Lex, AWS Lambda y Polly, y la transferencia al cumplimiento existente. ## Restricciones - Los presupuestos de latencia de voz son implacables: los que llaman notan brechas de menos de un segundo que los usuarios de chat nunca ven. - El backend de cumplimiento asíncrono era infraestructura de producción compartida con cada canal de chat; no se podía bifurcar para voz. - Los requisitos de seguridad empresarial —autenticación, manejo de secretos— se aplicaban a cada nuevo salto. ## Arquitectura Amazon Connect captura audio y lo transmite a Lex para la resolución de intenciones; un puente de Lambda traduce entre el flujo IVR sincrónico y el backend de chatbot asíncrono, luego Polly sintetiza respuestas de vuelta a la llamada. Las búsquedas posteriores comienzan especulativamente al inicio de la expresión en lugar de después de la resolución de intenciones, y el viaje de un llamador se correlaciona a través de Connect, Lex, Lambda y APIs posteriores para que los rastros sobrevivan al límite del canal. ## Resultado Se lanzó como un canal de producción de la plataforma del agente de soporte virtual que ayudó a reducir el volumen de llamadas al servicio de asistencia en un 40–60%. ## Lo que haría diferente Diseñaría la correlación entre servicios desde el primer día en lugar de agregarla durante el endurecimiento: los rastros que mueren en un límite de canal no son rastros. Y presupuestaría para la semántica de cancelación por interrupción desde el principio: cada síntesis en curso se vuelve cancelable, lo que cambia los requisitos de idempotencia a nivel posterior.