En 05-05 quedó un cabo suelto explícito. AlpinaShop diseñó una arquitectura por eventos para procesar automáticamente cada imagen de producto que se sube al bucket alpinashop-catalogo: un mensaje al topic imagenes-subidas, una llamada a la Vision API, las etiquetas escritas en alpinashop_analitica y una miniatura generada. El diseño estaba claro. La implementación se aplazó porque faltaba una pieza: algo que ejecute código cuando ocurre un evento, sin que haya un servidor esperando.

Esa pieza son las Cloud Functions, y es lo que vamos a construir aquí de principio a fin.

Pero antes conviene entender por qué el problema no es trivial. La solución "obvia" sería añadir un endpoint al catálogo Flask que reciba el aviso y procese la imagen. Es una mala idea por tres motivos: el procesamiento de una imagen tarda segundos y bloquearía a un proceso de gunicorn que debería estar sirviendo peticiones de clientes; el catálogo escalaría por la carga de imágenes en lugar de por el tráfico web; y un fallo del procesamiento afectaría a la tienda. La reacción a eventos quiere su propio ciclo de vida, y ese es exactamente el hueco que llena FaaS.

1. Qué es FaaS y cuál es la unidad de despliegue
2. Cloud Functions hoy: la 2ª generación sobre Cloud Run y Eventarc
3. Funciones HTTP: la primera función y su despliegue
4. Autenticación: por qué casi nunca deben ser públicas
5. Funciones por eventos: CloudEvents y Eventarc
6. El caso pendiente: procesar-imagen-producto de principio a fin
7. Idempotencia, reintentos y dead letter
8. El ciclo de vida real: arranques en frío y concurrencia
9. Configuración, secretos e identidad
10. Conexión a la VPC para llegar a Cloud SQL
11. Límites y coste
12. Pruebas locales y despliegue desde Cloud Build
13. Cuándo una función y cuándo un servicio

Repasa mentalmente el continuo de abstracción de 02-07, ahora con una casilla más:

Function as a Service lleva la abstracción a su extremo práctico: escribes una función —una unidad de código con una firma concreta—, la plataforma la empaqueta, la despliega, la ejecuta cuando algo la dispara y la apaga cuando no hace falta.

Las cuatro propiedades que definen el modelo:

• Se dispara por un evento. Una petición HTTP, un mensaje de Pub/Sub, un fichero nuevo en un bucket, un documento modificado en Firestore. La función no espera: la despiertan.
• Escala a cero. Sin eventos, no hay instancias y no se paga cómputo. Diferencia radical con una VM del MIG, que cuesta lo mismo a las cuatro de la madrugada que en plena campaña.
• Escala hacia arriba sola. Si llegan mil eventos a la vez, la plataforma arranca instancias. No hay que configurar un autoescalador.
• Es efímera y sin estado. Una instancia procesa y puede desaparecer. Nada que se guarde en memoria o en disco local sobrevive de forma fiable.

Esa última propiedad es la que más cuesta interiorizar y la que produce más errores de diseño. El estado vive fuera: en Cloud SQL, en Firestore, en Cloud Storage, en BigQuery. Una función que acumula algo en una variable global y espera encontrarlo en la invocación siguiente funciona en las pruebas —porque reutiliza la misma instancia— y falla en producción de forma intermitente e inexplicable.

Este es el apartado que hay que entender bien para no equivocarse con la documentación antigua que sigue circulando.

Cloud Functions nació en 2016 con una plataforma propia. En 2022 apareció la 2ª generación, y el cambio no es cosmético:

Una Cloud Function de 2ª generación es un servicio de Cloud Run con un contenedor construido automáticamente por Google a partir de tu código, y sus disparadores de eventos son suscripciones de Eventarc.

Google construye el contenedor por ti usando buildpacks, lo despliega en Cloud Run y conecta Eventarc para que los eventos lleguen como peticiones HTTP. Todo lo que Cloud Run sabe hacer, la función lo hereda.

Las diferencias prácticas, que son las que importan al diseñar:

La concurrencia es la diferencia más importante. En la 1ª generación, cada instancia atendía una petición: 100 peticiones simultáneas significaban 100 instancias, con 100 arranques en frío y 100 conexiones a la base de datos. En la 2ª, una instancia con concurrencia 80 atiende 80 peticiones a la vez, lo que reduce drásticamente los arranques en frío, el coste y la presión sobre Cloud SQL —problema muy real: el número de conexiones de Cloud SQL es limitado, y una función de 1ª generación mal dimensionada agota el pool con una facilidad pasmosa—.

La regla en 2026: usa siempre la 2ª generación. --gen2 es obligatorio en los ejemplos de esta lección. La 1ª generación solo aparece en funciones antiguas que nadie ha migrado.

Y la pregunta natural: si una función de 2ª generación es un Cloud Run, ¿por qué no usar Cloud Run directamente? Es una pregunta excelente y tiene respuesta, pero la dejamos para el apartado 13, cuando tengas el contexto para valorarla.

El Functions Framework es la biblioteca que convierte una función Python normal en un servicio HTTP. Se instala como una dependencia más y usa decoradores.

La estructura mínima de una función son dos ficheros:

Tres detalles que conviene notar:

• El decorador @functions_framework.http marca el punto de entrada. El nombre de la función Python (comprobar_stock) es el que se pasa en --entry-point.
• request es un objeto de Flask. Si has escrito el catálogo con Flask, la API te resulta familiar: request.args, request.get_json(), request.headers.
• El valor de retorno sigue las convenciones de Flask: una cadena, una tupla (cuerpo, código) o una respuesta completa.

El despliegue:

Cada opción, y por qué está ahí:

--max-instances merece una explicación, porque su ausencia causa incidentes reales. Sin techo, un pico de tráfico —o un bucle infinito, o un ataque— puede arrancar cientos de instancias que abren cientos de conexiones a alpinashop-pedidos y tumban la base de datos. El escalado infinito no es una virtud si lo que hay detrás no escala igual. Poner un límite convierte una caída total en una degradación parcial, que es infinitamente preferible.

Es tentador desplegar con --allow-unauthenticated porque "es más fácil de probar". Es exactamente cómo se filtran datos.

Una función pública tiene una URL adivinable en un patrón conocido, está expuesta a todo internet, la puede invocar cualquiera tantas veces como quiera —y tú pagas cada invocación— y suele tener permisos IAM sobre bases de datos y buckets de tu proyecto. Es un endpoint privilegiado sin puerta.

Con --no-allow-unauthenticated, invocar la función exige el rol roles/run.invoker —de Cloud Run, coherente con el apartado 2—:

Y desde el catálogo, la llamada se autentica con un token OIDC:

El token lo obtiene la biblioteca de la identidad del entorno —la cuenta de servicio adjunta al pod de GKE— sin ninguna clave. Es el mismo mecanismo de las suscripciones push con OIDC de 04-04.

Los tres casos en los que una función sí puede ser pública, y qué hace falta en cada uno:

El caso del webhook merece una nota: una función pública que recibe notificaciones de pago debe validar la firma HMAC que el proveedor incluye en la cabecera. Sin esa validación, cualquiera puede enviar un POST diciendo "el pedido 1234 está pagado". Es un fallo que aparece con una frecuencia deprimente.

Una función por eventos no recibe una petición HTTP: recibe un CloudEvent, un formato estándar del sector —no una invención de Google— con metadatos comunes (id, source, type, time, subject) y un dato específico del tipo de evento.

En Python se declara con @functions_framework.cloud_event:

Eventarc es el enrutador universal de eventos de GCP. Recibe eventos de más de 130 fuentes, los normaliza a CloudEvents y los entrega al destino. Los disparadores más útiles:

El disparador por logs de auditoría es el menos conocido y uno de los más potentes: permite reaccionar a cualquier operación de la API de GCP. Por ejemplo, ejecutar una función cada vez que alguien modifica una regla de firewall en alpinashop-prod:

Una nota importante sobre Cloud Storage: se puede disparar directamente desde el bucket (storage.object.v1.finalized) o publicando en un topic de Pub/Sub y disparando desde ahí. AlpinaShop eligió en 05-05 la segunda opción, y la razón es sólida: con Pub/Sub en medio, varios consumidores pueden reaccionar al mismo evento. Hoy solo procesa imágenes; mañana, un segundo suscriptor puede actualizar el índice de búsqueda sin tocar nada de lo existente. Con el disparador directo, cada consumidor nuevo obliga a reconfigurar el bucket.

Aquí se cierra la punta suelta de 05-05. Recordemos el flujo diseñado entonces:

Paso 1: notificar el bucket al topic. Un solo comando, que probablemente ya está hecho desde 05-05:

El --object-prefix=productos/ evita procesar objetos que no son fotos de producto —logotipos, ficheros temporales—, y es la forma más barata de filtrar: el evento ni siquiera se genera.

Paso 2: la función. Está comentada por bloques porque cada uno resuelve un problema concreto:

Los tres detalles que hacen que esto funcione en producción, y que separan un ejemplo de tutorial de código real:

Los clientes fuera de la función. Crear un ImageAnnotatorClient implica resolver credenciales y establecer conexiones: cientos de milisegundos. Creándolo a nivel de módulo, se crea una vez por instancia y se reutiliza en todas las invocaciones que esa instancia atienda. En una función con concurrencia 20 y mil eventos, la diferencia es enorme.

La guarda contra el bucle infinito (paso 2). Es el error clásico de las funciones disparadas por Cloud Storage y merece que se explique despacio: la función escribe la miniatura en el mismo bucket, lo que genera un evento OBJECT_FINALIZE, que dispara la función, que genera otra miniatura, que dispara la función… Cada iteración cuesta invocaciones, llamadas a la Vision API —que se facturan— y filas en BigQuery. Un bucle así descubierto un lunes por la mañana puede haber consumido un presupuesto entero durante el fin de semana. Las tres defensas posibles son el prefijo en el filtro de notificación, la guarda en el código y escribir en otro bucket; usa al menos dos.

El row_ids en insert_rows_json. BigQuery deduplica por ese identificador durante una ventana de tiempo. Es una segunda red bajo la comprobación de idempotencia del paso 3.

Paso 3: desplegar con su identidad y sus permisos.

--memory=1Gi no es capricho: abrir una foto de producto de 12 megapíxeles con Pillow consume bastante memoria, y en la 2ª generación la CPU asignada crece con la memoria, así que además va más rápido. --retry activa los reintentos, que es el tema del apartado siguiente.

Esta es la parte que distingue una función que funciona de una función en la que se puede confiar. Y arranca de un hecho que ya se estableció en 04-04:

Pub/Sub garantiza la entrega al menos una vez. Tu función recibirá mensajes duplicados. No es una posibilidad remota: es una certeza estadística.

Los duplicados llegan por causas perfectamente normales: la función procesó correctamente pero tardó más que el plazo de confirmación; hubo un fallo de red al confirmar; la instancia se reinició tras procesar y antes de confirmar; o el evento se reenvió porque una invocación anterior lanzó una excepción.

Idempotente significa que procesar el mismo evento N veces produce el mismo resultado que procesarlo una vez. Analicemos las tres acciones de nuestra función:

La tercera es la peligrosa, y por eso el diseño incluye tres capas de defensa:

Capa 1, el identificador estable. gs://bucket/ruta#generacion identifica una versión concreta de un objeto. Fíjate en que la ruta sola no bastaría: si Dani sube una foto corregida con el mismo nombre, es un objeto distinto que sí debe reprocesarse, y la generation lo distingue.

Capa 2, la comprobación previa con una tabla ligera de control:

La ventana de 7 días es un compromiso deliberado: los duplicados de Pub/Sub llegan en segundos o minutos, no días, y limitar la consulta permite aprovechar el particionado de la tabla y no escanear el histórico completo en cada invocación. Es la misma lógica de coste de 04-01.

Capa 3, el row_ids de BigQuery, que deduplica automáticamente aunque las dos anteriores fallen por una condición de carrera.

Reintentos. Con --retry, si la función lanza una excepción, Pub/Sub no recibe confirmación y reentrega el mensaje. Y aquí hay una decisión de diseño que se hace mal constantemente:

Un error permanente reintentado es una función que falla eternamente sobre el mismo mensaje, consumiendo cuota y llenando los logs. La regla: lanza excepción solo si volver a intentarlo tiene alguna posibilidad de funcionar.

Dead letter. Aun con la distinción anterior, algún mensaje fallará indefinidamente. El topic de mensajes fallidos evita que bloquee la cola:

Tras cinco intentos, el mensaje va al DLQ en lugar de reintentarse para siempre. Y un DLQ que nadie mira es peor que no tener DLQ, porque genera una falsa sensación de control: hay que poner una alerta sobre su número de mensajes sin confirmar —exactamente el tipo de alerta que se configura en 06-04—.

Una instancia de función pasa por tres fases, y entender cuál es cara explica casi todo el comportamiento observado:

El arranque en frío es el tiempo desde que llega el evento hasta que tu código empieza a ejecutarse: aprovisionar la instancia, cargar el runtime, importar las dependencias y ejecutar el código a nivel de módulo. Va de unos cientos de milisegundos a varios segundos, y depende sobre todo de cuánto pesan tus importaciones.

Las cinco palancas para mitigarlo, ordenadas por eficacia real:

Cuándo importa el arranque en frío y cuándo no, que es la decisión que de verdad hay que tomar:

--min-instances cuesta dinero incluso sin tráfico, y ese es el precio de renunciar parcialmente a "escala a cero". Ponerlo por defecto en todas las funciones anula una de las ventajas económicas del modelo. Ponlo donde la latencia la percibe un cliente.

Sobre la concurrencia, una advertencia importante: con --concurrency=80, ochenta peticiones se ejecutan simultáneamente en el mismo proceso Python. Cualquier variable global mutable pasa a ser compartida:

La regla: a nivel de módulo, solo clientes y constantes. Todo estado mutable, dentro de la función.

Las tres cosas que toda función de producción necesita bien resueltas.

Variables de entorno para configuración no sensible:

Secretos desde Secret Manager, nunca como variable de entorno con el valor:

Con esa sintaxis, la función lee os.environ["API_KEY_PASARELA"] con normalidad, pero el valor no está en la configuración del despliegue: se inyecta en tiempo de ejecución desde Secret Manager (03-06). Consecuencias prácticas: el valor no aparece en la consola, no queda en el historial de despliegues, se puede rotar sin redesplegar si usas :latest, y el acceso queda registrado en los logs de auditoría. También se pueden montar como fichero con --set-secrets='/etc/claves/api=secreto:latest', que es preferible para valores grandes como certificados.

Y el detalle que se olvida: la cuenta de servicio de la función necesita roles/secretmanager.secretAccessor sobre ese secreto concreto, concedido en la política del secreto.

La identidad. Por defecto, una función usa la cuenta de servicio de Compute Engine del proyecto, que suele tener el rol Editor —el mismo antipatrón de 06-01—. Siempre --service-account con una cuenta propia por función. Una función que solo escribe en BigQuery no debe poder borrar buckets.

Por defecto, una función vive fuera de tu VPC: puede salir a internet pero no puede alcanzar recursos con IP privada. Si alpinashop-pedidos tiene solo IP privada —como debe ser, según 03-01— una función no llega.

El puente es un conector de acceso a VPC sin servidor:

Detalles que importan:

• El rango /28 debe estar libre y no solaparse con sn-web-euw1 ni sn-datos-euw1. Es un requisito estricto y una fuente habitual de errores.
• El conector se factura por instancia y hora, esté o no en uso. Con --min-instances=2 pagas dos máquinas pequeñas permanentemente. Rompe parcialmente el "escala a cero", así que se comparte entre todas las funciones que lo necesiten.
• --egress-settings=private-ranges-only envía por la VPC solo el tráfico a rangos privados; el resto sale por internet directamente. Con all-traffic, todo pasa por la VPC y sale por el Cloud NAT alpinashop-nat-euw1 de 03-01, lo que da una IP de salida fija —útil si un tercero exige lista blanca de IP—.

Consejo: no añadas un conector "por si acaso". Si la función solo habla con APIs de Google —Vision, BigQuery, Storage, como procesar-imagen-producto— no lo necesita, y añadirlo es coste y complejidad gratuitos.

Los límites de la 2ª generación que conviene tener presentes —verifica siempre los valores vigentes en la documentación oficial—:

El coste tiene cuatro componentes, y hay un nivel gratuito mensual generoso:

Cálculo orientativo para procesar-imagen-producto. Supongamos 20.000 imágenes al mes, 1 GiB de memoria, 3 segundos por imagen:

• Invocaciones: 20.000 → cubiertas de sobra por el nivel gratuito.
• GB-segundo: 20.000 × 3 s × 1 GiB = 60.000 GB-s, mayormente dentro del nivel gratuito.
• GHz-segundo: proporcional, mismo orden.
• Coste real de cómputo: prácticamente cero.

Y ahora el dato que importa de verdad: la Vision API de esas 20.000 imágenes, con tres funcionalidades cada una, cuesta un orden de magnitud más que toda la ejecución de la función. La lección económica es que en las arquitecturas por eventos el cómputo casi nunca es el coste principal: lo son las APIs que se llaman y los datos que se mueven. Optimizar la memoria de la función mientras se hacen llamadas redundantes a una API de pago es optimizar lo que no importa.

Dicho esto, tres formas de que la factura se dispare de verdad:

1. Bucles infinitos (apartado 6). El más caro con diferencia.
2. --min-instances en funciones que no lo necesitan. Es coste fijo 24×7 y anula la ventaja del modelo.
3. Timeout largo con errores colgados. Una función con --timeout=540s que se queda esperando a un servicio caído paga nueve minutos por invocación fallida. Timeouts cortos y ajustados a la realidad.

En local, el Functions Framework levanta un servidor:

Y se simula un evento de Pub/Sub con la estructura real, base64 incluido:

Mejor aún, pruebas unitarias que no necesitan levantar nada:

La primera prueba merece un comentario: verifica que no se llama a la Vision API para una miniatura. Es la prueba que protege contra el fallo más caro posible de esta arquitectura, y cuesta seis líneas.

Despliegue desde Cloud Build, encajando con 06-01 y 06-02:

La cuenta de servicio de Cloud Build necesita roles/cloudfunctions.developer y roles/iam.serviceAccountUser sobre sa-procesar-imagen —este segundo permiso se olvida siempre y produce un error de permisos que no menciona la palabra "función"—.

Volvemos a la pregunta que quedó abierta en el apartado 2: si una función de 2ª generación es un Cloud Run, ¿por qué elegir una función?

Elige Cloud Functions cuando:

• El trabajo es una sola cosa disparada por un evento: procesar-imagen-producto es el ejemplo perfecto.
• No necesitas dependencias del sistema fuera de lo habitual.
• Quieres el camino más corto entre "tengo una idea" y "está funcionando".
• El equipo no quiere mantener Dockerfiles para cada pieza pequeña.

Elige Cloud Run cuando:

• Es una aplicación con varias rutas, como el catálogo Flask.
• Necesitas controlar la imagen: una versión concreta de una biblioteca del sistema, un binario, un modelo empaquetado.
• Ya tienes un contenedor —AlpinaShop lo tiene desde 02-05—.
• Quieres portabilidad real entre GKE, Cloud Run y cualquier otro sitio.

Para AlpinaShop, la asignación queda así, coherente con la decisión DA-001 de llevar el catálogo a Cloud Run (que se desarrolla en 07-02):

Hay un antipatrón que aparece cuando las funciones gustan demasiado, y conviene reconocerlo antes de caer en él:

Seis funciones encadenadas para procesar un pedido. Parece modular. En realidad es un monolito troceado con latencia de red entre sus líneas de código, y hereda todos los inconvenientes de ambos mundos:

• Latencia acumulada: seis arranques en frío posibles en lugar de uno.
• Depuración muy difícil: seguir una petición exige correlacionar seis conjuntos de logs. Es exactamente el problema que resuelve el rastreo distribuido de 06-06, pero que es mejor no tener.
• Sin transacciones: si funcion-cobrar funciona y funcion-notificar falla, el sistema queda en un estado incoherente y hay que compensar a mano.
• Cambios que cruzan seis despliegues: modificar el flujo obliga a coordinar seis funciones.
• Coste multiplicado: seis invocaciones y seis veces la sobrecarga.

La señal de alarma es sencilla: si tus funciones se llaman entre sí de forma síncrona, probablemente deberían ser un solo servicio. Y si de verdad necesitas un flujo de varios pasos con estado, la herramienta correcta no es encadenar funciones: es Workflows, la orquestación que AlpinaShop ya eligió en 04-06, que gestiona el estado, los reintentos y los errores de forma explícita.

Las funciones brillan cuando son hojas del árbol: reaccionan a un evento, hacen su trabajo y terminan. Cuando empiezan a ser nodos intermedios que coordinan a otras, se han elegido mal.

El bucle infinito de Cloud Storage. Una función disparada por un bucket que escribe en ese mismo bucket. Es el error más caro de esta lección. Defiéndete con al menos dos de las tres barreras: prefijo en el filtro de notificación, guarda en el código y bucket distinto para las salidas.

Suponer que los eventos llegan exactamente una vez. Llegan al menos una vez. Toda función por eventos necesita un identificador estable y una comprobación de idempotencia. Sin eso, tus datos tendrán duplicados y no sabrás por qué.

Reintentar errores permanentes. Una imagen corrupta no se arregla al quinto intento. Lanza excepción solo si reintentar puede funcionar; para lo demás, registra y retorna con normalidad.

Crear los clientes dentro de la función. Cientos de milisegundos desperdiciados en cada invocación. Los clientes, a nivel de módulo. Pero solo clientes y constantes: cualquier estado mutable global es una condición de carrera esperando a que subas la concurrencia.

Desplegar con --allow-unauthenticated "para probar". Ese "para probar" se queda. Usa --no-allow-unauthenticated y concede run.invoker a quien deba llamarla.

Dejar la cuenta de servicio por defecto. Es la de Compute Engine, con Editor. Una cuenta propia por función, con los permisos exactos.

No poner --max-instances. Un pico de eventos puede abrir cientos de conexiones a Cloud SQL y tumbar la base de datos. El escalado sin límite no es una virtud si lo de detrás no escala igual.

Meter secretos en variables de entorno. Usa --set-secrets con Secret Manager: no queda en la configuración, no aparece en la consola y se rota sin redesplegar.

Añadir un conector de VPC "por si acaso". Cuesta dinero permanentemente. Solo si necesitas alcanzar IP privadas.

Usar la 1ª generación por copiar un tutorial antiguo. --gen2 siempre: concurrencia, más memoria, más tiempo y muchas más fuentes de eventos.

Y el consejo que resume el apartado 13: si tus funciones se llaman unas a otras, para y replantea. Probablemente sea un servicio, o un Workflow.

AlpinaShop quiere una función disparada por el topic pedidos-nuevos que envíe un correo de confirmación al cliente y añada una fila a la tabla de facturación en BigQuery. Enviar un correo no es idempotente: el cliente se molesta si recibe tres. Diseña la función explicando el mecanismo de idempotencia, qué errores reintentarías y cuáles no, y qué configuración de despliegue usarías. Indica el punto exacto donde una condición de carrera podría producir un correo duplicado y cómo lo mitigarías.

Para cada uno de estos cuatro casos de AlpinaShop, elige Cloud Function, Cloud Run o Workflows, y justifica la decisión con criterios de esta lección: (a) generar el PDF de la factura de un pedido, unos 2 segundos por factura, disparado tras el pago; (b) el panel de administración interno, unas 30 rutas HTTP, usado por 5 personas en horario de oficina; (c) el proceso nocturno que recalcula recomendaciones, unos 40 minutos, con 6 pasos secuenciales dependientes; (d) redimensionar imágenes de opiniones de clientes, con picos de 500 imágenes en pocos minutos tras una campaña.

Un lunes, Marta ve que la factura del fin de semana ha sido 40 veces la habitual. Los datos: procesar-imagen-producto registró 1,2 millones de invocaciones en 48 horas frente a las 600 habituales; la tabla imagenes_vision tiene 1,2 millones de filas nuevas, muchas con la misma ruta_gcs; el bucket alpinashop-catalogo ha crecido 300 GB; y el DLQ imagenes-subidas-dlq está vacío. El viernes se desplegó un cambio "menor": guardar también una versión en blanco y negro de cada foto. Diagnostica la causa, explica por qué el DLQ vacío es una pista y no una tranquilidad, y detalla las medidas de contención inmediata y de prevención.

Solución 1

El problema central: la función tiene dos efectos con propiedades opuestas. Insertar en BigQuery es controlable con row_ids; enviar un correo es irreversible. Una vez enviado, no hay deshacer.

Mecanismo de idempotencia con marca previa al envío. La clave es registrar la intención antes de la acción irreversible, con una escritura condicional atómica. Firestore encaja mejor que BigQuery aquí porque ofrece transacciones y latencia baja:

Clasificación de errores:

Despliegue:

--min-instances=1 aquí sí se justifica: un cliente que acaba de pagar espera su confirmación, y dos segundos de arranque en frío en ese momento se notan.

La condición de carrera y su mitigación. El hueco está entre el create() y el enviar_correo(). Si la instancia muere justo ahí, la reserva queda en estado enviando para siempre y el cliente nunca recibe el correo, porque las reentregas verán la reserva y se retirarán.

El código lo mitiga con el temporizador de 300 segundos: una reserva enviando más antigua que eso se considera huérfana y se reintenta. La contrapartida es explícita y hay que asumirla: si la instancia no murió sino que simplemente tardó mucho, se enviarán dos correos.

Y aquí está la lección de fondo: con una acción externa irreversible no existe la garantía de exactamente una vez. Solo puedes elegir de qué lado fallar:

Para un correo de confirmación, un duplicado ocasional es molesto pero inocuo, mientras que no enviarlo genera una llamada a atención al cliente. Por eso el temporizador es la elección correcta aquí. Para un cargo en tarjeta, la respuesta sería la contraria, y la solución adecuada pasaría por una clave de idempotencia del propio proveedor de pago.

Solución 2

(a) PDF de factura: Cloud Function. Es el caso canónico: un evento, una acción acotada, 2 segundos de trabajo, sin dependencias exóticas. Disparada por pedidos-nuevos o por un topic propio de "pago confirmado", con --memory=512Mi y --max-instances moderado. Matiz: si la generación del PDF necesitara fuentes corporativas o LaTeX, la dependencia del sistema empujaría hacia Cloud Run con un contenedor propio.

(b) Panel de administración: Cloud Run. Treinta rutas HTTP son una aplicación, no una función. Una Cloud Function tiene un punto de entrada, y meter un enrutador dentro sería usar la herramienta al revés. Además el patrón de uso —cinco personas en horario de oficina— hace que escalar a cero por las noches y fines de semana sea ideal, y ese es precisamente Cloud Run. --min-instances=0, y si el arranque en frío molesta a primera hora, --min-instances=1 solo en horario laboral. Es coherente con DA-001.

(c) Recálculo nocturno de 40 minutos: Workflows. Dos razones, cada una suficiente. Primera, 40 minutos superan el límite de 9 minutos de una función por eventos. Segunda, y más importante: seis pasos secuenciales dependientes son orquestación, y encadenarlos con funciones sería el monolito distribuido del apartado 13. Workflows —ya elegido en 04-06— gestiona el estado, los reintentos por paso y los errores explícitamente, y cada paso invoca lo que corresponda: un Cloud Run Job, un trabajo de BigQuery o un pipeline de Vertex AI.

(d) Redimensionar imágenes de opiniones: Cloud Function. Es idéntico a procesar-imagen-producto: un evento, una acción, sin estado. Los picos de 500 imágenes son exactamente donde el modelo brilla —escala solo y vuelve a cero después—. Configuración: --memory=1Gi, --max-instances=100 para que el pico se absorba rápido, --min-instances=0 porque nadie espera en tiempo real, y --retry con idempotencia por generation.

El criterio que unifica los cuatro: cuenta cuántas cosas distintas hace la pieza y cuánto tarda. Una cosa y poco tiempo → función. Muchas rutas → servicio. Muchos pasos coordinados → flujo de trabajo. Y cuando dudes entre función y servicio para algo que ya está contenedorizado, Cloud Run casi siempre gana por portabilidad.

Solución 3

Diagnóstico: un bucle infinito, exactamente el del apartado 6.

El cambio "menor" del viernes añadió la escritura de una versión en blanco y negro en el mismo bucket, y con toda probabilidad en un prefijo que no es productos/miniaturas/, que es lo único que la guarda del código comprueba. Reconstruyendo la secuencia:

1. Se sube productos/piolet.jpg → evento → la función la procesa.
2. Escribe productos/miniaturas/piolet.jpg → evento → ignorada por la guarda. Correcto.
3. Escribe productos/bn/piolet.jpg → evento → la guarda NO lo cubre → se procesa.
4. Al procesar productos/bn/piolet.jpg escribe productos/bn/bn/piolet.jpg → evento → se procesa…

Cada nivel genera el siguiente. El crecimiento es exponencial hasta que algo lo frena. Las cuatro evidencias encajan sin excepción: 1,2 millones de invocaciones (recursión); filas repetidas con la misma ruta_gcs en imagenes_vision (cada nivel escribe una fila, y la idempotencia no protege porque cada objeto derivado es una ruta distinta); 300 GB de crecimiento (los objetos generados); y la factura disparada, dominada por la Vision API, no por la función.

Por qué el DLQ vacío es una pista y no una tranquilidad. El instinto dice "el DLQ está vacío, nada ha fallado". Es exactamente al revés: el DLQ vacío confirma que todo funcionó correctamente. La función no tenía ningún error; hacía perfectamente lo que se le pidió, un millón doscientas mil veces. Es el peligro de los sistemas por eventos: el fallo caro no produce errores, produce éxitos. Ninguna alerta basada en tasa de error habría detectado esto. La que sí lo habría detectado es una alerta sobre el volumen de invocaciones —tema de 06-04—, y su ausencia es el verdadero hallazgo del incidente.

Contención inmediata, en este orden:

Poner --max-instances=0 en lugar de borrar la función es deliberado: detiene el sangrado de inmediato, conserva toda la configuración para el diagnóstico y es reversible en un comando.

Limpieza: borrar los objetos derivados recursivamente (productos/bn/bn/... y siguientes) conservando el primer nivel si resulta útil; eliminar de imagenes_vision las filas cuya ruta_gcs contenga /bn/; y comprobar si algún proceso posterior —el índice de búsqueda, productos_color de 05-05— consumió esos datos y necesita rehacerse.

Prevención, en cinco medidas:

La tercera medida es la lección de diseño más transferible. La guarda original era una lista negra: "si empieza por productos/miniaturas/, ignorar". Una lista negra falla siempre que aparece un caso nuevo, y aparecerá. Lo correcto es una lista blanca:

Con esa versión, el cambio del viernes habría sido inocuo: la función solo procesa lo que está explícitamente permitido. En una arquitectura por eventos, prohibir lo conocido es frágil; permitir solo lo conocido es robusto.

Y la reflexión final del incidente: no hubo un fallo técnico. Hubo un cambio de una línea, revisado por nadie, en un sistema donde escribir en un bucket significa disparar código. Tres cosas lo habrían impedido y las tres están en este módulo: la revisión de código de 06-02 —alguien habría preguntado dónde se escribe el fichero nuevo—, la prueba unitaria del apartado 12 —que verifica que no se llama a Vision para objetos derivados—, y la observabilidad de 06-04 —una alerta de volumen que avisa en minutos—. La factura de 40× es el precio de no tener ninguna de las tres.

La punta suelta del módulo 5 está cerrada. procesar-imagen-producto existe, se dispara con imagenes-subidas, llama a la Vision API, genera la miniatura, escribe en alpinashop_analitica y no despierta a nadie de madrugada.

Sabes qué es FaaS y cuál es su unidad de despliegue —la función—, con las cuatro propiedades que lo definen: se dispara por eventos, escala a cero, escala solo hacia arriba, y es efímera y sin estado, con la consecuencia práctica de que todo lo que deba sobrevivir vive fuera.

Entiendes qué es hoy una Cloud Function de 2ª generación: un servicio de Cloud Run con un contenedor construido por Google y disparadores gestionados por Eventarc. Y sabes qué te da eso —concurrencia configurable en lugar de una petición por instancia, hasta 60 minutos en HTTP, hasta 32 GB, reparto de tráfico y más de 130 fuentes de eventos— con la regla clara de usar --gen2 siempre.

Sabes escribir una función HTTP con el Functions Framework y desplegarla con las opciones que importan, incluido --max-instances, porque el escalado sin límite no es una virtud si Cloud SQL no escala igual. Y sabes que casi ninguna función debe ser pública: --no-allow-unauthenticated, run.invoker a quien corresponda y token OIDC en el llamante, con las tres excepciones legítimas y lo que exige cada una.

Conoces las funciones por eventos, los CloudEvents y la tabla de qué dispara qué —Pub/Sub, Cloud Storage, Firestore y los logs de auditoría—, y por qué AlpinaShop pasa por un topic en lugar de disparar directamente del bucket: para que mañana un segundo consumidor pueda reaccionar sin tocar nada.

Tienes el caso completo resuelto, con los tres detalles que lo hacen viable en producción: clientes creados a nivel de módulo, la guarda contra el bucle infinito y el row_ids de BigQuery. Y tienes la disciplina que separa una función que funciona de una en la que se puede confiar: idempotencia con identificador estable —ruta más generation—, comprobación previa acotada en el tiempo y deduplicación en destino; la distinción entre errores transitorios que se reintentan y permanentes que no; y un dead letter con alerta, porque un DLQ que nadie mira es peor que no tenerlo.

Sabes qué es un arranque en frío, las cinco palancas para mitigarlo y —más importante— cuándo importa y cuándo no: --min-instances donde lo percibe un cliente, cero en el procesamiento por lotes. Conoces el peligro de las variables globales mutables con concurrencia alta, con la regla de que a nivel de módulo solo van clientes y constantes. Sabes inyectar configuración con variables de entorno y secretos con --set-secrets desde Secret Manager, dar a cada función su propia cuenta de servicio, y conectar a la VPC con un conector cuando —y solo cuando— hay que alcanzar una IP privada.

Tienes los límites y el coste con su cálculo orientativo, y la lección económica que trasciende el ejemplo: en una arquitectura por eventos, el cómputo casi nunca es el coste principal; lo son las APIs que llamas y los datos que mueves. Sabes probar en local, escribir la prueba unitaria de seis líneas que protege contra el fallo más caro posible, y desplegar desde Cloud Build.

Y tienes el criterio del apartado 13: función para una cosa disparada por un evento, servicio para una aplicación con muchas rutas, flujo de trabajo para varios pasos coordinados, con la advertencia contra el monolito distribuido de funciones y su señal de alarma —si tus funciones se llaman entre sí de forma síncrona, replantea—.

Ahora mira el estado de AlpinaShop. Hay una tienda en GKE, una función procesando imágenes, pipelines de datos, modelos entrenándose solos, un pipeline de CI/CD y una infraestructura de red que sostiene todo eso. Muchas piezas. Muchas más de las que cabían hace tres módulos.

Y sigue habiendo una sola forma de saber si funcionan: que un cliente escriba un correo diciendo que la web va lenta.

Ese es el problema de 06-04. Toca dejar de mirar la consola y empezar a medir: métricas, paneles y alertas con Cloud Monitoring, para enterarse de los problemas antes que los clientes.