En 01-06 abrimos un monolito Python con una base de datos PostgreSQL, un despliegue de martes y jueves y cinco síntomas que lo empujaban a cambiar, y dibujamos una arquitectura objetivo con una tabla que remitía cada componente a una lección futura. Treinta y ocho lecciones después, todas esas casillas están construidas: gRPC y Kafka, sagas y réplicas, Cassandra y Redis, Spark y Flink, Keycloak y Vault, Prometheus y Kubernetes, MQTT y WebSockets, Terraform y Lambda, la CDN y la cola SQLite de la furgoneta. Esta última lección no añade ninguna pieza nueva: junta las que hay. Primero la arquitectura completa en un solo diagrama y la tabla de 01-06 cerrada; después el recorrido de un pedido de Ana desde su navegador hasta la factura en S3, con todo lo que deja a su paso en trazas, métricas y auditoría; luego las seis decisiones de arquitectura como ADR, con sus alternativas rechazadas y sus consecuencias; los cinco síntomas de 01-06 con su resolución; la evaluación de la plataforma con los criterios del propio curso (falacias, consistencia por dato, SLO, RPO/RTO, controles de seguridad); lo que queda fuera; el proyecto que el alumno puede construir en su portátil con hitos verificables; y una guía para seguir profundizando. Los ejercicios son de integración: incorporar un dominio nuevo, analizar un incidente de extremo a extremo y recortar la arquitectura para tres personas. La conclusión cierra el curso.

1. La arquitectura final de Kilómetro Cero
2. La tabla de 01-06, cerrada
3. El recorrido de un pedido de Ana de extremo a extremo
4. Lo que el pedido deja a su paso: trazas, métricas y auditoría
5. Las decisiones de arquitectura como ADR
6. Los cinco síntomas de 01-06, revisitados
7. Evaluación con los criterios del curso
8. Lo que queda fuera y siguientes pasos
9. El proyecto: Kilómetro Cero reducido en docker-compose
10. Guía de estudio
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

El diagrama tiene una pieza que hasta ahora solo estaba prometida: el BFF de la app de repartidores, anunciado en 06-05 y situado en 08-01. Es un servicio pequeño, propiedad del equipo de reparto, detrás de Kong, que compone la pantalla de inicio de la app (ruta del día de reparto, estado de los pedidos de esa ruta de pedidos, nombres y fotos de los productos de catalogo) en una sola respuesta, con llamadas en paralelo, timeouts cortos y degradación (si catalogo no responde, la ruta se muestra sin fotos). No tiene base de datos: es composición en la API (08-01, apartado 5), justificada porque la app hace pocas llamadas, los datos son pequeños y necesita frescura.

La tabla de 01-06 era una promesa: cada componente, la lección donde se construiría. Esta es la misma tabla, cerrada, con lo que finalmente se construyó y el fichero o el nombre que lo materializa en km0/.

Ana, en Valencia, compra dos queso-curado de la Quesería Montblanc y un vino-crianza de la Bodega Roble Alto. El pedido es P-2026-000125. Este es el recorrido completo, con la lección en la que se construyó cada paso.

Cinco observaciones sobre el diagrama que resumen el curso:

1. Solo dos llamadas síncronas entre servicios (pasos 9 y 12), las dos con timeout, circuit breaker y mTLS, y las dos porque su respuesta gobierna la siguiente decisión (08-01). Todo lo demás son eventos.
2. Ninguna transacción cruza servicios. El pedido se crea en Cassandra, la reserva en RDS y el cobro en la pasarela como transacciones locales; la saga las encadena y compensa (03-05); la outbox garantiza que los eventos salen si y solo si la transacción local se confirma (02-05).
3. La idempotencia aparece cuatro veces: la Idempotency-Key de Ana en Kong/pedidos (un doble clic no crea dos pedidos), el id_reserva en inventario, la clave cobro-<pedido> hacia la pasarela, y el id_evento en cada consumidor. Un reintento en cualquier punto es seguro.
4. Ana recibe la respuesta en el paso 17, antes de que exista la vista del catálogo, la asignación de reparto o la factura. Lo que ve después (posición de la furgoneta, factura en su área personal) llega por caminos asíncronos con segundos de retraso, que es el estado normal (08-01).
5. El borde y el gateway hacen su trabajo antes de que nada llegue a los servicios: el JWT se verifica tres veces (Worker, Kong, servicio), el rate limiting protege a pedidos, y la ficha del producto ni siquiera llegó a la región.

Un pedido no solo produce estado; produce evidencia. Lo que queda tras P-2026-000125:

La prueba de que la observabilidad está bien hecha es que con el pedido_id se puede reconstruir todo: de los logs al trace_id, de la traza a cada servicio y su latencia, de la métrica a si ese pedido fue uno de los que rompieron el SLO, del evento en el lago a lo que analitica calculó, de la auditoría a quién lo hizo. Es lo que el ejercicio 2 pone a prueba.

En 08-01 se escribió el ADR-001 completo. Estas son las seis decisiones estructurales de Kilómetro Cero en formato resumido: cada una con la alternativa que se rechazó y la consecuencia negativa que se aceptó, que es la parte que dentro de un año permitirá saber si sigue siendo válida.

Cada ADR está en km0/docs/adr/ADR-00N-*.md, con el formato completo de 08-01. Nótese que tres de las seis decisiones (002, 003, 006) rechazan explícitamente una opción "más moderna" o "más gestionada": la arquitectura no es la suma de las mejores tecnologías sino de las decisiones que responden a un síntoma con un coste conocido.

Un buen curso deja criterios, no solo técnicas. Estos son los cinco con los que Kilómetro Cero se evalúa a sí misma, y con los que el alumno puede evaluar cualquier otra plataforma.

La lección de esta tabla es que "fuerte" aparece dos veces y "eventual" seis: la consistencia fuerte se paga y se reserva para lo que de verdad la necesita.

Ninguna arquitectura está terminada; esta tiene cinco frentes abiertos, cada uno con el módulo del curso que da las herramientas para abordarlo:

1. Multirregión activa-activa. Hoy hay pilot light (07-03, 08-03): la región secundaria tarda 1-2 horas en servir. Pasar a activa-activa exigiría decidir el modelo de escritura por dato: km0_pedidos en Cassandra multi-DC (LOCAL_QUORUM por región, 04-04) es natural; el stock (inventario) no lo es, y obligaría a particionar la autoridad por mercado (Girona y Lleida escriben en eu-west-1, Valencia en eu-central-1) con el modelo multilíder de 03-04 para los mercados repartidos. Es un proyecto de meses y el ADR-007 pendiente.
2. Event sourcing completo. Hoy los eventos son notificaciones de cambios de estado que se guardan aparte (y para siempre en el lago). Event sourcing haría de los eventos la fuente de verdad de pedidos: el estado se reconstruye reproduciendo pedido.creado, pago.confirmado, ... Se gana auditoría perfecta y reconstrucción de cualquier vista; se paga con snapshots, versionado de eventos históricos y consultas siempre por proyección. CQRS (08-01) ya deja el terreno preparado.
3. Data mesh. analitica es hoy un equipo central que consume todo. A medida que crecen los dominios, cada equipo pasaría a publicar sus datos como producto (con esquema, calidad, SLA y propietario) y analitica a ser plataforma. Es la ley de Conway (08-01) aplicada a los datos.
4. Plataforma interna como producto. El equipo de plataforma de 08-01 existe; lo que falta es tratarlo como producto: un portal donde un equipo crea un servicio nuevo con su Deployment, sus dashboards, sus alertas, su pipeline y su ADR de plantilla en minutos (el ejercicio 1 lo pone a prueba).
5. Coste como restricción de diseño. FinOps (08-03) mide; el siguiente paso es que el coste entre en las decisiones de arquitectura como entra la latencia: euros por pedido como SLO, revisión trimestral de los servicios gestionados frente a los propios, y apagado automático de todo lo que no sirva tráfico.

El curso ha mostrado código en cada lección; el proyecto propone construir una versión reducida y funcional en el portátil, con lo que cabe en docker-compose y sin nube: catalogo, pedidos, inventario, Kafka, PostgreSQL, Redis y Prometheus. pagos se simula, reparto y analitica son opcionales, y el resto de la plataforma (Keycloak, Kubernetes, Terraform, Lambda, CDN) queda fuera del alcance mínimo. Lo importante no es el tamaño sino que cada hito sea verificable con un comando.

Cada hito debe terminar con un ADR corto si se toma una decisión (por ejemplo, "PostgreSQL en lugar de Cassandra para pedidos en la versión reducida: contexto, consecuencias") y con las pruebas que lo verifican en tests/. El resultado es un repositorio que se puede enseñar y del que se puede hablar en una entrevista con la misma precisión con la que este curso ha hablado de Kilómetro Cero.

El curso ha sido un mapa; estos son los territorios para seguir. Se citan obras y artículos por título y autor, sin enlaces: todos son fáciles de localizar por su nombre.

Libros de referencia

• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017). El libro que más se parece a los Módulos 2, 3 y 4 de este curso, con mucha más profundidad: replicación, particionado, transacciones, consenso, procesamiento por lotes y en flujo. Es la lectura siguiente natural.
• Andrew S. Tanenbaum y Maarten van Steen, Distributed Systems (3.ª ed., disponible gratuitamente por los autores). El texto académico clásico: modelos, comunicación, sincronización, consistencia y tolerancia a fallos con rigor formal. Complementa el Módulo 1 y el 3.
• Sam Newman, Building Microservices (2.ª ed., O'Reilly, 2021) y Monolith to Microservices (2019). Todo lo de 08-01 con detalle: fronteras, migración, pruebas, organización.
• Betsy Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems y The Site Reliability Workbook. El origen de los SLO, los presupuestos de error, los postmortems y la guardia del Módulo 7. Disponibles gratuitamente en línea por Google.
• Eric Evans, Domain-Driven Design (2003), y Vaughn Vernon, Implementing Domain-Driven Design (2013), para profundizar en los bounded contexts de 08-01.
• Gregor Hohpe y Bobby Woolf, Enterprise Integration Patterns (2003): el catálogo de patrones de mensajería de los que 02-04 y 02-05 tomaron los nombres.
• Neal Ford, Mark Richards et al., Software Architecture: The Hard Parts (2021): trade-offs de descomposición, datos distribuidos y sagas, con el mismo espíritu de ADR.

Artículos fundacionales (todos localizables por título)

• Leslie Lamport, "Time, Clocks, and the Ordering of Events in a Distributed System" (1978): la base de 01-05. Y "The Part-Time Parliament" (1998) y "Paxos Made Simple" (2001) para el consenso.
• Diego Ongaro y John Ousterhout, "In Search of an Understandable Consensus Algorithm" (Raft, 2014): lo que etcd y Kafka KRaft implementan (03-03).
• Giuseppe DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (2007): hashing consistente, quórums, vector clocks y la elección de disponibilidad que Cassandra hereda (04-01, 04-04).
• Jeffrey Dean y Sanjay Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters" (2004), y Sanjay Ghemawat et al., "The Google File System" (2003): 05-02 y 04-02.
• James C. Corbett et al., "Spanner: Google's Globally-Distributed Database" (2012): consistencia fuerte a escala global con relojes acotados (TrueTime), el contrapunto a Dynamo.
• Jay Kreps, Neha Narkhede y Jun Rao, "Kafka: a Distributed Messaging System for Log Processing" (2011), y el ensayo de Jay Kreps "The Log: What every software engineer should know about real-time data's unifying abstraction" (2013): la idea del log como columna vertebral (ADR-004).
• Hector Garcia-Molina y Kenneth Salem, "Sagas" (1987): el artículo original de 03-05.
• Seth Gilbert y Nancy Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (2002), y Daniel Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC, 2012): 03-02.
• Marc Shapiro et al., "Conflict-free Replicated Data Types" (2011): los CRDT de 03-01 y 08-04.
• Peter Deutsch y James Gosling, las "Fallacies of Distributed Computing", y Peter Bailis et al., "Highly Available Transactions: Virtues and Limitations" (2013), para seguir con las falacias y los modelos de aislamiento.
• Tyler Akidau et al., "The Dataflow Model" (2015): tiempo de evento, marcas de agua y ventanas de 05-04.

Práctica

• Jepsen (Kyle Kingsbury): análisis públicos de cómo fallan bases de datos reales bajo particiones; la mejor escuela de escepticismo sobre garantías anunciadas.
• Los libros de Michael Nygard, Release It! (2.ª ed., 2018), para los patrones de estabilidad de 07-04 contados desde incidentes reales.
• Construir el proyecto del apartado 9 y, después, romperlo con los experimentos de 07-06.

• Presentar la arquitectura como un diagrama sin decisiones. El diagrama del apartado 1 vale poco sin los ADR del apartado 5; lo que se aprende de una arquitectura son sus alternativas rechazadas y sus consecuencias aceptadas.
• Evaluar por tecnologías y no por criterios. "Usa Kafka y Kubernetes" no dice si está bien diseñada. Las tablas del apartado 7 (falacias, consistencia por dato, SLO, RPO/RTO, quién puede qué) sí.
• Empezar el proyecto por la infraestructura. Kubernetes, mesh y Terraform sin un servicio que desplegar es el error de "elegir tecnologías antes que problemas" de 01-06. El proyecto empieza en H1 con tres servicios y docker-compose.
• Creer que la plataforma está terminada. El apartado 8 lista cinco frentes; una arquitectura sin lista de pendientes es una que nadie está mirando.
• Consejo: en cualquier sistema nuevo, empieza por escribir los síntomas (01-06), la tabla de consistencia por dato (03-01) y los SLO (07-01) antes de dibujar cajas. Son las tres páginas que más decisiones correctas producen.
• Consejo: guarda este curso como referencia por lección: cuando dentro de un año tengas que decidir entre orquestación y coreografía, o cuánto TTL poner en una CDN, la lección correspondiente tiene la tabla.

En 08-01 se decidió que las valoraciones son un bounded context propio con comunicación por eventos. Ahora diséñalo de extremo a extremo aplicando todo el curso: (a) contrato de eventos que consume y produce (con la envoltura de 02-04) y modelo de datos con su modelo de consistencia (03-01) y su almacenamiento (Módulo 4); (b) API pública en Kong con autenticación y autorización (quién puede valorar qué; 06-01, 06-05) y cómo llega la media a la ficha cacheada por la CDN (08-04); (c) SLO, métricas y alertas (07-01), y qué trazas y auditoría deja una valoración; (d) despliegue (07-05), RPO/RTO (07-03) y qué habría que añadir a main.tf (08-03); (e) el ADR-007 en formato resumido (decisión, alternativa rechazada, consecuencia).

Sábado 19 de septiembre, 18:42, Semana del Queso Artesano. Se dispara la alerta "SLO de pedidos: consumo de presupuesto de error ×14 en 5 min". Datos disponibles:

• Prometheus: rate(km0_pedidos_total{estado="rechazado_stock"}[5m]) pasa de 0,3/s a 9/s a las 18:40; la latencia p99 de POST /pedidos baja de 420 ms a 95 ms; km0_grpc_client_duration_seconds{metodo="ReservarStock"} p99 = 8 ms; km0_circuit_estado{dependencia="inventario"} = 0; lag del grupo catalogo-proyeccion = 0.
• Logs de inventario (Loki): a partir de las 18:39:50, cientos de líneas {"nivel":"warning","msg":"StockInsuficiente","producto":"queso-curado","mercado":"girona","disponibles":0,"solicitadas":2,"request_id":...}.
• Logs de catalogo: {"nivel":"info","msg":"vista actualizada","producto":"queso-curado","mercado":"girona","aplicado":true} a las 18:39:48, y ninguno después para ese producto.
• Trazas: los pedidos rechazados tienen spans kong → pedidos → inventario.ReservarStock (StockInsuficiente) de 90 ms; ninguno llega a pagos.
• productos_vista en catalogo: queso-curado / girona: disponible = true, unidades_aprox = 0, version_stock = 1758300000123.
• Auditoría: a las 18:39:45, {"quien":"mpuig","accion":"stock.ajustar","recurso":"queso-curado/girona","de":140,"a":0,"origen":"panel-productor"}.

(a) Reconstruye la cadena causal completa. (b) ¿Es un incidente de la plataforma, del producto o de operación? ¿Qué parte del comportamiento es correcta y cuál es un defecto? (c) Localiza el defecto exacto en el código de 08-01 (proyeccion_stock.py o productos_vista.sql) y corrígelo. (d) Escribe las tres acciones del postmortem (07-03) y qué señal habría detectado el problema antes que el SLO.

Una startup de tres personas quiere lanzar un marketplace como Kilómetro Cero en un solo mercado, con 20 productores, 300 pedidos al día y 6 repartidores. Tienen tres meses y no pueden operar Kubernetes ni Kafka. Usando la tabla de "cuándo no usar microservicios" de 08-01 y el lock-in selectivo de 08-03, diseña la arquitectura mínima: (a) qué se queda como monolito modular y con qué estructura interna; (b) qué tres decisiones de Kilómetro Cero conservarías intactas porque son baratas y evitan errores irreversibles; (c) cómo resolverías el seguimiento en tiempo real y las fotos sin Kafka, MQTT ni Lambda; (d) qué señales medibles indicarían que ha llegado el momento de extraer el primer servicio, y cuál sería.

Ejercicio 1.

(a) Consume pedido.entregado (publicado por reparto en pedidos.eventos con la envoltura estándar; datos: {pedido_id, cliente, lineas: [{producto, productor}], entregado_ms}) para saber qué se puede valorar. Produce en un tópico nuevo valoraciones.eventos (3 particiones, clave = producto, para que las valoraciones de un producto lleguen en orden a la proyección): valoracion.creada {valoracion_id, cliente, pedido_id, producto, productor, puntos, comentario, fecha_ms} y valoracion.respondida {valoracion_id, productor, respuesta, fecha_ms}. Modelo: tabla valorables (cliente, pedido_id, producto, entregado_ms, valorado bool) y valoraciones (id, cliente, producto, productor, puntos, comentario, respuesta, creada_en) en una base PostgreSQL propia km0_valoraciones (RDS pequeña, sin Multi-AZ al inicio): volumen bajo (una por línea entregada), consultas relacionales (por producto, por productor, pendientes de respuesta), y la regla "una valoración por línea" exige una restricción UNIQUE (cliente, pedido_id, producto) con consistencia fuerte local. La media en la ficha es eventual (proyección en catalogo), y el panel del productor lee su propia base con consistencia fuerte.

(b) Rutas en Kong: POST /api/v1/valoraciones (rol cliente), GET /api/v1/productos/{slug}/valoraciones (pública, cacheable 60 s), POST /api/v1/valoraciones/{id}/respuesta (rol productor), GET /api/v1/productores/me/valoraciones?pendientes=true (rol productor). Autorización en el servicio: al crear, claims.sub debe tener una fila en valorables no valorada para ese pedido y producto (ABAC con dato propio, sin llamar a pedidos); al responder, claims.productor debe coincidir con valoraciones.productor. Rate limiting específico (5 valoraciones/minuto por consumidor) contra el abuso. La media llega a la ficha porque catalogo consume valoracion.creada y mantiene suma_puntos y num_valoraciones en productos_vista (idempotente por id_evento); la ficha sigue siendo public, max-age=60 por mercado, y la media cambia con hasta un minuto de retraso en la CDN, aceptable. Los tres últimos comentarios se sirven en la ruta pública de valoraciones (cacheable, sin datos personales más allá del nombre de pila, que el cliente consintió).

(c) SLO: 99,5 % de disponibilidad y p99 < 300 ms para crear (no está en el camino de compra: SLO más laxo que pedidos). Métricas: km0_valoraciones_total{resultado}, latencia por ruta, lag del consumidor de pedido.entregado y del de catalogo sobre valoraciones.eventos. Alertas: consumo de presupuesto de error, lag > 5 min (una entrega que no se puede valorar), y tasa de no_autorizado anómala (abuso). Traza: kong → valoraciones POST → postgres, enlazada al consumidor de catalogo por el id_evento. Auditoría: valoracion.crear y valoracion.responder en auditoria.eventos (las respuestas de productores son contenido público, y la moderación necesita saber quién escribió qué).

(d) k8s/valoraciones-deployment.yaml copiando la plantilla de pedidos (2 réplicas, sondas, resources, topologySpreadConstraints, HPA por CPU, NetworkPolicy que solo permite entrada desde Kong y salida a su RDS y a Kafka, serviceAccountName con IRSA sin permisos de S3). RPO: minutos (backups de RDS y PITR; la pérdida de valoraciones es tolerable pero molesta); RTO: 1 hora (no bloquea ventas). En main.tf: aws_db_instance.valoraciones (db.t4g.small, sin multi_az), su grupo de seguridad (5432 solo desde EKS), un módulo IRSA sin políticas de S3, y el tópico valoraciones.eventos gestionado con el proveedor kafka o creado por el pipeline.

(e) ADR-007: "valoraciones como bounded context propio con PostgreSQL y comunicación exclusivamente por eventos". Alternativa rechazada: dentro de catalogo (acoplaría la moderación a los despliegues del catálogo en campaña y mezclaría dos lenguajes: "producto publicado" y "valoración"). Consecuencia aceptada: la ficha muestra la media con hasta un minuto de retraso; un componente más con base de datos, dashboard y guardia (del equipo de catálogo y productores); si reparto deja de publicar pedido.entregado, nadie puede valorar hasta que se recupere el lag (alerta).

Ejercicio 2.

(a) Cadena causal: 18:39:45, Marta Puig ajusta desde su panel el stock de queso-curado en Girona de 140 a 0 (probablemente un error al introducir el dato, o una retirada real del producto). inventario aplica el ajuste y publica stock.actualizado {disponible: 0}. 18:39:48, catalogo recibe el evento y la proyección lo aplica (aplicado: true) → unidades_aprox = 0. Pero disponible sigue en true. A partir de 18:39:50, los clientes que ven la ficha (con disponible = true) añaden queso-curado al carrito y confirman; pedidos inicia la saga, inventario responde StockInsuficiente en 8 ms, la saga compensa y el pedido queda rechazado_stock. La latencia p99 baja (los pedidos rechazados no pasan por la pasarela), la tasa de rechazos sube ×30 y el presupuesto de error se consume porque rechazado_stock cuenta como fallo del SLO de pedidos.

(b) Es un incidente mixto. La saga, el circuito y la compensación funcionan correctamente: ningún pedido se cobró sin stock, ninguna reserva quedó colgada. El ajuste de Marta es una acción legítima de negocio (y la auditoría la registra con precisión). El defecto está en la plataforma: la ficha del catálogo sigue diciendo "disponible" con 0 unidades, lo que dirige a cientos de clientes a un rechazo seguro. Es un defecto de la proyección CQRS, no de la consistencia eventual: el retraso fue de 3 segundos, aceptable; el problema es que el dato proyectado es incorrecto de forma permanente.

(c) En proyeccion_stock.py, aplicar calcula disp = d["disponible"] >= UMBRAL_DISPONIBLE con UMBRAL_DISPONIBLE = 1: con disponible = 0, disp = False, y el UPDATE debería haber puesto disponible = FALSE... salvo que la condición version_stock < %(v)s haya fallado. Pero el log dice aplicado: true, así que el UPDATE afectó a la fila. Entonces el defecto no está ahí; mírese productos_vista.sql: disponible BOOLEAN NOT NULL DEFAULT FALSE y unidades_aprox se actualizan juntos en el mismo UPDATE. La fila muestra unidades_aprox = 0 y disponible = true, lo que solo es posible si otra ruta de escritura puso disponible = true después: la ruta de publicación del producto por el productor (catalogo crea/actualiza la fila cuando el productor edita la ficha y, según 08-01, "la fila la crea catalogo cuando el productor publica el producto"). Marta editó la ficha (quizá el mismo ajuste desde el panel toca producto y stock), y el UPSERT de publicación sobrescribe disponible con su valor por defecto o con el valor que tenía la ficha en el formulario, sin respetar version_stock. El defecto es que dos caminos escriben la misma columna con reglas distintas: la corrección es que la publicación de la ficha nunca escriba disponible ni unidades_aprox (columnas propiedad exclusiva de la proyección), es decir, INSERT ... ON CONFLICT (slug, mercado) DO UPDATE SET nombre = EXCLUDED.nombre, precio_cents = EXCLUDED.precio_cents, productor = EXCLUDED.productor sin tocar las columnas de stock; y, como red de seguridad, un CHECK (NOT disponible OR unidades_aprox >= 1) en la tabla que haría fallar la escritura incoherente en lugar de dejarla pasar. Es el principio de 08-01 de "dueño del dato" aplicado dentro de un servicio, columna a columna.

(d) Postmortem sin culpa (07-03): 1. Corregir el UPSERT de publicación y añadir el CHECK; prueba de integración (07-06) que publica la ficha después de un stock.actualizado a 0 y verifica disponible = false. 2. Añadir una confirmación en el panel del productor para ajustes de stock que cambien más de un 50 % ("¿Poner queso-curado en Girona a 0 unidades? Había 140"), porque la auditoría muestra un salto improbable. 3. Separar en el SLO de pedidos los rechazos por stock (resultado de negocio correcto) de los errores de plataforma, o crear una alerta específica de "tasa de rechazado_stock por producto" con umbral bajo, para que el síntoma se atribuya bien. La señal que lo habría detectado antes: una alerta de coherencia en la proyección, count(productos_vista where disponible and unidades_aprox = 0) > 0, evaluada cada minuto (una consulta barata), o la métrica de Flink de 05-04 alertas_stock para queso-curado en Girona, que se disparó a las 18:39:50 hacia inventario.alertas y que Marta recibió por SSE (08-02) pero que nadie correlacionó con los rechazos.

Ejercicio 3.

(a) Un monolito modular en Python (FastAPI) con una base de datos PostgreSQL gestionada (RDS o Cloud SQL con backups automáticos y PITR, sin Multi-AZ al principio), desplegado en un PaaS de contenedores (Cloud Run, App Runner, Fly.io, Render: 2 instancias, autoescalado incluido, TLS gestionado). Estructura interna: los seis paquetes de 01-06 (catalogo, pedidos, inventario, pagos, reparto, analitica) cada uno con su api.py como único módulo público (08-01), esquemas de PostgreSQL separados por paquete (inventario.referencias, pedidos.pedidos) y una regla de lint (import-linter) que prohíbe importar módulos privados de otro paquete y consultas SQL entre esquemas. La transacción de confirmar pedido es local (una sola base): reserva, pedido y registro del cobro en una transacción, con la llamada a la pasarela fuera de ella (cobrar primero con Idempotency-Key, luego confirmar en transacción; si falla la confirmación, reembolsar). Redis gestionado pequeño para la caché del catálogo y el limitador. Un solo repositorio, un pipeline, docker-compose para desarrollo.

(b) Tres decisiones baratas que evitan errores irreversibles: 1. La envoltura de eventos y una tabla eventos (outbox) desde el primer día, aunque el "bus" sea la propia base de datos y el consumidor un proceso del monolito: cuando llegue Kafka, los productores ya publican y los consumidores ya son idempotentes; y el lago analítico puede empezar exportando esa tabla a Parquet cada noche. 2. Idempotencia en las APIs de escritura (Idempotency-Key en crear pedido, claves deterministas hacia la pasarela): es lo que en 02-05 y 08-04 evita cobros y pedidos duplicados, cuesta una tabla, y no se puede añadir después sin migrar clientes. 3. Observabilidad mínima con SLO: logs JSON con request_id, métricas RED y un SLO escrito para crear pedido; sin esto, no habrá datos para decidir cuándo extraer nada (apartado d). Y una cuarta gratuita: los ADR desde el primer día.

(c) Seguimiento: 6 repartidores enviando posiciones por HTTPS POST cada 10 s al monolito (60 peticiones/minuto: nada), guardadas en una tabla reparto.posiciones con retención de 24 h (a este volumen, PostgreSQL sobra), y los clientes con SSE o polling cada 5 s contra un endpoint que devuelve la última posición del pedido (con Cache-Control: max-age=4 para que el PaaS o una CDN absorba repeticiones). Sin MQTT ni WebSockets: no hay volumen que lo justifique, y SSE con reconexión automática cubre la experiencia. Fotos: subida por URL prefirmada a S3/GCS (04-03, se conserva) y miniaturas generadas en el mismo monolito en una tarea en segundo plano (una cola simple en PostgreSQL con SELECT ... FOR UPDATE SKIP LOCKED, procesada por un worker del propio despliegue), con una CDN gratuita o de bajo coste delante del bucket con claves inmutables (08-04, se conserva porque es casi gratis y evita el egress).

(d) Señales para extraer el primer servicio, medibles gracias a (b)-3: el p99 de crear pedido se degrada cuando sube el tráfico del catálogo (contención en la misma base o CPU: síntoma 1); el equipo pasa de 3 a 8-10 personas y los despliegues del catálogo rompen pedidos (síntoma 3); el tráfico de lectura supera lo que Redis + una réplica de lectura de PostgreSQL absorben; o la latencia de la pasarela empieza a bloquear conexiones (síntoma 2). El primero en salir, como en 01-06, es catalogo (solo lecturas, sin transacciones cruzadas, vuelta atrás con un cambio de ruta) o, si el síntoma dominante es el de la pasarela, pagos con su ACL. Nunca pedidos e inventario primero: son los que exigen sagas, y las sagas se justifican solo cuando la frontera ya existe por otra razón. La regla de 08-01 se cumple al revés: tres personas sin síntomas es la fila exacta de la tabla que dice "monolito modular".

Kilómetro Cero empezó como un monolito Python con una base de datos y cinco síntomas, y termina como una plataforma que puede dibujarse en un diagrama, recorrerse con un pedido, justificarse con seis ADR y evaluarse con los criterios que el propio curso ha dado: las ocho falacias asumidas como falsas en puntos concretos del diseño, una tabla de consistencia por dato donde "fuerte" aparece dos veces y "eventual" seis, SLO y RPO/RTO por componente, y una tabla de quién puede qué desde Ana hasta el Worker de la CDN. Los cinco síntomas de 01-06 tienen cada uno su resolución y su forma de verificarla; las decisiones tienen cada una su alternativa rechazada y su precio; y lo que queda fuera está escrito, con el módulo que da las herramientas para abordarlo. El proyecto propuesto reduce todo eso a lo que cabe en un portátil, con diez hitos que se comprueban con un comando, y la guía de estudio señala los libros y artículos donde cada idea de este curso tiene su origen y su profundidad.

Lo que el alumno sabe hacer ahora no es "usar Kafka" o "desplegar en Kubernetes", aunque también. Es algo más duradero: ante un sistema que tiene que repartirse entre varias máquinas, sabe escribir primero los síntomas y no las tecnologías; cortar fronteras donde el lenguaje cambia de significado y no donde hay una tabla; elegir para cada dato el modelo de consistencia que necesita y pagar solo por ese; hacer que cada llamada tenga timeout, cada mensaje un identificador y cada consumidor sea idempotente, porque la red va a fallar; sustituir la transacción global por una saga que compensa; poner el dato donde su carga lo pide, de PostgreSQL a Cassandra, de Redis a S3, de la CDN a la cola SQLite de una furgoneta; separar lo que se calcula por lotes de lo que no puede esperar; autenticar y autorizar en cada frontera sin confiar en ninguna; medir con SLO, observar con trazas, recuperar con backups probados y ensayar los fallos antes de que ocurran; describir la infraestructura como código y el coste como una métrica; y dejar cada decisión escrita con su contexto y sus consecuencias, para que quien venga después pueda cambiarla con conocimiento.

Eso es diseñar arquitecturas distribuidas: no acumular piezas, sino saber en cada una qué se gana, qué se pierde y por qué se eligió. Kilómetro Cero ha sido la excusa; el criterio es lo que se lleva el alumno. Gracias por haber recorrido el curso hasta aquí, y buena suerte con el siguiente sistema que tenga que repartirse entre varias máquinas: ahora ya sabe por dónde empezar.