La lección anterior terminó con dos preguntas. La primera: ¿hace falta un Deployment en EKS, con sus réplicas, sus sondas, su HPA y su guardia, para generar tres miniaturas cada vez que la Quesería Montblanc sube una foto, o para producir un PDF de factura cuando llega un pago.confirmado? Son tareas pequeñas, esporádicas, sin estado, que responden a un evento y terminan. La segunda: ¿por qué la foto de queso-curado tiene que viajar desde la región eu-west-1 hasta el móvil de Ana en Valencia en cada visita, pagando egress y 40 ms de latencia, cuando podría estar guardada a veinte kilómetros de ella? Y hay una tercera, que ya asomó en 08-02: ¿qué hace furgoneta-3 con sus posiciones durante un túnel de tres minutos, o el puesto de la Huerta La Vega en el mercado de Lleida cuando la conexión se cae y siguen llegando clientes? Las tres preguntas tienen respuestas que salen del modelo "servicio en un clúster en una región": serverless, donde el proveedor ejecuta funciones efímeras en respuesta a eventos y cobra por invocación; y edge computing, donde el cómputo y los datos se acercan a quien los usa, sea una CDN, una función en el borde de la red o un dispositivo que funciona sin conexión. Esta lección desarrolla ambos, con su modelo de ejecución, sus límites, sus casos adecuados e inadecuados en Kilómetro Cero, y el código que los implementa: una Lambda de miniaturas, una de facturas, la saga de pedido reescrita en Step Functions, un Worker de Cloudflare que verifica el JWT en el borde y un agregador local para la furgoneta. El proyecto final (08-05) integrará todo.

1. Serverless y FaaS: el modelo de ejecución
2. Arranque en frío, límites, concurrencia y precio
3. Casos adecuados e inadecuados: los cuatro de Kilómetro Cero
4. Serverless más allá de FaaS: colas, bases de datos, API Gateway y Step Functions
5. Patrones: fan-out, idempotencia obligatoria y DLQ
6. Observabilidad, pruebas locales, lock-in y coste a gran escala
7. Código serverless: miniaturas, facturas, SAM y la saga en Step Functions
8. Edge computing: por qué acercar el cómputo
9. CDN: cachear fotos y catálogo cerca de Ana
10. Funciones en el borde: verificación de JWT y personalización
11. Edge para IoT: la furgoneta y el mercado sin conexión
12. El continuo nube-edge-dispositivo y la seguridad en el borde
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

"Serverless" no significa que no haya servidores: significa que no son nuestros ni los vemos. El proveedor los aprovisiona, los escala y los retira; nosotros entregamos código y pagamos por lo que se ejecuta. La forma más pura es FaaS (Function as a Service): AWS Lambda, Google Cloud Functions, Azure Functions. En 08-03 la tabla de responsabilidad compartida lo dejaba nombrado; este es su modelo de ejecución:

1. Un evento ocurre: un objeto llega a un bucket, un mensaje entra en una cola o un tópico, una petición HTTP llega a un endpoint, un temporizador salta.
2. El proveedor busca una instancia de la función lista (un microcontenedor con el runtime de Python y nuestro código). Si no hay ninguna libre, crea una (arranque en frío).
3. Invoca el manejador (handler(evento, contexto)) con el evento serializado. La función hace su trabajo y devuelve.
4. La instancia queda congelada unos minutos por si llega otro evento; si no llega, se destruye. No hay estado entre invocaciones en el que se pueda confiar (el sistema de ficheros temporal puede sobrevivir, pero no está garantizado).
5. Si llegan mil eventos a la vez, el proveedor crea hasta mil instancias en paralelo (escalado a miles); si no llega ninguno, no hay ninguna (escalado a cero) y no se paga nada.

La comparación con el Deployment de 07-05 resume la diferencia de modelo:

Arranque en frío (cold start): crear la instancia, cargar el runtime y ejecutar el código de inicialización (imports, conexiones) antes de la primera invocación. En Python con pocas dependencias son 100-300 ms; con Pillow, boto3 y un cliente de Kafka, 1-2 s; en una VPC, algo más. Es aceptable para procesar una foto y no para responder a Ana. Se mitiga con concurrencia aprovisionada (instancias mantenidas calientes, que se pagan aunque no se usen: se pierde el escalado a cero), con paquetes pequeños, y moviendo la inicialización pesada fuera del manejador para que se ejecute una vez por instancia y no por invocación.

Límites: tiempo máximo por invocación (15 min en Lambda, 9-60 min en Cloud Functions según la generación), memoria (de 128 MB a 10 GB; la CPU se asigna en proporción a la memoria, así que una función lenta a veces se acelera dándole memoria), tamaño del paquete (250 MB descomprimido; o una imagen de contenedor de hasta 10 GB), tamaño del evento (6 MB síncrono, 256 KB asíncrono), espacio temporal (/tmp de hasta 10 GB).

Concurrencia: el número de instancias simultáneas. Tiene un límite por cuenta y región (1 000 por defecto en Lambda, ampliable) y se puede reservar por función (para que una función descontrolada no agote la cuota de las demás) o limitar (para no agotar la base de datos de detrás: si km0_analitica acepta 100 conexiones, la función que la escribe no puede tener 500 instancias). Ese límite es el bulkhead de 07-04 en versión serverless.

Precio: por número de invocaciones (del orden de 0,20 € por millón) más por GB-segundo de ejecución (memoria asignada × duración; del orden de 0,000017 € por GB-s), con un tramo gratuito mensual. Una función de miniaturas con 512 MB que tarda 800 ms cuesta ≈ 0,000007 € por foto: 100 000 fotos al mes, menos de 1 €. Es lo que hace que serverless sea imbatible para cargas esporádicas y lo que lo hace caro para cargas constantes (apartado 6).

Con ese filtro, Kilómetro Cero identifica cuatro tareas que hoy viven como código dentro de los servicios (o como cron jobs en Kubernetes) y que encajan mejor como funciones:

1. Miniaturas al subir una foto a km0-fotos. En 04-03 la Quesería Montblanc subía fotos/queso-curado/original.jpg por URL prefirmada y "un proceso de miniaturas" generaba las de 300 y 800 px. Ese proceso era un consumidor con un bucle. Como función: evento s3:ObjectCreated → Lambda con Pillow → escribe miniatura-300.jpg y miniatura-800.jpg. Esporádico (cientos de fotos al día, con picos cuando un productor sube el catálogo entero), sin estado, 1 s por foto.
2. Factura PDF al pago.confirmado. Hoy un consumidor de pedidos.eventos en pedidos. Como función: evento de Kafka (MSK como origen de eventos de Lambda, en lotes) → generar el PDF → escribirlo en km0-facturas → notificar. Ritmo de los pedidos: miles al día, picos en campaña, sin estado.
3. Webhooks de la pasarela de pagos. La pasarela notifica de forma asíncrona los cobros diferidos y las devoluciones con un POST a una URL nuestra. Es un endpoint que recibe pocas llamadas, debe estar siempre disponible, verificar una firma y publicar un evento: API Gateway + Lambda, sin ocupar una réplica de pagos para esperar.
4. Tareas programadas ligeras. Caducar reservas de stock no confirmadas cada minuto, limpiar sesiones, comprobar que el DAG de Airflow terminó: temporizador (EventBridge) → Lambda. Sustituyen a CronJobs de Kubernetes que ocupaban recursos para ejecutar 200 ms de trabajo.

Y lo que no se mueve a funciones, con la razón: pedidos y catalogo (latencia exigida a personas, pool de conexiones, Kong y mesh delante), el servidor WebSocket de 08-02 (estado y conexiones largas; hay servicios gestionados de WebSocket, pero el fan-out entre instancias y la lógica de suscripción son justo lo que no encaja), los consumidores de Flink (estado y checkpoints), los trabajos de Spark (horas).

FaaS es la parte visible; a su alrededor hay servicios "serverless" en el sentido de sin capacidad que aprovisionar y con pago por uso:

Step Functions merece atención porque sustituye a algo que el curso construyó con esfuerzo. El OrquestadorSagaPedido de 03-05 persistía el estado de cada saga en la tabla sagas, reintentaba los fallos transitorios, distinguía los permanentes y ejecutaba las compensaciones en orden inverso. Step Functions hace exactamente eso como servicio: el estado de cada ejecución lo guarda el proveedor (con historial completo de cada paso), los reintentos y los Catch se declaran por paso, y las compensaciones son ramas del grafo. Lo que se pierde: el orquestador vive fuera del clúster, cada paso es una invocación (con su latencia y su coste), la definición es JSON y no Python, y es lo más específico del proveedor que hay (lock-in total). La comparación completa está en el apartado 7, con la saga reescrita.

Fan-out con colas. Un evento que debe procesarse de varias formas (una foto subida: miniaturas, análisis de contenido, actualización de la ficha) no dispara tres funciones directamente desde S3; se publica en un tópico (SNS o EventBridge) que lo entrega a una cola por consumidor (SQS), y cada cola dispara su función. Las colas desacoplan (si la función de análisis falla, las miniaturas se generan igual), absorben picos (un productor que sube 2 000 fotos no crea 2 000 × 3 instancias de golpe: la cola las dosifica con el límite de concurrencia) y dan reintentos y DLQ.

Idempotencia obligatoria. El proveedor entrega los eventos al menos una vez y reintenta automáticamente cuando la función falla o agota el tiempo: una función que tarda 16 minutos por un pico de tamaño se reinvoca, y si la primera instancia había escrito la mitad del resultado, la segunda parte de ese estado. Todo lo que se vio en 02-05 sobre consumidores idempotentes aplica con más fuerza, porque aquí los reintentos no los controlamos nosotros: cada función debe ser segura ante repetición. Las técnicas: claves de salida deterministas (la miniatura se escribe siempre en la misma clave: escribir dos veces es inofensivo), tabla de idempotencia en DynamoDB con el id del evento (la factura F-2026-000124 se genera una vez), y operaciones condicionales (PutItem con attribute_not_exists).

DLQ. Tras n reintentos (configurable por función o por cola), el evento va a una cola de mensajes muertos, con alerta (07-01) y procedimiento de reproceso: la DLQ de 02-05, gestionada. Sin DLQ configurada, un evento envenenado (una imagen corrupta que hace fallar a Pillow) se reintenta hasta agotar la política y se pierde en silencio.

Observabilidad. Las funciones emiten logs a CloudWatch (o Cloud Logging) automáticamente, y métricas de invocaciones, errores, duración y throttles. Lo que hay que añadir es lo mismo que en 07-02: logs estructurados con el X-Request-Id o el id_evento para correlacionar, y trazas con OpenTelemetry (o X-Ray) que enlacen la función con el servicio que produjo el evento, porque una petición de Ana que acaba en una factura atraviesa pedidos, Kafka y la Lambda, y sin propagación de contexto la traza se corta en Kafka. El servicios/comun/trazas.py de 07-02 se empaqueta con la función como capa (layer).

Pruebas locales. Una función no se puede ejecutar "sin el proveedor" salvo con emuladores: AWS SAM (sam local invoke, sam local start-api) ejecuta la función en un contenedor con un evento de ejemplo; LocalStack emula S3, SQS, DynamoDB y más en Docker, lo que permite pruebas de integración con Testcontainers (07-06) sin cuenta de AWS. Ninguno es perfecto (los permisos IAM y los límites reales solo se ven en el proveedor), así que el pipeline despliega a un entorno de staging real para las pruebas de contrato.

Lock-in. Es el más alto de todo lo visto: el formato del evento, el manejador, los servicios de alrededor (SQS, DynamoDB, Step Functions) son del proveedor. Se mitiga separando el manejador (adaptador de 10 líneas) de la lógica (funciones Python puras, probables sin proveedor), como se hace en el apartado 7; pero hay que aceptarlo: quien elige Step Functions elige AWS.

Coste a gran escala. El precio por invocación es imbatible a baja frecuencia y se vuelve caro a alta: una función con 512 MB que corre constantemente (por ejemplo, 100 invocaciones/s de 200 ms cada una, 24 h al día) consume ≈ 2,6 millones de GB-s al mes ≈ 45 €, más 260 millones de invocaciones ≈ 52 €: unos 100 €/mes, frente a ≈ 30 € de un Pod pequeño en un nodo ya pagado. La regla aproximada: cuando la utilización media supera el 30-40 % de un contenedor equivalente, el contenedor sale más barato. Por eso las miniaturas y las facturas son serverless y pedidos no.

La estructura añadida a km0/:

Decisiones a destacar: la idempotencia se basa en el ETag del original guardado como metadato de la miniatura, de modo que una reinvocación no rehace trabajo y una foto nueva con la misma clave (nuevo ETag) sí lo rehace; CacheControl: immutable es la promesa de 04-03 de no sobrescribir claves cacheadas por la CDN, que aquí se cumple porque la web referencia miniatura-800.jpg?v=<etag>; y el manejador no contiene negocio, para que procesar_objeto se pruebe con un cliente falso y para que el lock-in se limite a esas líneas.

Un matiz importante sobre el orden de operaciones: reclamar se hace antes de generar el PDF. Si la función muere después de reclamar y antes de escribir, la factura no se generará nunca en un reintento (la marca ya existe). La alternativa (reclamar después de escribir) permite duplicados si muere entre medias. Como escribir dos veces la misma clave de S3 es inofensivo (idempotente por sí mismo), la elección correcta aquí es reclamar después, o usar la existencia del objeto como marca. Se deja como está a propósito para el ejercicio 1, que pide corregirlo: es el tipo de razonamiento sobre el punto de ack que 02-05 enseñó, y en serverless no hay excusa para no hacerlo.

Tres detalles del template.yaml que evitan errores clásicos: el filtro por sufijo original.jpg impide que la escritura de una miniatura dispare de nuevo la función (un bucle infinito que también sería una factura infinita); ReservedConcurrentExecutions acota el daño de un pico; y el origen de eventos MSK convierte a Lambda en un grupo de consumidores más de pedidos.eventos, con el mismo modelo de particiones y offsets de 02-04, lo que significa que un fallo persistente de la función bloquea el avance de esa partición para ese grupo (y solo para ese grupo) hasta que el lote va a la DLQ. Se despliega con sam build && sam deploy --guided la primera vez, y desde el pipeline después.

La saga de 03-05 (reservar stock → cobrar → confirmar; compensar en orden inverso ante fallo permanente), expresada en Amazon States Language, con cada paso invocando una función (o, en producción, el servicio correspondiente vía API):

Compárese con el OrquestadorSagaPedido de 03-05:

La decisión de Kilómetro Cero, que el ADR-006 de 08-05 formaliza: la saga de pedido se queda en pedidos, porque está en el camino crítico (latencia), tiene un volumen constante (coste) y ya está construida y probada; Step Functions se reserva para flujos de baja frecuencia y larga duración donde la visibilidad y los reintentos declarativos compensan, como la baja de un productor (cancelar sus productos, liquidar sus pagos, archivar sus fotos, todo con esperas de días).

Todo lo anterior sigue en la región del proveedor. El edge computing mueve cómputo y datos hacia el borde: a los puntos de presencia de una CDN (cientos de ciudades), a las antenas o pasarelas del operador, o a los propios dispositivos. Cuatro razones, y para cada una un caso de Kilómetro Cero:

Una CDN (Content Delivery Network: CloudFront, Cloudflare, Fastly, Akamai) es una red de servidores de caché distribuidos por el mundo, delante del origen. 04-05 la situó como capa de caché y 04-03 la justificó por el egress; aquí se diseña.

Cómo funciona. El DNS de km0.example apunta a la CDN; el navegador de Ana en Valencia resuelve al punto de presencia más cercano; si el objeto está en su caché (hit), lo sirve en 5-10 ms; si no (miss), lo pide al origen (S3 para las fotos, Kong para la API), lo guarda según las cabeceras de caché y lo sirve. El hit ratio es la métrica: con 4 200 productos y immutable, supera el 95 % tras el calentamiento.

Cache keys. La clave de caché es, por defecto, la URL completa (con parámetros de consulta). Dos consecuencias: miniatura-800.jpg?v=abc y ?v=def son objetos distintos, que es exactamente lo que se quiere para versionar (04-03); y una URL con parámetros irrelevantes (?utm_source=...) fragmenta la caché y baja el hit ratio, así que se configura qué parámetros forman parte de la clave. Cabeceras como Accept-Language o cookies pueden añadirse a la clave (con cuidado: cada valor multiplica las variantes).

TTL por tipo de contenido y invalidación:

La invalidación explícita (purge por URL o por etiqueta) existe pero es lenta (segundos a minutos para propagarse a todos los puntos de presencia) y a menudo se cobra; el diseño correcto la evita para lo inmutable y la usa solo para lo semiestático (la ficha) como complemento del TTL corto. Es el mismo principio de 04-05: "TTL como red, invalidación explícita como mecanismo".

Las CDN modernas ejecutan código en el punto de presencia (Cloudflare Workers, Lambda@Edge y CloudFront Functions, Fastly Compute): funciones muy pequeñas (milisegundos, pocos MB) que ven la petición antes de que llegue al origen o la respuesta antes de que llegue al cliente. Sus usos en Kilómetro Cero:

• Verificación de JWT en el borde. Una petición con un token inválido o caducado se rechaza en Valencia, sin viajar a Irlanda ni ocupar a Kong: menos latencia para el error y menos carga en el origen ante un ataque. El borde verifica la firma (con la clave pública de Keycloak, cacheada) y la caducidad; la autorización fina sigue en el servicio (06-01), y Kong vuelve a verificar (defensa en profundidad, como en 08-02).
• Personalización sin perder la caché. La ficha de queso-curado es igual para todos salvo el mercado (precio y disponibilidad por ciudad). El Worker lee el mercado de una cookie o de la geolocalización de la petición y lo añade a la clave de caché (/productos/queso-curado?mercado=valencia), de modo que hay una variante por mercado y no una por usuario.
• Redirecciones y A/B. Redirigir /es/... según Accept-Language, enviar al 10 % de los usuarios a la nueva página de producto y medir, sin desplegar nada en el origen.
• Servir desde el borde con respaldo. Si el origen falla, servir la última versión cacheada aunque haya caducado (stale-if-error): el catálogo sigue visible durante un incidente.

El Worker no contiene lógica de negocio ni accede a bases de datos: verifica, decide la clave de caché y reenvía. Todo lo que necesite el estado real (stock, pedidos) sigue yendo al origen. Y hay una restricción de diseño que el código respeta: la respuesta cacheada por mercado no puede contener datos del usuario; si catalogo añadiera "tus favoritos" a la ficha, la caché por mercado serviría los favoritos de Ana a Marc. Por eso la ficha es pública y los favoritos son otra llamada, private.

El borde más extremo es el dispositivo. Dos casos en Kilómetro Cero exigen funcionar sin conexión y sincronizar después:

La furgoneta. En 08-02, paho encolaba en memoria las posiciones durante el túnel y las enviaba de golpe al salir: 36 mensajes que a nadie interesaban uno a uno. Un agregador local en el dispositivo hace tres cosas mejor: guarda las posiciones en una cola persistente en disco (SQLite) para que un reinicio de la app no las pierda, agrega localmente (mientras no hay red, resume el tramo en un único mensaje con distancia recorrida, tiempo y trayectoria simplificada), y al recuperar la conexión envía primero la posición actual (lo urgente) y después el resumen (lo histórico). Es el edge como filtro: la nube recibe menos datos y más útiles.

El puesto del mercado. La Huerta La Vega vende en el mercado de Lleida con un terminal que descuenta stock local. Sin conexión, sigue vendiendo: es una réplica que acepta escrituras mientras está desconectada, es decir, replicación multilíder (03-04) con conflictos garantizados (la nube reserva 3 calabacines para un pedido online mientras el puesto vende 5 de los 6 que quedaban). 03-01 dio la herramienta para que la fusión sea determinista: los CRDT. Un contador de ventas del puesto como G-Counter (solo incrementa; fusionar es tomar el máximo por réplica) se sincroniza sin conflicto; el stock disponible, que es una resta, no es un CRDT puro, y se resuelve con la regla de negocio de 03-04: el puesto tiene autoridad sobre su stock físico (inv-lleida-puesto) y la nube sobre las reservas online, y la reconciliación puede dejar un pedido online sin stock, que la saga rechaza con compensación. Lo que el edge no puede hacer es prometer consistencia fuerte sin conexión: es la partición de 03-02, y el puesto elige disponibilidad.

Con el agregador, el ejercicio 2 de 08-02 cambia de respuesta: al salir del túnel, Ana recibe una posición (la actual), analitica recibe un tramo con la distancia y diez puntos (suficiente para el cálculo de distancia de Flink, que ahora puede sumar el distancia_m en lugar de reconstruirla), y el broker no recibe 36 mensajes. Los seq siguen siendo monótonos y persistidos, así que la deduplicación de 08-02 sigue funcionando. Lo que hay que añadir en el lado de la nube es un consumidor del nuevo tópico tramo en el puente MQTT → Kafka, hacia un tópico reparto.tramos.

Nube, borde y dispositivo no son alternativas sino un continuo: cada cálculo y cada dato se sitúan donde el equilibrio entre latencia, ancho de banda, autonomía, capacidad y control sea mejor.

Seguridad en el borde. Cuanto más lejos del centro, menos control físico: un Worker corre en infraestructura de un tercero, el terminal del mercado está en una mesa y la furgoneta puede ser robada. Cinco reglas:

1. Nada secreto en el borde de red: el Worker verifica firmas con la clave pública; nunca tiene la privada ni credenciales de bases de datos. Los secretos que un Worker necesita (una clave de API del origen) se guardan en el almacén de secretos de la CDN, no en el código.
2. El dispositivo se autentica con identidad propia y revocable: un certificado o credencial por dispositivo (la contraseña MQTT de furgoneta-3 de 08-02, emitida al darlo de alta), que se revoca en el broker si el dispositivo se pierde, y que solo autoriza su prefijo de tópicos (ACL).
3. Datos en reposo cifrados en el dispositivo: la cola SQLite con posiciones y los comandos con direcciones de clientes se cifran (SQLCipher o el almacén seguro del sistema operativo) y se borran cuando se sincronizan.
4. Mínimo dato en el borde: el terminal del puesto no necesita la dirección ni el teléfono de Ana; recibe solo lo que le hace falta para vender (producto, unidades, precio), y lo que envía (ventas) no lleva datos personales.
5. El borde no es la verdad: cualquier dato que venga del dispositivo se valida en la nube (el puente de 08-02 comprobaba que el repartidor del payload coincide con el del tópico; el tramo con 900 km en 3 minutos se descarta como inválido). Un dispositivo comprometido puede mentir; el diseño debe limitar lo que una mentira puede causar.

• Funciones para todo. Un consumidor constante de 500 eventos/s o un servicio con SLO de latencia son más baratos y previsibles como contenedor. Serverless para lo esporádico, lo evento-driven y lo que escala a cero.
• Suponer una sola ejecución. El proveedor reintenta; la función que no es idempotente genera dos facturas o tres miniaturas. Claves deterministas, marcas de idempotencia, operaciones condicionales.
• La función que se dispara a sí misma. Escribir la miniatura en el mismo bucket que dispara la función, sin filtro por prefijo o sufijo: bucle infinito y factura ilimitada. Filtro en el evento y comprobación en el código.
• Conexiones a base de datos desde mil instancias. Mil Lambdas abren mil conexiones a PostgreSQL. Límite de concurrencia, RDS Proxy, o DynamoDB para el estado de las funciones.
• Inicialización dentro del manejador. Cargar Pillow o crear el cliente de S3 en cada invocación multiplica la duración y el coste. Fuera del manejador, una vez por instancia.
• Sin DLQ. Un evento envenenado se reintenta y se pierde sin que nadie lo sepa. DLQ con alerta y procedimiento de reproceso, siempre.
• Cachear en la CDN respuestas con datos personales. Un public en /api/v1/pedidos sirve los pedidos de Ana a Marc. private, no-store para todo lo personal, y clave de caché por mercado, nunca por usuario, para lo compartido.
• Sobrescribir objetos cacheados por la CDN. La caché no se entera. Claves inmutables con versión (?v=<etag>), como se decidió en 04-03.
• Confiar en el dispositivo. Valida en la nube todo lo que venga del borde; asume que puede estar comprometido.
• Consejo: separa siempre manejador (adaptador del proveedor) y lógica (Python puro). Las pruebas se hacen sobre la lógica; el lock-in se limita al adaptador.
• Consejo: calcula el coste de cada función a la frecuencia real y a diez veces la real. Si a diez veces sigue siendo barata, es un buen caso; si se dispara, prepara la salida a contenedor.

En serverless/facturas/handler.py, reclamar(id_evento) se ejecuta antes de generar y escribir el PDF. (a) Describe el fallo concreto que esto produce y con qué probabilidad ocurre. (b) Reescribe la parte del manejador para que la idempotencia sea correcta, razonando por qué escribir dos veces en S3 es aceptable y qué ocurre si el proceso muere en cada punto posible. (c) ¿Sería distinta la respuesta si, en lugar de escribir un PDF en S3, la función enviara un correo con la factura?

Durante la campaña, la web sirve 6 millones de vistas de producto al día; cada vista descarga una miniatura-800 (180 KB) y la ficha JSON (4 KB). (a) Con el diseño del apartado 9 (fotos immutable, ficha con max-age=60), estima el hit ratio esperable de cada tipo y el egress diario desde S3 y desde Kong, frente a servir todo desde el origen. (b) Un día, la Quesería Montblanc cambia la foto de queso-curado y se queja de que "algunos clientes siguen viendo la antigua". ¿Qué ha fallado, si el diseño es correcto? (c) El equipo propone añadir el nombre de usuario a la ficha ("Hola, Ana") para personalizarla. Explica el impacto en la caché y propón una alternativa.

Para cada flujo, decide si Kilómetro Cero debería implementarlo con el orquestador propio de 03-05, con Step Functions, o con una simple función disparada por evento, y justifica con coste, latencia, duración y visibilidad: (a) la saga de confirmación de pedido (1,2 M al mes en campaña, en el camino crítico); (b) la baja de un productor (decenas al año: cancelar productos, esperar a que se entreguen los pedidos en curso, liquidar pagos a los 30 días, archivar fotos, notificar); (c) el reintento de cobros diferidos que la pasarela rechaza temporalmente (cientos al día, un reintento cada 6 horas durante 3 días).

Ejercicio 1.

(a) Si la función muere (timeout de 120 s por un lote grande, error de red con S3, retirada de la instancia) después de reclamar y antes de put_object, la marca factura#<id_evento> queda escrita y el PDF no. En el reintento de Lambda (o en el siguiente lote, porque el offset no avanzó), reclamar devuelve False y la factura se salta para siempre: factura perdida, sin error ni alerta. La probabilidad por evento es baja (la ventana son unos milisegundos entre dos llamadas), pero con 1,2 M pedidos al mes y reinicios de instancias, ocurrirá varias veces al mes.

(b) Reordenar: generar y escribir primero, marcar después; y usar la marca solo para evitar trabajo repetido, no para la corrección.

Análisis por punto de muerte: antes de put_object: nada escrito, el reintento lo hace todo. Entre put_object y marcar: el PDF existe, la marca no; el reintento vuelve a generar el mismo PDF y lo escribe en la misma clave (S3 reemplaza el objeto entero; con versionado queda una versión más, inofensiva) y marca. Después de marcar: todo hecho. En ningún caso se pierde la factura, y el peor resultado es un PDF regenerado. Escribir dos veces es aceptable porque la operación es naturalmente idempotente: mismo contenido determinista (el PDF no lleva la hora de generación; si la llevara, habría que fijarla al fecha_ms del evento) en la misma clave.

(c) Sí. Enviar un correo no es idempotente por naturaleza: enviarlo dos veces molesta a Ana. Entonces la marca antes de enviar es necesaria para no duplicar, pero deja la ventana de pérdida. La solución es la de 02-05 con la pasarela: usar un servicio de correo que acepte una clave de idempotencia (muchos la ofrecen por mensaje), de modo que se pueda enviar "otra vez" sin duplicar; o dividir en dos pasos, generar el PDF (idempotente, en S3) y encolar el envío en una cola con deduplicación por id (SQS FIFO con MessageDeduplicationId), donde el envío se reintenta con seguridad. Sin una de esas dos cosas, hay que elegir entre perder o duplicar, y para un correo se prefiere duplicar.

Ejercicio 2.

(a) Fotos: 4 200 productos, objetos inmutables, un año de TTL; tras el calentamiento, cada punto de presencia tiene todas las miniaturas: hit ratio > 98 % (los misses son solo el primer acceso a cada objeto en cada PoP y las fotos nuevas). Egress desde S3: 6 M × 180 KB ≈ 1,08 TB/día sin CDN; con 98 % de hits, ≈ 22 GB/día desde S3 (más el egress de la CDN al usuario, que suele ser mucho más barato o incluido). Fichas: max-age=60 y 4 200 productos × 4 mercados = 16 800 variantes; 6 M vistas/día son 70 por segundo, repartidas en 16 800 claves: en promedio cada clave se pide cada 4 minutos, así que en la mayoría de PoP la ficha ha caducado cuando se vuelve a pedir; hit ratio quizá del 30-60 % (mejor para los productos populares, peor para la cola larga). stale-while-revalidate=300 sube ese ratio mucho (sirve la caducada y refresca en segundo plano), a costa de hasta 5 minutos de obsolescencia. Egress desde Kong: 6 M × 4 KB = 24 GB/día sin CDN; con 50 %, 12 GB. La foto domina: la CDN elimina el 98 % de ~1,1 TB diarios; para la ficha, el beneficio es de latencia y de carga en catalogo más que de egress.

(b) Si el diseño es correcto (la nueva foto tiene un ETag nuevo y la web referencia ?v=<etag nuevo>), lo que ha fallado es que la ficha que contiene la URL de la foto está cacheada: los clientes que reciben una ficha cacheada (hasta 60 s, o hasta 5 minutos con stale-while-revalidate) reciben la URL antigua, que sigue apuntando a un objeto inmutable y válido, la foto antigua. No es un fallo de la foto sino del TTL de la ficha, y es el comportamiento esperado: "algunos clientes durante unos minutos". Si el problema durara horas, la causa sería otra: la web referenciando la foto sin ?v= (sobrescritura de clave, el error de 04-03) o el consumidor de stock.actualizado invalidando Redis pero no la CDN (04-05 advertía de invalidar en todas las capas).

(c) Con "Hola, Ana" en el cuerpo de la ficha, la respuesta ya no es igual para todos los usuarios de un mercado: o se marca private (y se pierde la caché en la CDN: el hit ratio de la ficha cae a 0 y catalogo recibe los 70 req/s completos) o, peor, se cachea por mercado y Marc ve "Hola, Ana". La alternativa: la ficha sigue siendo pública y por mercado, y la personalización se hace en el cliente (el navegador ya tiene el nombre en el JWT o en la sesión y lo pinta) o con una segunda llamada pequeña y private (/api/v1/yo) que la CDN nunca cachea. Es el principio del Worker: separar lo compartido cacheable de lo personal.

Ejercicio 3.

(a) Orquestador propio en pedidos. Volumen alto y constante (≈ 150 €/mes solo en transiciones de Step Functions, más las invocaciones), en el camino crítico (cada transición añade decenas de ms al p99, comprometiendo el SLO de 500 ms), duración de segundos, y ya construido y probado con Testcontainers. La visibilidad la dan las trazas de 07-02 y la tabla sagas.

(b) Step Functions. Decenas al año (coste despreciable), duración de semanas (esperas de 30 días que un orquestador propio tendría que gestionar con estado persistido y temporizadores: Step Functions tiene el estado Wait con fechas y ejecuciones de hasta un año), fuera de cualquier camino crítico, y con enorme valor de visibilidad (ver en qué paso está la baja de cada productor, quién la aprobó, por qué falló la liquidación). Cada paso invoca las APIs de los servicios existentes. El lock-in se acepta porque el flujo es periférico.

(c) Una función disparada por temporizador (o una cola con retraso), no Step Functions ni orquestador. Cientos al día con un reintento cada 6 horas durante 3 días es un patrón de cola con reintento diferido: SQS con DelaySeconds (máximo 15 minutos, así que se encadena) o, más simple, una tabla cobros_pendientes con siguiente_intento y una Lambda programada cada 15 minutos que procesa los vencidos con la Idempotency-Key de 02-05 y publica pago.confirmado o pago.rechazado al terminar. Step Functions con Wait de 6 horas funcionaría, pero es una máquina de estados para lo que es un bucle con una fecha; el coste y la complejidad no se justifican, y la visibilidad la da la tabla.

Serverless y edge computing amplían el espacio de decisiones de Kilómetro Cero en dos direcciones opuestas a la del clúster en una región. Con FaaS, el proveedor ejecuta funciones efímeras en respuesta a eventos, escala de cero a miles y cobra por invocación y GB-segundo; a cambio impone arranques en frío, límites de tiempo y memoria, ausencia de estado y, sobre todo, reintentos que no controlamos y que hacen de la idempotencia de 02-05 una obligación y no una buena práctica. Con ese filtro, las miniaturas de km0-fotos, las facturas de pago.confirmado, los webhooks de la pasarela y las tareas programadas salen de los servicios y pasan a funciones definidas con SAM, con DLQ, límite de concurrencia y filtros que evitan bucles, mientras pedidos, el WebSocket de 08-02, Flink y Spark se quedan donde estaban. Los servicios serverless de alrededor (colas, DynamoDB, API Gateway, Step Functions) completan el modelo, y la saga de 03-05 reescrita en Amazon States Language muestra con precisión qué se gana (estado gestionado, reintentos declarativos, visibilidad) y qué se paga (latencia, coste por transición, lock-in), lo que deja la saga de pedido en pedidos y reserva Step Functions para los flujos largos y esporádicos. En la otra dirección, el edge acerca datos y cómputo a quien los usa: la CDN sirve fotos inmutables y fichas por mercado con TTL e invalidación diseñados por tipo de contenido, el Worker verifica el JWT y decide la clave de caché sin tocar el origen, el agregador de la furgoneta convierte 36 posiciones de túnel en una posición y un tramo, y el puesto del mercado sigue vendiendo sin conexión con CRDT y reconciliación por autoridad, aceptando la partición de 03-02 en lugar de negarla. El continuo nube-borde-dispositivo sitúa cada dato donde el equilibrio es mejor, y la seguridad en el borde parte de que el borde puede mentir.

Con esto, todas las piezas de Kilómetro Cero están sobre la mesa: desde el corte de los bounded contexts de 08-01 hasta la caché en Valencia y la cola SQLite en la furgoneta. La última lección las junta: la arquitectura completa en un solo diagrama, el recorrido de un pedido de Ana de extremo a extremo con todo lo que deja a su paso, las decisiones y sus trade-offs revisitados como ADR, los cinco síntomas de 01-06 con su resolución, la evaluación con los criterios del curso, lo que queda fuera, el proyecto que el alumno puede construir en su portátil y la guía para seguir profundizando. Es el Proyecto Final: Kilómetro Cero de Extremo a Extremo.