3. Clasificar workflows por criticidad

Descripción

Al terminar esta lección vas a tener la herramienta más importante de toda la guía: una matriz de dos ejes que ordena un catálogo entero de workflows y te dice, para cada uno, cuánto cuidado merece y de qué tipo. Vas a aprender a distinguir criticidad —qué tan grave es que un workflow falle— de reversibilidad del efecto —qué tan fácil es deshacer lo que ya pasó—, que son dos preguntas distintas que casi todo el mundo mezcla en una sola llamada "importancia". Y vas a ver, con los tres protagonistas de Terra Market cayendo en casillas distintas, por qué dos workflows igual de importantes pueden merecer cuidados opuestos.

Esto importa porque es lo que convierte el trabajo de operar de un arte de intuición en un oficio con método. Sin esta matriz, el esfuerzo de los siete módulos que siguen se reparte al azar: acabas poniéndole cinco capas de protección al que hace el reporte semanal y ninguna al que crea los pedidos, no por mala decisión sino por falta de decisión. Con la matriz, cada workflow tiene una casilla, cada casilla tiene un nivel de cuidado, y puedes justificar en una frase por qué cada uno tiene lo que tiene. Esa capacidad —justificar el reparto del esfuerzo— es exactamente lo que separa a alguien que configura workflows de alguien a quien una empresa le confía un sistema.

Conexión con el módulo: en la lección 2 aprendiste a reconocer que un workflow está en producción y a describirlo con tres piezas —dueño, promesa medible, radio de impacto—. Esta lección toma dos de esas ideas (el radio de impacto y la reversibilidad que asomó en la señal 4) y las convierte en los dos ejes de una matriz. El resultado ordena todo lo que viene: la lista de verificación de la lección 4 se calibra según la casilla, el cuidado al cambiar en vivo de la lección 5 depende de la casilla, y el proyecto de la lección 8 es, en su primer paso, aplicar esta matriz a los dieciocho workflows. Es la lección que más vas a citar hacia adelante.

Dos preguntas que no son la misma

Vamos a empezar por el error que esta lección corrige, porque nombrarlo hace que todo lo demás encaje.

Cuando alguien mira un catálogo de workflows y trata de ordenarlos, casi siempre usa una sola palabra: importancia. "Este es más importante que aquel". Y con esa única regla ordena todo de más a menos importante, como una fila. El problema es que "importancia" está escondiendo dos preguntas completamente distintas, y cuando las juntas en una sola pierdes la información que más necesitas.

Las dos preguntas son:

1. ¿Qué tan grave es que falle? — Si este workflow falla y nadie lo recupera, ¿qué se pierde y cuánto duele? A esto lo vamos a llamar criticidad.

2. ¿Qué tan fácil es deshacer lo que pasó? — Cuando el efecto de este workflow sale al mundo y algo sale mal, ¿se puede arreglar? ¿Solo? ¿A mano? ¿No se puede? A esto lo vamos a llamar reversibilidad del efecto.

Fíjate en que son independientes. Un workflow puede ser gravísimo si falla y a la vez trivial de arreglar. Otro puede ser poco grave y a la vez imposible de deshacer. Meterlos en una sola palabra —"importancia"— te obliga a promediarlos, y el promedio borra justo el matiz que decide qué cuidado necesita cada uno.

La analogía. Piensa en dos cosas que pueden salir mal en tu casa. La primera: se rompe un vaso. La segunda: se te olvida pagar la luz y te la cortan. ¿Cuál es "más importante"? La pregunta no tiene respuesta, porque son graves de formas distintas y se arreglan de formas distintas. El vaso roto es un incidente menor pero irreversible —ese vaso no vuelve—; barres los vidrios y compras otro. La luz cortada es más grave pero reversible —pagas y vuelve—; el problema es serio pero se deshace con una acción. Si tuvieras que ordenar "vaso roto" y "luz cortada" en una sola fila de importancia, perderías lo único que de verdad te dice qué hacer con cada uno: uno no se puede deshacer pero no importa mucho, el otro importa más pero se deshace.

Los workflows son igual. Por eso no los ordenamos en una fila: los ubicamos en una cuadrícula de dos ejes. Y esa cuadrícula es la matriz de criticidad.

El primer eje: criticidad

Qué es. La criticidad responde una sola pregunta, la misma que ya sabes hacer desde la lección 2: si este workflow falla y nadie lo recupera, ¿qué se pierde? La respuesta la clasificamos en tres niveles.

Crítico. Si falla y no se recupera, se pierde algo que el negocio no puede permitirse perder: un pedido pagado, un pago a un vendedor, una factura, un reembolso. Un solo fallo no recuperado es, por sí mismo, un incidente. No hace falta que se repita para que duela; con una vez basta.

Importante. Su fallo tiene un costo real pero acotado y recuperable. El negocio sigue funcionando, con fricción. Merece atención pronta —hoy, no dentro de una semana— pero no inmediata, y un solo fallo aislado rara vez es un incidente en sí mismo.

Conveniente. Su fallo es una molestia o una oportunidad perdida. El negocio ni se entera a corto plazo. No es que no valga nada —si no valiera, no existiría—, es que su ausencia temporal no rompe nada. En inglés se le dice nice to have: está bien tenerlo, se sobrevive sin él.

La anatomía de una trampa. Hay un matiz en la criticidad que casi nadie ve la primera vez, y es importante: la criticidad de algunos workflows no es un punto fijo, es una función del tiempo. inventory-update es el ejemplo perfecto. Que falle una vez es conveniente —no pasa nada, la siguiente corrida arregla todo—. Que falle ocho veces seguidas es crítico —la tienda lleva dos horas vendiendo lo que no hay—. El mismo workflow cambia de nivel según cuánto dure el fallo. Cuando clasifiques, no busques solo "qué tan grave es un fallo": pregúntate también "¿un fallo sostenido cambia el nivel?". Para muchos workflows la respuesta será no. Para algunos, como inventory-update, la respuesta es el corazón de cómo hay que cuidarlos.

Qué esperar. Al clasificar tu catálogo por criticidad, lo normal es que la mayoría caiga en "importante" —es la categoría media y la más poblada— y que "crítico" y "conveniente" tengan pocos cada uno. Si te sale que casi todo es crítico, probablemente estás confundiendo "me daría vergüenza que fallara" con "el negocio no puede permitírselo". Muy pocas cosas son de verdad críticas, y llamar crítico a todo tiene el mismo efecto que no llamar crítico a nada: el nivel deja de significar algo.

El segundo eje: reversibilidad del efecto

Qué es. La reversibilidad responde una pregunta distinta: cuando el efecto de este workflow ya ocurrió en el mundo y algo salió mal, ¿se puede volver a un estado correcto, y con cuánto trabajo? También en tres niveles, pero ojo, porque el orden de "mejor a peor" es el inverso del que uno esperaría.

Autocorrectivo (el más benigno). Si el efecto sale mal, la siguiente ejecución lo arregla sola, sin que nadie mueva un dedo. Son workflows que corren en ciclo y cada corrida pisa a la anterior. inventory-update es el caso puro: si la corrida de las 14:15 escribe un stock equivocado o no escribe nada, la de las 14:30 trae el stock correcto y lo sobreescribe. El error se cura solo por diseño.

Corregible. Si el efecto sale mal, se puede arreglar, pero hace falta una acción humana o una compensación: reenviar un correo de corrección, reprocesar desde dead_letter, recalcular y reescribir un dato interno. Nada se destruyó de forma permanente; hay trabajo por hacer, pero hay camino de vuelta. La mayoría de los workflows caen aquí.

Irreversible (el más delicado). Si el efecto sale mal, no hay vuelta atrás limpia. El efecto fue un evento único sobre el mundo que, una vez perdido o duplicado, no se puede tomar de vuelta ni reproducir. Un pedido pagado que se perdió no se recupera si nadie guardó el evento —storefront no lo reenvía—. Un pago a un vendedor ya transferido no se deshace con un clic. Una factura fiscal, una vez emitida, es un documento legal. Este nivel es donde vive el cuidado de verdad.

Por qué "autocorrectivo" es mejor que "corregible". Puede sonar raro que lo autocorrectivo sea mejor que lo corregible —ambos se arreglan—, pero la diferencia es enorme en la práctica y se mide en trabajo humano. Lo autocorrectivo se arregla sin ti: el sistema absorbe el fallo. Lo corregible se arregla contigo: alguien tiene que enterarse, entender y actuar. Y ese "alguien tiene que" es exactamente el costo operativo que estás aquí para minimizar. Un workflow autocorrectivo te regala tolerancia gratis; uno irreversible te la cobra en vigilancia.

La analogía. Piensa en tres formas de escribir. Escribir con lápiz es corregible: te equivocas, borras, reescribes; queda un rastro y cuesta un poco, pero se arregla. Escribir en la arena de la playa es autocorrectivo: te equivocas y no importa, la próxima ola borra todo y empiezas limpio sin hacer nada. Escribir con cincel en piedra es irreversible: cada golpe es para siempre, y por eso —fíjate en esto— antes de dar el primer golpe mides diez veces. El nivel de reversibilidad no cambia lo que escribes; cambia cuánto cuidado pones antes de escribirlo. Con lápiz escribes rápido. Con cincel, despacio y verificando. Esa es exactamente la relación entre reversibilidad y cuidado operativo.

Qué esperar. Para clasificar por reversibilidad, la pregunta más útil es: "si esto sale mal, ¿quién lo arregla y cómo?". Si la respuesta es "nadie, la próxima corrida" → autocorrectivo. Si es "yo o alguien, con una acción" → corregible. Si es "no se puede, hay que vivir con las consecuencias o hacer una compensación cara" → irreversible. Y recuerda la conexión con la señal 4 de la lección 2: solo los workflows cuyo efecto sale de tu máquina tienen reversibilidad interesante. Uno que solo lee y calcula para ti es trivialmente reversible —lo vuelves a correr y ya— y no compite por tu atención.

La matriz: cruzar los dos ejes

Ahora juntamos los dos ejes en una cuadrícula de 3 × 3. Las columnas son la reversibilidad (de la más benigna a la más delicada); las filas, la criticidad (de la más grave a la más leve). Cada workflow cae en una casilla, y cada casilla tiene un carácter propio.

                        REVERSIBILIDAD DEL EFECTO
                Autocorrectivo   Corregible      Irreversible
              ┌────────────────┬───────────────┬────────────────┐
   Crítico    │   raro pero     │  vigilar y     │  🔴 MÁXIMO      │
              │   posible       │  recuperar     │  CUIDADO        │
C             │                 │                │  order-sync     │
R             ├────────────────┼───────────────┼────────────────┤
I  Importante │  inventory-     │  shipment-     │  cuidado alto,  │
T             │  update         │  notify        │  poco volumen   │
I             │  (patrón, no    │  (evitar       │                 │
C             │   ejecución)    │   duplicados)  │                 │
I             ├────────────────┼───────────────┼────────────────┤
D  Conveniente│  dejar correr,  │  arreglar      │  raro: efecto   │
A             │  revisar de vez │  cuando se     │  fuerte, poca   │
D             │  en cuando      │  pueda         │  importancia    │
              └────────────────┴───────────────┴────────────────┘

Fíjate en la diagonal. La esquina de arriba a la derecha —crítico e irreversible— es la más peligrosa del catálogo: si falla duele mucho y no se puede deshacer. Es la casilla del cincel en piedra sobre algo que no puedes permitirte perder. La esquina de abajo a la izquierda —conveniente y autocorrectivo— es la más tranquila: si falla no importa mucho y se arregla solo. Es la escritura en la arena de algo que da igual.

El cuidado operativo que merece cada workflow crece conforme te mueves hacia la esquina superior derecha. Esa dirección —hacia arriba y hacia la derecha— es, literalmente, el orden en que vas a invertir tu tiempo en los siete módulos siguientes.

Ejemplo trabajado: los tres protagonistas en tres casillas

Aquí está el corazón de la lección. Vamos a ubicar a order-sync, inventory-update y shipment-notify en la matriz, y vas a ver que caen en tres casillas distintas y que por eso mismo merecen cuidados opuestos, aunque los tres "sean de producción".

order-sync → crítico × irreversible.

Criticidad: si un pedido pagado se pierde y nadie lo recupera, el cliente pagó y no recibe nada; el almacén nunca supo que existió. El negocio no puede permitírselo. Es crítico, y un solo fallo no recuperado ya es un incidente.

Reversibilidad: el efecto —crear el pedido en el erp— es un evento único. Si se pierde, storefront no reenvía el webhook; el pedido, para el sistema, dejó de existir. No hay siguiente corrida que lo arregle ni forma de reconstruirlo si nadie lo guardó. Es irreversible.

Casilla: la esquina roja. Cincel en piedra sobre lo que más importa.

Qué cuidado implica: no se puede perder ni una ejecución. Cada fallo tiene que quedar guardado en algún lado —dead_letter— para poder reprocesarlo, y alguien tiene que enterarse de que hay pedidos esperando. Es el workflow que justifica las cinco capas de manejo de errores del módulo 2 completo, la observabilidad más fina del módulo 4, y la guardia más atenta del módulo 8.

inventory-update → importante × autocorrectivo.

Criticidad: aquí aparece la trampa del tiempo. Un fallo aislado es conveniente —no pasa nada—. Un fallo sostenido es crítico —la tienda vende lo que no hay—. Su criticidad de base la ponemos en importante, con la nota de que un fallo prolongado la escala. Esa nota no es un detalle: es cómo se cuida este workflow.

Reversibilidad: cada corrida pisa a la anterior. La de las 14:30 corrige lo que la de las 14:15 hizo mal. Es autocorrectivo puro.

Casilla: importante × autocorrectivo, en la columna izquierda.

Qué cuidado implica —y aquí está el contraste con order-sync—: lo opuesto. En order-sync te importa cada ejecución; en inventory-update no te importa casi ninguna ejecución, te importa el patrón. Reintentar con fuerza un fallo de inventory-update es casi inútil: si la corrida falló porque el erp está lento, la de dentro de quince minutos probablemente funcione igual de bien. Lo que necesitas no es proteger la corrida, es detectar la racha: "llevas ocho corridas seguidas fallando" es la única alerta que importa aquí. Guardar cada sku fallido en dead_letter, como harías con order-sync, sería llenar una tabla de basura que la siguiente corrida vuelve irrelevante.

shipment-notify → importante × corregible.

Criticidad: si un aviso no sale, un cliente no se entera de que su paquete se movió. Molesto, no grave; recuperable —el cliente puede consultar el estado de otra forma—. Importante, no crítico.

Reversibilidad: el efecto es mandar un correo. Un correo no se puede "des-enviar", pero el daño de uno equivocado o duplicado se corrige: mandas una aclaración, te disculpas, y la molestia pasa. No se destruyó dinero ni un registro único. Es corregible.

Casilla: importante × corregible, en la columna del medio.

Qué cuidado implica: aquí el enemigo no es perder, es duplicar. Como carrier a veces reporta el mismo evento dos veces y storefront duplica webhooks, el riesgo real de shipment-notify es mandarle tres correos idénticos al mismo cliente, que se queja. Su cuidado principal no es un reintento agresivo ni una tabla de fallos: es una comprobación de "¿ya avisé de esto?" antes de enviar. Ese es un problema de idempotencia —guía de contratos— más que de recuperación. Fíjate cómo la casilla ya te está diciendo dónde buscar la solución.

Qué esperar. Pon las tres conclusiones lado a lado y mira lo que pasó:

Workflow	Casilla	El cuidado principal es…	Lo que NO ayuda
order-sync	crítico × irreversible	no perder ninguna ejecución; guardar y reprocesar	—
inventory-update	importante × autocorrectivo	detectar la racha de fallos; el patrón, no la corrida	reintentar fuerte, guardar cada sku fallido
shipment-notify	importante × corregible	evitar duplicados antes de enviar	reintentar agresivo (empeora la duplicación)

Los tres son de producción. Los tres, si les aplicaras la misma receta —"pongámosle reintentos agresivos y guardemos todos los fallos"—, quedarían mal cuidados: order-sync bien, inventory-update con una tabla llena de basura y sin la alerta que importa, y shipment-notify peor que antes, porque reintentar agresivo un correo aumenta la duplicación que es justo su problema. La receta única es el enemigo. La matriz es lo que te salva de aplicarla.

Esa es la lección, y por eso es la más importante del módulo: el cuidado correcto no se deduce de "qué tan importante es", se deduce de la casilla. Y la casilla necesita los dos ejes, porque un solo eje —importancia— habría puesto a los tres casi juntos y habría escondido que necesitan cosas opuestas.

Clasificar los dieciocho en una tarde

La matriz no sirve de nada como teoría; sirve como procedimiento aplicado a tu catálogo real. Aquí está cómo se hace en una tarde, sin sobrepensarlo.

Paso 1 — Lista los workflows. Ya la tienes del ejercicio 3 de la lección 1: el catálogo con una línea por workflow.

Paso 2 — A cada uno, dos preguntas y nada más. No abras el workflow, no leas su lógica. Solo dos preguntas de negocio:

• Si falla y nadie lo recupera, ¿qué se pierde? → criticidad (crítico / importante / conveniente).
• Si sale mal, ¿quién lo arregla y cómo? → reversibilidad (autocorrectivo / corregible / irreversible).

Paso 3 — Escribe la casilla. Una tabla con tres columnas: nombre, criticidad, reversibilidad. Sin matices todavía; el matiz viene después.

Paso 4 — Ordena por cercanía a la esquina roja. Los crítico×irreversible primero, los conveniente×autocorrectivo al final. Ese orden es tu lista de prioridades para el resto de la guía.

Así queda el catálogo completo de Terra Market después de la primera pasada. Esta tabla es material que vas a reutilizar tal cual en el proyecto de la lección 8:

MATRIZ DE CRITICIDAD — Terra Market — 18 workflows

  Workflow                 Criticidad    Reversibilidad   Casilla
  ─────────────────────────────────────────────────────────────────
  order-sync               Crítico       Irreversible     🔴 esquina roja
  invoice-issue            Crítico       Irreversible     🔴 esquina roja
  refund-process           Crítico       Irreversible     🔴 esquina roja
  seller-payout            Crítico       Irreversible     🔴 esquina roja
  error-handler            Crítico       Corregible       crítico infra
  dead-letter-watch        Crítico       Corregible       crítico infra
  shipment-notify          Importante    Corregible       vigilar duplicados
  seller-commission-calc   Importante    Corregible       recalcular si falla
  support-ticket-triage    Importante    Corregible       reprocesar (usa IA)
  seller-onboarding        Importante    Corregible       reintentar + manual
  daily-ops-report         Importante    Corregible       recuperable, benigno
  inventory-update         Importante    Autocorrectivo   patrón, no ejecución
  catalog-sync             Importante    Autocorrectivo   patrón, no ejecución
  price-sync               Importante    Autocorrectivo   patrón, no ejecución
  review-sentiment-tag     Conveniente   Corregible       dejar correr (IA)
  abandoned-cart-reminder  Conveniente   Corregible       evitar duplicados
  review-request           Conveniente   Corregible       nice to have
  weekly-sales-digest      Conveniente   Corregible       nice to have

Tres cosas que conviene señalar de esta tabla, porque son hallazgos, no adornos:

Los seis críticos son la mitad de arriba, y no todos son irreversibles. Cuatro caen en la esquina roja —order-sync, invoice-issue, refund-process, seller-payout—: los que mueven dinero o registros únicos. Los otros dos —error-handler y dead-letter-watch— son críticos por otra razón: son la infraestructura de observación del resto. Si error-handler falla, no pierdes un pedido, pierdes la capacidad de enterarte de que perdiste pedidos. Es crítico de segundo orden, y merece su propia mención porque es fácil olvidarlo: cuidas los workflows de negocio y dejas sin cuidado al que te avisa cuando fallan.

"Importante" es la categoría más poblada, con ocho workflows, y dentro de ella la reversibilidad los separa en dos grupos con cuidados distintos: los corregibles (que se recuperan con acción) y los autocorrectivos (que se cuidan por patrón). Ese es el segundo eje ganándose su lugar.

Los cuatro convenientes son casi todos correo o etiquetado, y comparten un patrón: su fallo es una oportunidad perdida, no un daño. Merecen lo mínimo —que no se rompan en silencio para siempre— y nada más. Gastar en ellos la energía de la esquina roja es un error de reparto tan grave como no gastarla donde toca.

Qué se hace con el resultado

Clasificar sin actuar es un ejercicio bonito y estéril. El resultado de la matriz se usa de tres formas concretas, y las tres estructuran el resto de la guía.

Primero, define el orden de trabajo. Empiezas por la esquina roja y bajas. En Terra Market, los primeros en recibir manejo de errores del módulo 2 son order-sync y compañía, no weekly-sales-digest. El proyecto de la lección 8 termina justo con esta priorización: los tres que hay que arreglar primero.

Segundo, define el nivel de cada cuidado. No es que los convenientes no lleven nada; es que llevan menos. Un workflow crítico×irreversible lleva reintento seguro, rama de error, tabla de reproceso, alerta con urgencia y un runbook. Uno conveniente×corregible lleva, quizá, solo una alerta suave si lleva días caído. La lección 4 convierte esto en una lista de verificación calibrada por casilla, y es donde vas a ver el reparto en detalle.

Tercero, define el tipo de cuidado, no solo la cantidad. Esta es la parte que la matriz hace y una fila de importancia no podría: te dice qué clase de protección. Autocorrectivo → vigila el patrón. Corregible → guarda para reprocesar y evita duplicados. Irreversible → no pierdas nada y verifica antes de escribir. La casilla no solo dice "cuánto", dice "de qué".

Un cierre honesto sobre la clasificación: no es para siempre y no es exacta. Un workflow puede cambiar de casilla cuando cambia el negocio —si Terra Market empieza a facturar en tiempo real, un workflow que era conveniente puede volverse crítico—. Y los bordes entre casillas son borrosos: habrá workflows de los que dudes entre importante y crítico, y está bien. La matriz no busca la verdad absoluta de cada workflow; busca que el catálogo quede ordenado lo suficiente como para repartir el esfuerzo con criterio en vez de al azar. Un ordenamiento imperfecto pero explícito vence a una intuición perfecta pero privada, porque el explícito se puede discutir, heredar y corregir.

Errores comunes

Llamar crítico a todo (conceptual, el más frecuente). Qué pasa: al clasificar, cada workflow parece importante desde su propio ángulo, y la fila "crítico" se llena. Cuando todo es crítico, nada lo es: la etiqueta deja de guiar el esfuerzo, porque no puedes empezar por "los críticos" si son quince de dieciocho. Por qué pasa: se confunde "me daría vergüenza que fallara" o "me costó trabajo hacerlo" con "el negocio no puede permitírselo". El orgullo del constructor infla la criticidad. Cómo detectarlo: cuenta tus críticos. Si son más de un tercio del catálogo, revisa: casi seguro colaste como críticos varios que son importantes. Cómo corregirlo: para cada candidato a crítico, exige la prueba dura: "¿qué se pierde, en términos que el negocio reconozca, si esto falla una vez y nadie lo recupera?". Si la respuesta es "nada permanente" o "una molestia", no es crítico. Reserva "crítico" para lo que de verdad no admite pérdida.

Colapsar los dos ejes en uno (conceptual, el que esta lección combate). Qué pasa: se clasifica solo por "importancia" y se ignora la reversibilidad, o al revés. El síntoma es aplicar la misma receta de cuidado a workflows que parecen igual de importantes pero que necesitan cosas opuestas —como les pasaría a los tres protagonistas—. Por qué pasa: dos ejes son más trabajo mental que uno, y la tentación de simplificar a una sola fila es fuerte. Cómo detectarlo: si tu clasificación es una lista ordenada de más a menos importante, sin una segunda dimensión, colapsaste los ejes. Cómo corregirlo: obliga a las dos preguntas separadas —"¿qué tan grave?" y "¿se puede deshacer?"— y no dejes que la respuesta a una contamine la otra. El caso que lo hace evidente es shipment-notify frente a order-sync: ignora la reversibilidad y les pondrás el mismo reintento agresivo, que a uno lo salva y al otro lo empeora.

Olvidar la infraestructura de observación (práctico, y silencioso). Qué pasa: se clasifican con cuidado los workflows de negocio y se dejan fuera —o en una casilla baja— los que vigilan a los demás, como error-handler y dead-letter-watch. Meses después, un workflow crítico falla, pero como el que debía avisar también estaba caído, nadie se entera, y el fallo del crítico se descubre tarde y por un cliente. Por qué pasa: estos workflows no producen nada visible para el negocio, así que no "se sienten" críticos. Cómo detectarlo: en tu matriz, busca los workflows cuyo trabajo es enterarte de fallos. Si no están en criticidad alta, es esto. Cómo corregirlo: el que te avisa de los incendios es tan crítico como los que se pueden incendiar. error-handler es crítico porque de él depende que te enteres de todo lo demás; su reversibilidad es corregible, pero su criticidad no admite descuento.

Ejercicios

Ejercicio 1 — Ubica cinco en la matriz. Toma estos cinco workflows de Terra Market y ubica cada uno en su casilla (criticidad × reversibilidad), con una frase de justificación por eje: invoice-issue, abandoned-cart-reminder, catalog-sync, refund-process, support-ticket-triage. No mires la tabla de la lección hasta terminar; luego compara.

Ver solución

• invoice-issue → crítico × irreversible. Criticidad: si no se emite una factura de un pedido confirmado, hay un problema de ingresos y de cumplimiento fiscal; el negocio no puede permitírselo. Reversibilidad: una factura fiscal, una vez emitida, es un documento legal que no se "des-emite" con un clic —corregirla implica notas de crédito y trámites—. Esquina roja.

• abandoned-cart-reminder → conveniente × corregible. Criticidad: si no se manda el recordatorio, se pierde un carrito que quizá se habría recuperado; oportunidad perdida, no daño. Reversibilidad: si se manda mal o duplicado, molesta un poco y se corrige con una disculpa; nada permanente. Esquina tranquila, con la nota de que la duplicación molesta, como en todos los que escriben al cliente.

• catalog-sync → importante × autocorrectivo. Criticidad: si un producto tarda una hora en aparecer o desaparecer de la tienda, se pierden ventas o se vende algo dado de baja; real pero acotado, y escala si es sostenido. Reversibilidad: corre cada hora y cada corrida pisa a la anterior; el error se cura solo. Misma columna que inventory-update.

• refund-process → crítico × irreversible. Criticidad: un reembolso que no se procesa deja a un cliente sin su dinero de vuelta; grave. Reversibilidad: un reembolso ya enviado no se recupera —el dinero salió—. Esquina roja, y con doble filo: tanto no hacerlo (cliente sin reembolso) como hacerlo dos veces (dinero de más que salió) son irreversibles.

• support-ticket-triage → importante × corregible. Criticidad: si clasifica mal un ticket, un cliente espera más de lo debido; molesto, no grave, recuperable. Reversibilidad: un ticket mal clasificado se re-clasifica a mano; hay trabajo pero hay vuelta. Columna del medio. (Nota: usa IA, así que hereda del módulo 7 el cuidado de costo, pero eso es otra dimensión.)

Por qué funciona: fíjate en que refund-process te obligó a pensar la irreversibilidad en las dos direcciones —no hacerlo y hacerlo de más—. Los workflows que mueven dinero suelen tener ese doble filo, y reconocerlo es exactamente el tipo de cuidado que la esquina roja exige.

Ejercicio 2 — El contraste que define la lección. Explícale a un compañero, en un párrafo, por qué order-sync e inventory-update merecen cuidados opuestos pese a que los dos son de producción y los dos son importantes para el negocio. Usa las palabras "casilla", "patrón" y "cada ejecución".

Ver solución

Una respuesta posible:

"Los dos son de producción, sí, pero caen en casillas distintas de la matriz y eso lo cambia todo. order-sync es crítico e irreversible: cada ejecución es un pedido único que, si se pierde, no vuelve, porque storefront no reenvía el webhook. Por eso en order-sync me importa cada ejecución: ninguna se puede perder, cada fallo tiene que quedar guardado para reprocesarlo, y alguien tiene que enterarse. inventory-update, en cambio, es autocorrectivo: cada quince minutos una corrida nueva pisa a la anterior, así que un fallo aislado se cura solo sin que yo haga nada. Ahí no me importa casi ninguna ejecución individual; me importa el patrón. Un fallo no es incidente; ocho fallos seguidos sí, porque significan que la tienda lleva dos horas con stock viejo. Si les pusiera a los dos la misma receta —reintentos agresivos y guardar cada fallo—, a order-sync lo protejo bien, pero a inventory-update le lleno una tabla de basura que la siguiente corrida vuelve irrelevante y me pierdo la única alerta que importa, que es la de la racha. Cuidados opuestos, y la matriz es lo que me lo dice."

Por qué funciona: el párrafo no dice "uno es más importante que otro" —que sería colapsar los ejes—, dice "caen en casillas distintas y por eso el tipo de cuidado es distinto". Esa es la idea que la lección existe para instalar.

Ejercicio 3 — Clasifica tu propio catálogo. Toma tu catálogo real (o el de Terra Market si aún no tienes propio) y llena la tabla de tres columnas —nombre, criticidad, reversibilidad— para todos tus workflows. Luego responde dos preguntas: ¿cuántos te quedaron en la esquina roja (crítico × irreversible)?, y ¿hay algún workflow de "infraestructura de observación" (uno que avise de fallos) y en qué casilla quedó?

Ver solución

No hay una tabla correcta, pero hay señales de que la hiciste bien.

Sobre la esquina roja. En un catálogo mediano y sano, la esquina roja tiene pocos: los que mueven dinero o registros únicos irreproducibles. Si te quedaron muchos —digamos la mitad—, casi seguro inflaste la criticidad o la irreversibilidad. Vuelve a cada uno y pregúntate la prueba dura: ¿de verdad se pierde algo permanente e irreparable si falla una vez? En Terra Market fueron cuatro de dieciocho, y es una proporción razonable de referencia.

Sobre la infraestructura de observación. Aquí está el hallazgo que casi todos pasan por alto en la primera pasada: el workflow que te avisa de los fallos suele quedar sin clasificar o en una casilla baja, porque "no hace nada para el negocio". Si el tuyo quedó ahí, súbelo. Es crítico, porque de él depende que te enteres de todo lo demás; su reversibilidad probablemente sea corregible, pero su criticidad no admite descuento. Si no tienes ningún workflow de este tipo, ese vacío es en sí mismo un hallazgo: significa que hoy los fallos de tus críticos se descubren por casualidad, y eso es justo lo que el módulo 2 (con el error-handler global) y el módulo 4 (con las alertas) vienen a resolver.

Un resultado típico de una primera pasada honesta: la mayoría de los workflows en "importante", tres o cuatro en la esquina roja, un puñado de convenientes, y —si tienes suerte y quien te precedió pensó en ello— uno o dos de observación que hay que recordar clasificar arriba.

Por qué funciona: esta tabla es, literalmente, el primer entregable del proyecto de la lección 8. Hacerla ahora no es práctica desechable: es trabajo que se queda. Y las dos preguntas del final entrenan los dos errores más comunes —inflar la esquina roja y olvidar la observación—, que son justo los que separan una clasificación útil de una decorativa.

Resumen y siguiente paso

En esta lección construiste la herramienta central de la guía. Con la imagen del vaso roto y la luz cortada viste que "importancia" esconde dos preguntas distintas, y las separaste en dos ejes: la criticidad —qué tan grave es que falle, en tres niveles: crítico, importante, conveniente— y la reversibilidad del efecto —qué tan fácil es deshacer lo que pasó, de la más benigna a la más delicada: autocorrectivo, corregible, irreversible—. Con la imagen del lápiz, la arena y el cincel entendiste que la reversibilidad no cambia lo que haces, cambia cuánto cuidado pones antes de hacerlo. Cruzaste los ejes en la matriz 3 × 3 y ubicaste a los tres protagonistas en tres casillas distintas: order-sync en la esquina roja (crítico × irreversible, importa cada ejecución), inventory-update en importante × autocorrectivo (importa el patrón, no la ejecución), y shipment-notify en importante × corregible (importa evitar duplicados). Y viste la lección que lo justifica todo: el cuidado correcto no se deduce de la importancia, se deduce de la casilla, hasta el punto de que una misma receta salva a uno y empeora a otro. Clasificaste los dieciocho de Terra Market y descubriste tres cosas: la esquina roja tiene cuatro (los que mueven dinero), hay dos críticos de infraestructura fáciles de olvidar (error-handler, dead-letter-watch), y "importante" es la categoría más poblada.

Antes de avanzar deberías poder: definir los dos ejes y sus tres niveles cada uno; explicar por qué autocorrectivo es mejor que corregible; ubicar cualquier workflow en su casilla con una justificación por eje; y decir de memoria en qué casilla cae cada protagonista y qué cuidado opuesto implica.

La lección 4 toma esta matriz y la convierte en acción. Vas a construir la lista de verificación antes de encender: qué debe tener un workflow antes de que alguien dependa de él —dueño, comportamiento ante fallo, rastro para depurar, credencial con mínimo privilegio, límite de gasto si usa IA, y quién se entera si se cae—. Y la clave, que enlaza directo con lo que acabas de aprender: la lista no es única, está calibrada por casilla. Un conveniente×autocorrectivo no necesita lo mismo que un crítico×irreversible, y una lista única que se aplica a todo se ignora entera. Cada casilla de la lista va a remitir, además, al módulo que la resuelve, así que la lección 4 es también el mapa de por qué existen los módulos 2 al 7.

Recursos

• Understand executions — n8n Docs — la base para razonar la reversibilidad: qué hace una ejecución de producción sobre los sistemas reales, y por qué el efecto que "sale" es el que hay que clasificar.
• Handle errors gracefully — n8n Docs — el manejo de errores que cada casilla va a necesitar en distinta medida; la esquina roja lo usa entero, la esquina tranquila casi nada. Es la referencia base del módulo 2.
• Workflow settings — n8n Docs — donde vive el campo Error Workflow que conecta cada workflow con error-handler, el crítico de infraestructura de esta lección.
• n8n Docs — la referencia general. Los umbrales concretos de cada cuidado (cuántos reintentos, cada cuánto alertar) se afinan en los módulos 2 y 4; aquí solo decidiste qué casilla merece cuánto.