Asincronía, eventos y tiempo real

Inicia sesión para guardar tu progreso en todos tus dispositivos. Mientras tanto, se guarda en este navegador.

Por qué importa

Enviar un email, generar un PDF, llamar a un agente LLM, procesar un webhook: si esto se ejecuta dentro de la petición del usuario, la petición es lenta, supera los límites de tiempo de serverless y pierde trabajo ante cualquier caída. El diseño asíncrono es la forma en que los sistemas serios se mantienen rápidos y no pierden nada.

Resultados de aprendizaje

1. Mover el trabajo lento o poco fiable a jobs en segundo plano duraderos.
2. Elegir entre colas, pub/sub y diseños orientados a eventos.
3. Manejar webhooks de forma segura (verificar, deduplicar, confirmar rápido, procesar en asíncrono).
4. Coordinar flujos de varios pasos con sagas y el patrón outbox.
5. Elegir el transporte en tiempo real adecuado: WebSockets, SSE o long polling.
6. Ejecutar tareas programadas que puedan solaparse y saltarse sin problemas.

Lecciones

8.1 Colas y workers (15)

Patrón: la petición valida, escribe la intención en la base de datos, encola el job y devuelve 202 Accepted con un ID de job. El worker procesa, actualiza el estado y notifica.

• En la práctica, la entrega es at-least-once (al menos una vez): diseña cada handler de jobs para que sea idempotente.
• Opciones: gestionadas (SQS, Cloud Tasks), basadas en Redis (BullMQ), basadas en Postgres (pg-boss, Graphile Worker), motores de workflows duraderos (Inngest, Trigger.dev, Temporal).
• Los motores de workflows duraderos suelen ser la mejor opción para agentes de IA: cada paso se guarda como checkpoint y se reintenta de forma independiente.

8.2 Pub/Sub y arquitectura orientada a eventos (16, 17)

• Cola: un mensaje, un consumidor (una tarea por hacer).
• Pub/Sub: un evento, muchos suscriptores independientes (un hecho que ocurrió: order.paid).
• Orientada a eventos: los servicios reaccionan a eventos en lugar de llamarse directamente. Desacoplada, pero más difícil de trazar; exige esquemas para los eventos y buena observabilidad.
• Nombra los eventos en pasado; versiona los esquemas de eventos; incluye un ID de evento para deduplicar.

8.3 Transacciones distribuidas, outbox y sagas (18, 19)

• No puedes tener una sola transacción ACID que abarque tu base de datos, Stripe y un proveedor de email.
• Transactional outbox: en la misma transacción de base de datos, escribe el cambio de negocio y una fila en el outbox; un relay publica las filas del outbox. Evita el "guardado pero nunca publicado" o el "publicado pero no guardado".
• Saga: una secuencia de pasos locales, cada uno con una acción compensatoria (reservar stock → cobrar la tarjeta → crear el envío; si el envío falla: reembolsar, liberar el stock). Orquestada (un coordinador) o coreografiada (eventos).
• El two-phase commit existe, pero rara vez es apropiado en sistemas web modernos.

8.4 Webhooks (101)

Al recibir:

1. Verifica la firma (HMAC con secreto compartido) y el timestamp para frenar falsificaciones y ataques de repetición (replay).
2. Deduplica por el ID de evento del proveedor (restricción única).
3. Confirma rápido (2xx en pocos segundos) y luego procesa en un job en segundo plano.
4. Maneja la entrega fuera de orden; ante la duda, consulta el estado actual al proveedor. Al enviar: firma los payloads, reintenta con backoff, ofrece a los clientes un log de entregas y la opción de reenviar, y protégete del SSRF en las URLs que proporcionan los clientes.

8.5 Cron jobs (21)

• Asume que una ejecución puede saltarse, retrasarse o ejecutarse dos veces. Haz que los jobs sean idempotentes y reanudables.
• Evita solapamientos con un lock (advisory lock de la base de datos).
• Procesa por lotes con checkpoints, no en una única transacción gigante.
• Monitoriza con un heartbeat tipo "dead man's switch" (alerta si el job no se ejecutó).
• Guarda los horarios en UTC; cuidado con el horario de verano en otros mercados.

8.6 Transportes en tiempo real (22, 23, 24)

Lab 8: Hazlo asíncrono

1. Mueve tu operación síncrona más lenta (llamada al LLM, PDF, email) a un job duradero con consulta de estado (polling) o progreso por SSE.
2. Implementa un receptor de webhooks (Stripe o Resend) con verificación de firma, deduplicación y procesamiento asíncrono. Reenvía el mismo evento 10 veces; demuestra que solo produce un efecto.
3. Implementa una saga de 3 pasos con compensación; inyecta un fallo en el paso 3; demuestra el rollback.
4. Añade un cron job con lock contra solapamientos y alerta por heartbeat.

Definition of Done

• Ninguna petición de cara al usuario realiza trabajo que pueda superar unos pocos segundosEvidencia
• Todos los handlers de jobs son idempotentes, con reintentos y DLQEvidencia
• Webhooks: firma verificada, deduplicados, procesados en asíncrono (probado con replay)Evidencia
• Outbox o saga implementados en cualquier proceso de negocio que cruce sistemasEvidencia
• Cron jobs con lock, idempotentes y monitorizados con heartbeatEvidencia
• Salida del LLM enviada en streaming por SSEEvidencia

Paquete de prompts de IA

• "Identifica todas las operaciones de los handlers de peticiones que llaman a un servicio externo o que podrían tardar más de 1 segundo. Propón cuáles mover a jobs en segundo plano."
• "Implementa este handler de webhooks: verifica la firma con comparación en tiempo constante, rechaza timestamps caducados, deduplica por event id con una restricción única, encola el procesamiento y devuelve 200."