ASGI (Uvicorn) + Redis pubsub. No mires solutions.md hasta entregar.
Ejercicio 1 — La matriz de decisiones
- Para cada caso, elige protocolo y justifica en 2 líneas: (a) API pública para integradores; (b) comunicar billing-service con reservation-service internos; (c) app móvil que muestra dashboard configurable; (d) chat de soporte en vivo; (e) notificación de "tu entrada está lista".
- ¿Cuál de los cinco casos NO merece nada nuevo hoy en TicketFlow y por qué?
Ejercicio 2 — SSE mínimo viable
- Levanta el endpoint SSE de la lección (o uno simulado que publique cada 2s el número de asientos libres) con
python manage.py runserver(ASGI) y consúmelo concurl -N http://.../events/{uuid}/availability/stream/. ¿Ves los eventos llegar? - Publica desde otro proceso (
redis-cli PUBLISH avail:42 '{"free": 41}') y verifica la recepción en el stream. - Añade keepalive: evento
: pingcada 15s. ¿Por qué sin ello Nginx/proxies cortan la conexión?
Ejercicio 3 — Del evento de reserva al push
- Conecta
reservar()(10): tras crear la reserva,PUBLISH avail:{event_id} {"free": N}. Verifica que tu curl del ejercicio 2 recibe el update. - Pregunta de diseño: ¿publicas dentro de
transaction.atomic()o después del commit? ¿Qué recibe el cliente si te equivocas de lado? (pista: rollback).
Ejercicio 4 — Carga de conexiones
- Abre 200 streams SSE (script con
curl -Nen paralelo ohttpxasync). Mira memoria del proceso (05) yss -tan(05): ¿cuántas conexiones ESTAB? - Cambia el keepalive a 1s y repite: ¿cambia algo medible? ¿Qué ocurre con 2.000 conexiones y Uvicorn default (pista: límites de ficheros abiertos —
ulimit -n)?
Ejercicio 5 — La decisión escrita (mini-ADR)
Escribe el ADR-0007 de TicketFlow: "Disponibilidad en vivo vía SSE" — contexto (qué pain real), decisión, alternativas descartadas (polling con números, WS), consecuencias operativas (conexiones, proxies, reconexión Last-Event-ID).
Entrega
Pega el curl del stream, el ADR y números de carga. Después: Lección 17 — Webhooks y APIs de terceros.