2. Constructor vs dueño del sistema: dos responsabilidades distintas

Descripción

Al terminar esta lección vas a poder distinguir con claridad dos responsabilidades que casi siempre viven en la misma persona pero que son trabajos distintos: la del constructor, que entrega un workflow que funciona, y la del dueño del sistema, que responde por ese workflow cuando la realidad lo golpea. Vas a conocer las tres preguntas que definen a un dueño de sistema —las tres que, hechas antes de poner algo en producción, cambian la calidad de todo lo que construyes— y vas a ver cada una aplicada al workflow order-triage de Cumbre.

Esto importa porque el salto entre las dos responsabilidades es exactamente donde el mercado empieza a pagar más. Construir un workflow que procesa un pedido correcto es una habilidad valiosa y es tu piso. Poder mirar ese mismo workflow y decir "esto va a cobrar dos veces el día que el proveedor reintente, y así lo evito" es lo que separa a alguien a quien le confías una automatización de juguete de alguien a quien le confías el flujo por el que pasa el dinero de la empresa. Es, literalmente, una de las preguntas que se hacen en las entrevistas para roles de automatización: "¿qué pasa si esto se ejecuta dos veces?".

Conexión con el módulo: en la lección 1 viste el drama —order-triage que se dispara dos veces y cobra dos veces— y las cuatro promesas de la guía. Esta lección le pone nombre a las dos personas que están detrás de ese drama: la que construyó el workflow (que hizo un buen trabajo) y la que tiene que responder por él (que necesita otras herramientas). A partir de la lección 3 vamos a construir el vocabulario técnico —"confiable", "efecto", "al menos una vez"— pero ese vocabulario se entiende mucho mejor cuando ya tienes clara la diferencia de rol que esta lección define. Las tres preguntas que aprendes aquí reaparecen en cada lección de la guía: son el esqueleto de la mentalidad de dueño.

Dos trabajos que parecen uno

Piensa en la diferencia entre cocinar un plato y dirigir la cocina de un restaurante.

Cocinar un plato es una habilidad concreta y exigente. Necesitas técnica, buenos ingredientes, tiempo. Cuando el plato sale bien —bien cocido, bien sazonado, bien presentado— hiciste un trabajo excelente. Cualquiera que lo pruebe lo confirma. El plato funciona.

Dirigir la cocina es otra cosa. El plato tiene que salir bien no una vez, sino cuatrocientas veces esa noche. Tiene que salir igual de bueno cuando el salón está lleno y la cocina va contra reloj. Tiene que salir aunque a un cocinero se le queme la primera tanda y haya que rehacerla sin que el cliente espere el doble. Tiene que salir aunque el proveedor de pescado no haya llegado y toque improvisar. El que dirige la cocina no pregunta "¿este plato está bueno?"; pregunta "¿esta cocina puede sacar este plato una y otra vez, toda la noche, cuando las cosas salen mal?".

Las dos son habilidades reales. La segunda no es "más avanzada" en el sentido de que use técnicas más difíciles; el que dirige quizá cocina peor que su mejor cocinero. Es distinta: se ocupa de la repetición, del error, de la recuperación. Y un restaurante no sobrevive con buenos cocineros si nadie piensa como el que dirige.

En n8n, tú eres las dos personas. Cuando armas un workflow, cocinas el plato: conectas los nodos, ajustas la lógica, lo pruebas, sale bien. Ese es el constructor. Pero en el momento en que ese workflow entra en producción y empieza a procesar pedidos reales, aparece la segunda responsabilidad: alguien tiene que responder cuando el mismo pedido llega dos veces, cuando el CRM se cae justo después del cobro, cuando el proveedor cambia el formato del pedido sin avisar. Ese es el dueño del sistema. Y casi siempre eres tú también, tres semanas después, cuando el problema aparece.

El punto de esta lección no es que uno sea mejor que el otro. Es que son dos conjuntos de preguntas distintas, y que el error más caro en automatización es hacer solo el primer conjunto y creer que terminaste.

Las preguntas del constructor

El constructor hace un trabajo real y bien definido. Sus preguntas son sobre si el workflow hace lo que tiene que hacer en el caso normal:

• ¿Los nodos están bien conectados?
• ¿La lógica de clasificación es correcta?
• ¿El pedido llega al CRM con los campos correctos?
• ¿El cobro usa el monto correcto?
• ¿El correo tiene el texto y el destinatario correctos?

Estas preguntas son necesarias. Un workflow que falla en cualquiera de ellas ni siquiera funciona en la demo. Y responderlas bien no es trivial: requiere entender el modelo de datos, las expresiones, los nodos. Todo eso lo aprendiste en las guías anteriores, y es la base sobre la que se para esta.

Fíjate en lo que tienen en común todas las preguntas del constructor: asumen una sola ejecución, con datos correctos, y con todos los servicios funcionando. El constructor pregunta "¿esto está bien construido?", y la respuesta se verifica ejecutándolo una vez. Ese es su horizonte: una corrida, el camino feliz.

Y aquí está la trampa: el camino feliz casi siempre funciona. Un workflow razonablemente construido procesa un pedido correcto sin problemas la enorme mayoría de las veces. Por eso la demo sale bien. Por eso da confianza. Y por eso el problema del dueño del sistema es tan traicionero: no aparece cuando pruebas, aparece cuando la realidad te manda el caso que no probaste.

Las tres preguntas del dueño del sistema

El dueño del sistema empieza justo donde el constructor termina. Da por hecho que el workflow funciona en el caso normal —eso ya lo verificó el constructor— y pregunta por todo lo demás. Sus preguntas se pueden resumir en tres, y quiero que te las aprendas, porque son la columna vertebral de la guía entera.

Pregunta 1: ¿Qué pasa si esto se dispara dos veces?

Esta es la pregunta central de la guía, y ya viste por qué en la lección 1. El mismo evento puede llegar dos veces —el proveedor reintenta, el humano hace doble clic, n8n reintenta— y un workflow que no está diseñado para eso duplica sus efectos.

El constructor no se hace esta pregunta porque en la demo el pedido llega una vez. El dueño del sistema se la hace siempre, antes de poner nada en producción, porque sabe que "una vez" es una suposición, no una garantía.

Aplicada a order-triage: si el pedido evt_8f2a91c4 llega dos veces, ¿qué pasa? Hoy, sin protección: dos registros en el CRM, dos cobros, dos correos. La pregunta no es retórica; tiene una respuesta concreta y mala, y el trabajo del dueño es cambiar esa respuesta.

Pregunta 2: ¿Qué pasa si el servicio de destino cae a la mitad?

Un workflow como order-triage toca varios servicios externos: el CRM, la pasarela de pago, el servicio de correo. Ninguno de ellos está garantizado a estar disponible en el momento exacto en que tu workflow lo necesita. Se caen, tienen mantenimiento, se saturan, dan tiempos de espera.

La pregunta del dueño es: si el workflow ya hizo la mitad de su trabajo y el siguiente servicio no responde, ¿en qué estado queda el sistema? Esto se llama fallo parcial, y es más peligroso que un fallo total, porque un fallo total no hace nada —y no hacer nada es fácil de detectar y de reintentar— mientras que un fallo parcial deja el sistema a medias: hizo unos efectos y otros no.

Aplicada a order-triage: imagina que el nodo Create charge cobra con éxito, pero justo después el servicio de correo está caído y Send Email falla. El cliente pagó pero no recibió confirmación. Si ahora alguien —o n8n— reintenta el workflow completo para "arreglarlo", el reintento vuelve a pasar por Create charge y cobra otra vez. El intento de recuperarse del fallo parcial causa el duplicado. Esta interacción entre fallo parcial y reintento es una de las más importantes de toda la guía, y la retomamos en las lecciones 5 y 6 y en el Módulo 6 completo.

Pregunta 3: ¿Qué pasa si el esquema de entrada cambia?

Tu workflow recibe datos de alguien más —un proveedor, otra parte del sistema, un formulario—. Ese alguien puede cambiar el formato de los datos sin avisarte. Un campo que se llamaba amount ahora se llama total. Un número que venía como número ahora viene como texto. Un campo que siempre estaba presente ahora a veces falta.

La pregunta del dueño es: cuando eso pase —y va a pasar— ¿el workflow falla ruidosamente y para, o sigue adelante haciendo cosas raras con datos que no entiende? La respuesta ideal no es "el workflow nunca falla"; es "el workflow falla en la frontera, antes de tocar nada, en vez de fallar a la mitad después de haber cobrado".

Aplicada a order-triage: si mañana la tienda en línea empieza a mandar amount como texto —"2154.00" en vez de 2154.00— el nodo Create charge podría cobrar un monto equivocado, o fallar de una forma que dispare un reintento, que a su vez duplica. Un cambio silencioso aguas arriba se convierte en un cobro incorrecto o duplicado aguas abajo. Esta pregunta es la semilla del Módulo 3 entero, que trata sobre los contratos entre workflows: la promesa explícita de qué formato entra y qué formato sale.

Las dos columnas, lado a lado

Si te sirve verlo condensado, esta tabla pone las preguntas de cada rol frente a frente. La misma pieza de order-triage, dos formas de interrogarla:

El constructor pregunta	El dueño del sistema pregunta
¿Los nodos están bien conectados?	¿Qué pasa si el flujo entero corre dos veces?
¿El cobro usa el monto correcto?	¿Qué pasa si el cobro se repite?
¿El registro llega al CRM con los campos correctos?	¿Qué pasa si el CRM cae justo después de cobrar?
¿El correo tiene el destinatario correcto?	¿Qué pasa si el correo falla y alguien reintenta todo?
¿El agente clasifica bien?	¿Qué pasa si mañana el pedido llega con otro formato?

Mira la diferencia de tiempo verbal, que no es casual. El constructor pregunta en presente sobre un caso: "¿esto está bien?". El dueño pregunta en condicional sobre el futuro: "¿qué pasaría si…?". El constructor verifica lo que hay; el dueño imagina lo que vendrá. Y como lo que vendrá incluye reintentos, caídas y cambios que hoy no están, sus preguntas no se pueden responder ejecutando el workflow una vez. Se responden pensando, y esa es la disciplina que esta guía entrena.

El patrón detrás de las tres preguntas

Fíjate en lo que comparten las tres. El constructor pregunta por lo que el workflow hace cuando todo sale bien. El dueño pregunta por lo que el workflow hace cuando algo sale mal, y en particular por si, al salir mal, hace daño. Las tres preguntas son variaciones de una sola preocupación:

No basta con que el workflow funcione. Tiene que no hacer daño cuando no funciona.

Esa frase es el corazón de la mentalidad de dueño, y la lección 3 la convierte en un criterio técnico preciso. Por ahora quédate con la forma de las tres preguntas, porque las vas a usar en cada auditoría de aquí en adelante.

Ejemplo trabajado: order-triage visto por los dos roles

Vamos a mirar el mismo workflow con los dos pares de ojos, para que la diferencia deje de ser abstracta.

Este es order-triage, otra vez:

Webhook  ──►  Get customer  ──►  AI Agent      ──►  Create CRM order  ──►  Create charge  ──►  Send Email
(recibe       (lee la ficha      (clasifica         (crea el registro       (cobra en la        (confirma al
 el pedido)    del cliente)       el pedido)         en el CRM)              pasarela)           cliente)

Cómo lo ve el constructor. "El webhook recibe el pedido. Leo la ficha del cliente para tener su información. El agente clasifica el pedido por prioridad y categoría. Creo el registro en el CRM con los datos del pedido y la clasificación. Genero el cobro por el monto del pedido. Mando el correo de confirmación. Lo probé con un pedido de Luna Coffee y salió perfecto: registro creado, cobro generado, correo recibido." Y tiene razón. Como pieza construida, está bien hecha.

Cómo lo ve el dueño del sistema. Toma el mismo workflow y le hace las tres preguntas:

¿Qué pasa si se dispara dos veces? Dos registros, dos cobros, dos correos. El cliente paga el doble. Riesgo alto, sin protección.

¿Qué pasa si un servicio cae a la mitad? Si Create charge funciona pero Send Email falla, el cliente pagó sin confirmación. Y si se reintenta el workflow completo para recuperarse, vuelve a cobrar. Fallo parcial que un reintento convierte en duplicado.

¿Qué pasa si el esquema cambia? Si amount empieza a llegar como texto, el cobro puede salir con un monto raro o fallar y disparar un reintento. Ninguna validación en la frontera.

Mismo workflow. El constructor ve una pieza terminada; el dueño ve tres agujeros. Y aquí está lo importante: el dueño no está diciendo que el constructor hizo mal su trabajo. El workflow está bien construido. Lo que falta es la segunda capa, la que se ocupa de la repetición, del fallo parcial y del cambio. Esa capa es esta guía.

Qué esperar cuando hagas este ejercicio tú. Cuando tomes uno de tus propios workflows y le hagas las tres preguntas, lo más común es que descubras que nunca las habías pensado, y que las respuestas te incomoden. Esa incomodidad es exactamente el resultado esperado. Significa que pasaste de ver un workflow terminado a ver un sistema con riesgos concretos. No es que tus workflows fueran malos; es que los estabas mirando con un solo par de ojos.

La secuencia que convierte un fallo en un cobro doble

La pregunta 2 —el fallo parcial— es la más difícil de ver de las tres, porque el daño no lo causa el fallo directamente, sino el intento de recuperarse de él. Vale la pena seguir la secuencia paso a paso, porque es el patrón que vas a reconocer una y otra vez en la guía.

Imagina esta línea de tiempo en order-triage, con el pedido ORD-2041:

Momento	Qué pasa	Estado del sistema
1	Llega el pedido. Se lee la ficha del cliente y se clasifica.	Todo bien, sin efectos todavía
2	Create CRM order crea el registro.	1 registro en el CRM
3	Create charge cobra $2154.	1 registro, 1 cobro real
4	Send Email intenta mandar el correo, pero el servicio está caído. Falla.	1 registro, 1 cobro, 0 correos. La ejecución queda marcada como fallida.
5	Alguien ve la ejecución en rojo y presiona "reintentar el workflow completo" para arreglar el correo.	La ejecución arranca desde el principio
6	El reintento vuelve a pasar por Create CRM order.	2 registros en el CRM
7	El reintento vuelve a pasar por Create charge.	2 registros, 2 cobros
8	Ahora sí, Send Email funciona y manda el correo.	2 registros, 2 cobros, 1 correo

Mira lo que acaba de pasar. El problema original era chico y honesto: un correo que no salió. La intención era buena: arreglarlo reintentando. Y el resultado es peor que el problema original: un cobro duplicado. El reintento, que existe para recuperarse de fallos, se convirtió en la causa del duplicado, porque volvió a ejecutar efectos que ya se habían hecho.

Este es el nudo que la guía desata. Un dueño del sistema, viendo esta secuencia, saca dos conclusiones que vas a desarrollar en los módulos siguientes: primero, que reintentar solo es seguro si los efectos son idempotentes (Módulo 2 y Módulo 6); y segundo, que hay que poder reintentar solo la parte que falló —el correo— en lugar del workflow completo, lo cual requiere saber qué ya se hizo (Módulo 4). Por ahora, quédate con la lección incómoda: un reintento ingenuo sobre un flujo con efectos no protegidos no arregla el fallo, lo duplica.

Por qué esto es también una conversación de carrera

Vale la pena decir esto sin rodeos, porque es parte de por qué vale la pena aprenderlo. Las dos responsabilidades no se pagan igual.

Un rol que solo construye workflows —que arma flujos a partir de requerimientos claros— es valioso, pero es reemplazable y se cotiza como tal. Un rol que es dueño de un sistema —que responde cuando algo se dispara dos veces, que diseña para el fallo, que puede explicar por qué su automatización no cobra de más— es otra categoría. En las descripciones de puesto, el vocabulario cambia: de "workflow builder" a "automation engineer" o "automation system owner". Y ese cambio de vocabulario viene con un cambio de expectativa: se asume que puedes responder las tres preguntas de esta lección.

No lo digo para presionarte. Lo digo porque quiero que sepas qué estás construyendo cuando aprendes esto. No estás aprendiendo un truco más de n8n. Estás aprendiendo el conjunto de preguntas que define un rol distinto y mejor pagado. La sintaxis de una clave de idempotencia se aprende en una tarde; el criterio para saber dónde ponerla, cuándo hace falta y cómo defenderla en una entrevista es lo que se construye a lo largo de esta guía.

Podríamos considerar que la diferencia, en el fondo, es esta: el constructor entrega algo que funciona; el dueño entrega algo en lo que se puede confiar. Y la confianza, en sistemas por los que pasa dinero, es lo que se paga.

Dónde vive cada responsabilidad en el trabajo real

Un matiz importante para que esto no suene idealizado. En equipos grandes, a veces las dos responsabilidades se reparten entre personas: alguien arma los workflows y alguien más se ocupa de la confiabilidad, el monitoreo y la operación. Pero en la mayoría de los equipos donde vas a trabajar con n8n —empresas medianas, agencias de automatización, equipos chicos como el de Cumbre— las dos recaen sobre la misma persona. Sobre ti.

Eso tiene una consecuencia práctica: no puedes esperar a "terminar de construir" para empezar a pensar como dueño. Las dos responsabilidades se ejercen casi al mismo tiempo. Mientras armas el workflow, ya deberías estar haciéndote las tres preguntas, porque muchas de las protecciones que vas a aprender son más fáciles de poner mientras construyes que de agregar después. Un ejemplo que verás en el Módulo 2: es mucho más sencillo elegir bien la clave que identifica cada pedido cuando estás diseñando el flujo que cuando ya está en producción cobrando de más.

Por eso esta guía no separa "primero construyes, luego aseguras". Lo que hace es agregarle a tu forma de construir un segundo conjunto de preguntas, para que salgan juntas. La meta es que, dentro de unos módulos, las tres preguntas del dueño te salgan solas cada vez que arrastres un nodo que crea, cobra o envía algo.

Hay un beneficio secundario, y es de tranquilidad. Cuando construyes sin pensar como dueño, cada workflow que pones en producción es una fuente de ansiedad silenciosa: en el fondo sabes que algo puede salir mal y no sabes qué. Cuando construyes haciéndote las tres preguntas, pones en producción sabiendo exactamente qué probaste, qué protegiste y qué riesgos residuales quedan. No es que desaparezca el riesgo —nunca desaparece del todo— sino que pasa de ser un miedo difuso a ser una lista concreta que puedes revisar y defender. Esa diferencia, entre "espero que ande" y "sé qué le probé", es también parte de lo que significa ser dueño de un sistema.

Errores comunes

Creer que las tres preguntas son "para después" (conceptual). Qué pasa: alguien entiende que la confiabilidad importa, pero la trata como una segunda etapa —"primero lo hago funcionar, después lo aseguro"— y esa segunda etapa nunca llega, porque en cuanto funciona, se pasa al siguiente workflow. Por qué pasa: la presión de entregar algo que funcione es inmediata y visible; el riesgo de un duplicado es futuro e invisible hasta que ocurre. Cómo detectarlo: si ninguno de tus workflows en producción tiene protección contra disparos dobles, es que la segunda etapa nunca llegó para ninguno. Cómo corregirlo: mueve las tres preguntas al momento de construir, no al de terminar. Antes de conectar un nodo que cobra o envía, hazte la pregunta 1. Es la diferencia entre diseñar para la confiabilidad y parcharla después, y lo segundo siempre sale peor y más caro.

Confundir "el workflow funciona" con "el workflow está listo" (conceptual). Qué pasa: se prueba el camino feliz, sale bien, y se declara terminado. La demo funciona, el cliente aprueba, va a producción. Por qué pasa: el camino feliz es lo que se prueba naturalmente, y casi siempre funciona, lo que da una falsa sensación de completitud. Cómo detectarlo: pregúntate qué caminos infelices probaste. Si la respuesta es "ninguno, porque funcionó", probaste el 10% que siempre funciona y no probaste el 90% que decide si tu sistema es confiable. Cómo corregirlo: "funciona" es la respuesta del constructor; "está listo" requiere además responder las tres preguntas del dueño. La lección 8 te da un método para probar los caminos infelices de forma sistemática.

Tratar la mentalidad de dueño como pesimismo o exageración (conceptual). Qué pasa: alguien escucha "¿y si se dispara dos veces?, ¿y si el servicio cae?, ¿y si el esquema cambia?" y lo descarta como paranoia —"eso casi nunca pasa"—. Por qué pasa: cada uno de esos eventos es improbable en una ejecución cualquiera, así que en pequeño parecen exageraciones. Cómo detectarlo: multiplica la probabilidad por la cantidad de ejecuciones. Un evento que ocurre en 1 de cada 1000 ejecuciones, en un workflow que corre 500 veces al día, ocurre varias veces por semana. Cómo corregirlo: la mentalidad de dueño no es pesimismo, es aritmética. Lo raro en una ejecución es rutinario a escala. Diseñar para lo raro no es exagerar; es diseñar para el volumen real.

Pensar que ser dueño del sistema significa no confiar en nada (conceptual). Qué pasa: alguien lleva la mentalidad al extremo y quiere blindar cada nodo, validar cada campo, proteger cada operación, y termina con workflows imposibles de mantener. Por qué pasa: es el péndulo que se va al otro lado después de entender los riesgos. Cómo detectarlo: si estás poniendo protección contra duplicados en un nodo que solo lee datos, te pasaste. Cómo corregirlo: la mentalidad de dueño es selectiva, no total. Solo los efectos —crear, cobrar, enviar, borrar— necesitan protección; las lecturas no. Distinguir unos de otros es exactamente el tema de la lección 7, y es lo que evita que la confiabilidad se convierta en paranoia improductiva.

Ejercicios

Ejercicio 1 — Clasifica cinco preguntas. Para cada una de estas preguntas sobre order-triage, decide si es una pregunta de constructor o de dueño del sistema, y justifica en una frase.

(a) ¿El nodo Create charge está usando el campo amount correcto? (b) ¿Qué pasa si el pedido evt_8f2a91c4 llega dos veces? (c) ¿El agente de IA clasifica bien los pedidos urgentes? (d) ¿Qué pasa si la pasarela de pago no responde justo después de que el CRM ya registró el pedido? (e) ¿El correo de confirmación tiene el nombre correcto del cliente?

Ver solución

(a) Constructor. Es sobre si el workflow hace lo correcto en el caso normal: usar el campo correcto. Se verifica ejecutándolo una vez con datos correctos.

(b) Dueño del sistema. Es la pregunta 1: qué pasa al repetirse. Asume que el caso normal ya funciona y pregunta por la repetición.

(c) Constructor. Es sobre la correctitud de la lógica en el caso normal. Que el agente clasifique bien es parte de "hace lo que tiene que hacer".

(d) Dueño del sistema. Es la pregunta 2: fallo parcial. El CRM ya registró, la pasarela no responde; el sistema queda a medias.

(e) Constructor. Es sobre si el contenido del correo es correcto en el caso normal. Un dato bien mapeado.

Por qué funciona: fíjate en el patrón. Las preguntas del constructor se responden ejecutando una vez con datos buenos. Las del dueño se responden imaginando qué pasa cuando la ejecución se repite, un servicio falla o los datos cambian. Ninguna de las dos es más importante; son capas distintas, y un sistema confiable necesita las dos.

Ejercicio 2 — Aplica las tres preguntas a un workflow tuyo. Elige un workflow real que hayas construido —o uno de una guía anterior— que tenga al menos un efecto (que cree, envíe o modifique algo). Hazle las tres preguntas del dueño del sistema y escribe la respuesta honesta de cada una, aunque sea incómoda.

Ver solución

No hay una respuesta única porque depende de tu workflow, pero sí hay un patrón en lo que la gente encuentra. Lo más común es descubrir que:

Para la pregunta 1 (¿dos veces?): el workflow no tiene ninguna protección, y si se dispara dos veces, duplica su efecto. Casi nadie diseña contra esto la primera vez.

Para la pregunta 2 (¿fallo parcial?): si el workflow tiene varios efectos en secuencia, un fallo entre uno y otro deja el sistema a medias, y no hay un plan claro para eso.

Para la pregunta 3 (¿cambio de esquema?): el workflow confía en que los datos de entrada siempre vienen con el mismo formato, sin validar nada en la frontera.

Si tu workflow salió bien parado en las tres, hay dos posibilidades: o ya piensas como dueño (excelente), o el workflow no tiene efectos de verdad —solo lee y transforma— en cuyo caso las preguntas no aplican con la misma fuerza, y eso también es un aprendizaje: no todo necesita protección.

Por qué funciona: el valor de este ejercicio no está en las respuestas, está en la incomodidad. Sentir que un workflow que creías terminado tiene tres agujeros es el momento en que dejas de ser solo constructor. A partir de aquí, la guía te da las herramientas para tapar cada agujero.

Ejercicio 3 — Escribe tu defensa de entrevista. Imagina que en una entrevista técnica te muestran order-triage tal como está —sin ninguna protección— y te preguntan: "¿Ves algún problema con este workflow?". Escribe, en cuatro o cinco frases, la respuesta que darías, usando las tres preguntas del dueño del sistema y nombrando al menos un riesgo concreto con su consecuencia.

Ver solución

Un ejemplo de respuesta sólida:

"El workflow está bien construido para el caso normal, pero veo tres riesgos de confiabilidad. El primero y más grave: no está protegido contra disparos dobles. Si el proveedor del webhook reintenta —cosa que hacen cuando no reciben confirmación a tiempo— el workflow crea un segundo registro y, sobre todo, genera un segundo cobro al cliente. El segundo: hay un fallo parcial posible entre Create charge y Send Email; si el cobro funciona pero el correo falla, el cliente pagó sin confirmación, y cualquier reintento del workflow completo vuelve a cobrar. El tercero: no hay validación del formato de entrada, así que un cambio en cómo llega el campo amount podría producir un cobro incorrecto. Para el primer riesgo, que es el crítico, usaría una clave de idempotencia sobre el event_id para detectar y descartar el segundo disparo antes de que llegue al cobro."

No hay una única redacción correcta. Lo que hace fuerte a la respuesta es que nombra el mecanismo concreto (el reintento del proveedor, el fallo parcial entre dos nodos específicos) y la consecuencia concreta (segundo cobro), no que suene técnica en general.

Por qué funciona: en una entrevista, "creo que le falta manejo de errores" no dice nada. "Si el proveedor reintenta, cobra dos veces, y así lo evito" demuestra que piensas como dueño de un sistema. Esa es exactamente la diferencia que esta guía te enseña a articular, y la vas a poder defender de verdad cuando termines los seis módulos.

Resumen y siguiente paso

En esta lección separaste dos responsabilidades que viven en la misma persona pero son trabajos distintos. El constructor entrega un workflow que funciona, y sus preguntas asumen una ejecución, datos correctos y todos los servicios disponibles: el camino feliz, que casi siempre funciona. El dueño del sistema empieza donde el constructor termina y pregunta por lo que pasa cuando algo sale mal, con tres preguntas que son la columna vertebral de la guía: ¿qué pasa si se dispara dos veces?, ¿qué pasa si un servicio cae a la mitad (fallo parcial)?, ¿qué pasa si el esquema de entrada cambia? Las tres son variaciones de una sola preocupación: no basta con que el workflow funcione; tiene que no hacer daño cuando no funciona.

Viste las tres preguntas aplicadas a order-triage y descubriste que el mismo workflow que el constructor ve terminado, el dueño lo ve con tres agujeros —y que señalar esos agujeros no es criticar la construcción, es agregarle la capa que falta—. Y viste por qué esto es también una conversación de carrera: el vocabulario de las descripciones de puesto cambia de "workflow builder" a "automation system owner" justo cuando se asume que puedes responder estas tres preguntas.

Antes de avanzar deberías poder: nombrar de memoria las tres preguntas del dueño del sistema; explicar por qué el camino feliz da una falsa sensación de completitud; y aplicar al menos dos de las tres preguntas a un workflow con la respuesta concreta de qué saldría mal.

Ya tienes la mentalidad y las tres preguntas. Lo que falta es volver preciso el término que usamos todo el tiempo sin definirlo: "confiable". La lección 3 lo convierte en un criterio técnico exacto —correcto vs disponible, y la diferencia entre "no falla" y "no hace daño al fallar"— que va a ser la vara con la que juzgues cada workflow del resto de la guía.

Recursos

• Error handling — n8n Docs — la sección oficial sobre manejo de errores en n8n; el arsenal técnico que el dueño del sistema usa para responder la pregunta 2 (fallo parcial), y que esta guía desarrolla en el Módulo 6.
• Webhook node — n8n Docs — el nodo que dispara order-triage; su comportamiento ante reintentos del proveedor es el origen de la pregunta 1.
• Data structure — n8n Docs — la estructura de datos que viaja entre nodos; entenderla bien es parte del trabajo del constructor sobre el que se apoya el dueño.
• Execution data — n8n Docs — dónde ver qué pasó en cada ejecución; la herramienta con la que el dueño del sistema investiga un fallo parcial o un duplicado, que estudiamos a fondo en la lección 4.