Lección 53 — Monolito modular frente a microservicios

Las fronteras del monolito, hoy. Sin solutions.md hasta entregar.

Ejercicio 1 — La matriz honesta

1. Completa la tabla del §1 para TU contexto (equipo, volumen, cumplimiento) con NÚMEROS: ¿cuántos despliegues/semana tendrían 5 microservicios? ¿Cuánto costaría la saga en cada flujo (¿cuántas de tus features serían distribuidas)?
2. El caso a favor: escribe el mejor argumento REAL a favor de microservicios para TicketFlow (no el marketing): ¿cuál sería y qué tendría que pasar para que pesara más que su costo?
3. El caso a favor del monolito: el argumento contrario con los mismos datos: la decisión escrita en 5 líneas con su revisión (el ADR del 48).

Ejercicio 2 — La modularización

1. Reorganiza (o dibuja) tu repo en los 5 módulos del §2: ¿qué va en cada uno y qué sobra (¿el utils del 24? ¿el cajón de shared)? El mapa de módulos con su lenguaje propio (52: el ubicuo por contexto).
2. La interfaz pública: escribe el api.py de tickets y de payments (las funciones públicas y su tipo). ¿Qué se descubre al escribirla (¿funciones que cruzan módulos por debajo: los imports que la frontera obliga a subir)?
3. El test de frontera: implementa el test del CI (§2) que prohíbe from tickets.models en payments/ (y todas las combinaciones prohibidas). Corre el CI: ¿cuántos violadores cazó en TU repo? Mígralos a las interfaces públicas.

Ejercicio 3 — Los contratos entre módulos

1. El síncrono: el checkout (payments) llama tickets.reservar(): escribe el test de contrato entre módulos (la 35 aplicada al import: ¿la firma? ¿las excepciones? ¿el summary?). ¿Qué pasa si mañana la función cambia de firma — ¿quién lo caza?
2. El asíncrono: el evento PaymentSucceeded (payments→tickets vía outbox, 25/30): escribe el test del contrato del evento (¿payload mínimo? ¿quién lo consume y qué hace?). ¿Qué se pierde si lo haces síncrono (¿la transacción única? ¿el acoplamiento del receptor)?
3. La regla escrita: en docs/adr/, la regla de elección síncrono/async entre módulos (§3) con los 2 ejemplos del repo como caso de estudio. 8 líneas.

Ejercicio 4 — El umbral y el strangle

1. Los 5 umbrales (§4) aplicados a TicketFlow: ¿cuál dispara primero y con qué evento real (¿el PCI del 56? ¿el volumen ×10?)? Escribe el trigger del ADR con la condición medible.
2. El strangle simulado: planifica (49: fases con estimación) la extracción de payments: ¿qué fases (¿duplicar con flag? ¿canary? ¿destronar?) y cuánto cuesta CON la frontera del ejercicio 2 hecha vs SIN ella? Los dos números, la comparación.
3. El plan de salida: el día que payments se extrae: ¿qué cambia del repo (¿el outbox deja de ser tabla y pasa a stream externo? ¿la saga del 32 cruza la red?)? Lista los 5 cambios arquitectónicos que la extracción obliga (los que la frontera preparada ya mitigó).

Ejercicio 5 — La defensa de la decisión

1. El pitch al CTO imaginario que pide microservicios "porque escalamos": es la respuesta del 51: las métricas reales (¿cuántas réplicas usa hoy el monolito? ¿cuántas necesitaría por separado?) y la propuesta alternativa (¿el monolito modular + el trigger documentado?). Máx 10 líneas.
2. La pregunta del compañero nuevo: "¿por qué no microservicios?" — la respuesta en 3 frases con el enlace al ADR. El test: ¿la entiende sin contexto?
3. El cierre: tu regla personal de arquitectura en 3 líneas (¿el monolito primero? ¿la frontera antes que la física? ¿el trigger antes que la moda?) — pégala en tu onboarding (48).

Entrega

Pega la matriz con números, las interfaces públicas con el test de frontera, el ADR del umbral y el plan strangle comparado. Después: Lección 54 — Resiliencia.