Una entrada reciente del blog de Andrey Karpenko (Charap.co), titulada “Metastability in Recovery: Cascading Recovery with a Loop”, profundiza en un fenómeno poco tratado en ingeniería de sistemas: las cascadas de recuperación y los bucles de retroalimentación que pueden hacer inviable la recuperación de un sistema aun cuando los fallos originales sí se aislaron. El texto parte de su anterior post sobre fallos metastables, donde un mismo comportamiento (por ejemplo, reintentar) puede ser correcto bajo una asunción y contraproducente bajo otra, y resume la charla que el propio Karpenko ofreció en SREcon Americas junto a Todd Porter (Meta) y Dave Maier (Portland State).
El núcleo del artículo describe cómo la recuperación de un sistema “dependee” (proveedor) puede desbordar a su dependiente (consumidor): cuando el proveedor vuelve a funcionar, envía de golpe todo el trabajo acumulado, incluida una posible sobrecarga extra del propio proceso de recuperación. Ese aluvión provoca en el dependiente un trabajo adicional que, en muchos casos, es más costoso que el que habría requerido procesar los datos a tiempo. Si el dependiente, además, devuelve trabajo hacia aguas arriba (por ejemplo, refetcheando datos ya consumidos del bus de mensajes), se cierra un bucle de realimentación que puede atrapar al sistema en un estado metastable del que no puede salir.
El post distingue tres modos de recuperación —sin recuperación, aditiva y amplificada— y tipifica los “mismatches” que disparan la amplificación: térmico (los datos “fríos” requieren más recursos que los “calientes”), de granularidad (una unidad pequeña de déficit fuerza recomputar una unidad grande) y otros en estudio. La conclusión práctica es que compartimentizar fallos no basta: también hay que diseñar cómo se recupera cada sistema para evitar cascadas y bucles que conviertan la recuperación en el nuevo origen del problema.