Lección 55 — Escalado

Los peldaños, medidos. Sin solutions.md hasta entregar.

Ejercicio 1 — La ley cero

1. La auditoría del estado: lista TODO el estado de tu app (memoria, ficheros, caché local, globals): ¿qué viola la ley cero? ¿Qué es tolerable (¿el breaker por réplica?) y qué no (¿el caché local en prod?).
2. La prueba: con 2 réplicas (compose scale o 2 procesos), mata la réplica A a mitad de un checkout continuo (k6 o loop): ¿el usuario nota? ¿la sesión del token (18) sigue? Documenta la cronología.
3. El estado escondido cazado: busca lru_cache, @cache, globals mutables y /tmp en tu código: cada hallazgo con su veredicto (¿tolerable con TTL? ¿bug en réplicas?).

Ejercicio 2 — Las réplicas

1. Monta la réplica de lectura (el gestionado del 42 o el compose: pg_basebackup en dev) y el DATABASE_ROUTERS del §2. Verifica: el browse va a la réplica (pg_stat_activity por DB), el POST al primario.
2. El lag: escribe el test del read-your-writes: crea la reserva → consulta "mis reservas" INMEDIATAMENTE → ¿la ve? Sin la cura: ¿el lag simulado (con pg_sleep en la réplica o el delay del router fake) la esconde? Con la cura (el hint del request): ¿aparece?
3. La medición: k6 (36) con el browse 70% sobre: primario solo vs primario+réplica: pega los dos p95 y el uso del primario. ¿Cuánto respira el primario?

Ejercicio 3 — El cuello de escritura

1. Las 4 reducciones del §3 sobre TU checkout: verifica cada una (¿el bulk UPDATE? ¿la pasarela fuera de la TX? ¿los índices mínimos? ¿el skip_locked?) y mide con pg_stat_statements (36): ¿cuánto del total_time de escritura queda?
2. El lock-wait como métrica: instrumenta pg_locks/pg_stat_activity (el wait_event del lock) durante la meseta: ¿cuántos esperan y por cuánto? La métrica lock_wait_ms en el dash del 46: la que decide el particionado.
3. El plan escrito: con los números del ejercicio 2-3: ¿a qué volumen (¿cuántas reservas/min?) activarías cada peldaño siguiente (¿partición? ¿shard?)? El documento de la escalera con SUS triggers medibles.

Ejercicio 4 — La partición

1. El caso del curso: reproduce la contención por recurso: 2 eventos grandes (20k asientos cada uno) con 100 compradores simultáneos SOBRE EL MISMO evento y 100 repartidos: ¿la latencia del repartido peca por el mismo-evento (¿el lock-wait compartido?)? Pega los números.
2. Implementa la partición por evento (el LIST del §4) y repite la prueba: ¿el repartido se libera? ¿El mismo-evento sigue igual (la contención es POR evento: la partición no la toca — la cura del mismo-evento es el turnstile del 36)?
3. El contrato de la partición: el test que exige el WHERE event_id en las queries de reservas (¿el plan del 09 con el prune?) y el job del 31 que crea la partición del próximo evento (con la prueba: el evento sin partición: ¿el insert falla o va al default? decide y documenta).

Ejercicio 5 — La escalera completa

1. El documento docs/scaling.md: la escalera del §5 con TUS números (los triggers medibles de cada peldaño según los ejercicios 2-4). El documento que el CTO del 53 pide.
2. El anti-patrón cazado: el CTO imaginario pide "sharding por si acaso": la respuesta del 51/53 con TU número real (¿cuánto aguanta el primario HOY? ¿el trigger está a ×10 de eso?). Máx 8 líneas.
3. El cierre del módulo: el mapa final de TicketFlow escalado (ASCII): réplicas, caché, colas, partición, el edge del 42 y el breaker del 54 — dónde vive cada pieza del curso en el sistema escalado. Este mapa es la foto de TODO el curso.

Entrega

Pega la auditoría del estado, los p95 de réplicas, el test del lock-wait con la métrica y el mapa final escalado. Después: Lección 56 — Cumplimiento.