The Professor
Stack: Todo el curso · Proyecto: TicketFlow completo Estado: Publicada — la defensa del backend y el postmortem simulado Prerrequisito: Lección 56 — Cumplimiento
Objetivos
- Consolidar TicketFlow como producto terminado: el sistema completo con sus garantías, su observabilidad y su documentación.
- Defender el proyecto: la presentación técnica (el porqué de cada decisión) y el pitch de negocio (51) en dos audiencias.
- Sobrevivir al postmortem simulado: el incidente inesperado que el examen inyecta y tu respuesta con el método del 47.
1. El alcance del examen: qué se defiende
El proyecto final no es "escribe más código": es DEFENDER lo que el curso construyó. Las tres partes: (1) la defensa técnica (30 min): el recorrido del sistema con los ADRs — el porqué del lock (10), del outbox (25), de la saga (32), del DDD parcial (52), del monolito modular (53); cada decisión con su trade-off y su trigger de revisión; (2) el pitch de negocio (10 min): el mapa del dinero (51) y la traducción sin jerga — el dueño del negocio debe entender qué compró; (3) el postmortem simulado (30 min): el incidente inyectado (§4) resuelto en vivo con el protocolo del 47.
El material de la defensa (lo que se entrega): el repo completo (el código + tests + pipeline), los docs (el onboarding del 48, el runbook del 47, el mapa del 56), y el one-pager final: el mapa del sistema (el 55) con las 10 garantías del negocio.
2. Las 10 garantías: la lista que responde "¿qué compré?"
La síntesis de todo el curso en la lista que el examen verifica (cada garantía con su lección y su test):
| # | Garantía | Lección | El test que la póliza |
|---|---|---|---|
| 1 | Un asiento, un ganador (cualquier concurrencia) | 10 | el test de N=10 (34) |
| 2 | Ningún evento de dominio se pierde (outbox) | 25 | el test de atomicidad (34) |
| 3 | El dinero nunca se mueve dos veces (idempotencia + saga) | 14/32 | la saga reanudable (34) |
| 4 | Todo error es un problem+json con trace_id | 26 | assert_problem (35) |
| 5 | La config es el entorno; la imagen es una | 27/40 | la misma imagen ×3 (27) |
| 6 | Cada contrato cambiado rompe un test antes que al front | 35 | el contract guard (28) |
| 7 | El pico de preventa degrada con gracia y se recupera | 36/54 | el game day del 54 |
| 8 | Cada incidente es diagnosticable en <15 min | 45/46 | el game day del 46 |
| 9 | Cada decisión tiene su ADR con trigger de revisión | 48 | el índice de ADRs |
| 10 | El dato personal tiene base, retención y derechos | 23/56 | el DPO interno (56) |
La defensa recorre la lista: cada fila es 2 minutos de "qué garantiza, cómo, y dónde está la prueba". El examinador (el profesor, un colega, o tú mismo en 6 meses) elige 3 filas al azar y las exige con demo.
3. La defensa técnica: el formato que enseña
El formato de la defensa (30 min, el método del curso): (1) el recorrido del REQUEST (el checkout de punta a punta: HTTP → capas (24) → TX (10) → outbox (25) → saga (32) → cola (29) → email — la historia del 32 con el sistema real); (2) el recorrido del FALLO (el breaker (54), el UNKNOWN (32), el postmortem del 47: el sistema defendido por lo que hace cuando duele); (3) los 3 ADRs más discutidos (el examinador pregunta "¿por qué no K8s? ¿por qué no Kafka? ¿por qué DDD parcial?": las respuestas son los ADRs con su trigger). La regla del examen: la respuesta "no lo sé, pero así lo averiguaría" (el método del 37/47) puntúa MÁS que el farol — el oficio es el método, no la memoria.
4. El postmortem simulado: el incidente inyectado
El examen inyecta UN incidente no anunciado (el pool del examinador): (a) la pasarela responde lento (5 s) durante el pico; (b) el outbox se atasca (el poller muere silencioso); (c) un deploy introduce un N+1 en el listado; (d) el Redis se llena y evicta las claves del caché; (e) un cliente repórtate "pagué dos veces" (el cobro duplicado: la pesadilla del 14). La respuesta esperada (el protocolo del 47 EN VIVO): confirmar (el dash del 46), acotar (trace/log del 45), mitigar (flag/rollback/breaker), localizar (las herramientas del 37), explicar (el postmortem en 10 min con acciones). El tiempo: 30 min con la cronología escrita.
La preparación del simulacro (el ejercicio 3): tú INYECTAS los 5 incidentes en TU entorno y los resuelves tú mismo con cronología — el examen es el simulacro hecho delante de testigos. La lista de los 5 con su arma: (a) → timeout+breaker+SLO; (b) → heartbeat del 46; (c) → el flamegraph del 37; (d) → el FLUSHALL del 38 + el maxmemory; (e) → la idempotencia del 14 + el ledger del 08.
5. El cierre del curso: lo que queda después
El curso termina; el oficio sigue. Lo que queda instalado: el sistema (TicketFlow con sus 10 garantías), el MÉTODO (medir antes de optimizar, la red de tests antes del refactor, el ADR antes de la decisión, el postmortem después del incidente), y los HÁBITOS (la suite rápida en cada guardado, el PR con self-review, el game day trimestral, la revisión de la factura y del backlog con el negocio). La recomendación final del profesor: el siguiente proyecto (el tuyo, no el del curso) arranca con las primeras 3 lecciones del módulo 12 en la cabeza: dominio primero (52), fronteras modulares desde el día 1 (53), el ADR desde la primera decisión (48) — y el resto del curso como la caja de herramientas a la que volver por peldaño, no de memoria: el índice (la portada del sitio) ES el mapa.
Autoevaluación
- Las tres partes del examen (defensa/pitch/postmortem): ¿qué material entrega cada una y qué pregunta-arma tiene la defensa?
- Recorre las 10 garantías: ¿cuál te costaría más demostrar HOY y qué le falta (¿el test? ¿el runbook? ¿el número)?
- ¿Por qué "no lo sé, pero así lo averiguaría" puntúa más que el farol y qué herramientas nombra esa respuesta?
- De los 5 incidentes del pool: ¿cuál es tu peor escenario y cuál es SU arma (¿el timeout, el heartbeat, el ledger...)?
- ¿Qué tres hábitos del curso sobreviven al proyecto terminado y cuál es la recomendación final del profesor?
Continúa con los ejercicios. Las solutions.md solo tras intentarlo.