El anti-patrón: la máquina que reimplementa una cache

El anti-patrón nunca se decide: se acumula. Nadie escribe un lunes por la mañana la resolución de implementar una cache dentro de un statechart. Lo que ocurre es que un assign guarda un resultado para no volver a pedirlo, y suena razonable; que una guarda comprueba si ya lo tenemos, y suena eficiente; que aparece un mapa por identificador cuando el flujo pasa a manejar varios recursos; que alguien añade una marca de tiempo porque el dato se quedaba viejo; y que al final del trimestre el contexto de la máquina contiene una tabla con política de caducidad, invalidación manual y un comentario pidiendo perdón. Cada paso fue local y defendible; el resultado es una cache sin deduplicación, sin compartición, sin recolección y sin herramientas, incrustada en el único sitio del sistema que no debía saber nada de frescura.

El síntoma: un mapa en el contexto

El código del anti-patrón es reconocible de un vistazo porque tiene un vocabulario propio que no pertenece al dominio de ninguna aplicación: claves, frescura, caducidad, invalidación.

type Contexto = {
  cache: Record<string, { dato: Ficha; en: number }>
  claveActual: string
}

const maquina = setup({
  guards: {
    yaLoTengoFresco: ({ context }) => {
      const entrada = context.cache[context.claveActual]
      return entrada !== undefined && Date.now() - entrada.en < 60_000
    },
  },
  actions: {
    guardar: assign({
      cache: ({ context, event }) => ({
        ...context.cache,
        [context.claveActual]: { dato: event.output, en: Date.now() },
      }),
    }),
    invalidarTodo: assign({ cache: {} }),
  },
}).createMachine({
  states: {
    decidiendo: {
      always: [{ target: 'listo', guard: 'yaLoTengoFresco' }, { target: 'leyendo' }],
    },
    leyendo: { invoke: { src: 'leerFicha', onDone: { target: 'listo', actions: 'guardar' } } },
    listo: { on: { OTRA_FICHA: { target: 'decidiendo', actions: 'elegirClave' } } },
  },
})

Nada de esto está mal escrito. La guarda es correcta, la acción es inmutable, el estado transitorio con always es idiomático. El problema es de ubicación: acabas de construir, dentro de un modelo cuyo propósito era describir el orden legal de un procedimiento, un almacén de datos con política temporal. El grafo ya no responde solo a dónde estoy y qué puedo hacer; ahora también responde a qué sé y desde cuándo, y esas dos preguntas envejecen a ritmos distintos y las tocan personas distintas.

Las señales de que te estás pasando de listo

El diagnóstico no requiere leer la máquina entera. Basta con buscar cuatro rasgos en el contexto y en las guardas, y contrastar con una quinta señal que no está en el código sino en las conversaciones del equipo.

La quinta señal es la más fiable y no vive en el repositorio: es la frase alguien tiene que refrescar la máquina cuando cambie ese dato. En cuanto un equipo necesita coordinar manualmente que un cambio en un sitio se refleje en un grafo que guardó una copia, la arquitectura ya está pidiendo a gritos una fuente única con invalidación por clave. Esa coordinación manual no escala porque crece de forma cuadrática: cada dato nuevo debe conectarse con cada máquina que lo hubiera copiado, y nadie mantiene esa matriz en la cabeza más allá de la tercera pantalla.

Por qué la cache casera pierde siempre

Conviene entender que la derrota no es por falta de talento ni de tiempo, sino por posición en la arquitectura. Una cache necesita ver todos los consumidores de un recurso para deduplicar, compartir e invalidar; el contexto de una máquina, por diseño, solo ve lo que ocurre dentro de ese actor. La limitación es estructural y ninguna cantidad de código la levanta.

Hay además un coste que la tabla no recoge y que suele decidir el debate: la carga cognitiva compuesta. Quien lee la máquina para entender el flujo tiene que atravesar la lógica de frescura, y quien la lee para entender la frescura tiene que atravesar el grafo. Dos preocupaciones entrelazadas cuestan más que la suma de las dos separadas, y esa multiplicación se paga en cada revisión de código durante toda la vida del módulo.

flowchart TD
A[el contexto guarda un dato de servidor] --> B[el dato lo consumen otros sitios?]
B -->|si| C[es cache: sacalo a la capa de datos]
B -->|no| D[te preocuparia que quedase obsoleto?]
D -->|si| C
D -->|no| E[cambiarlo sin permiso romperia el dominio?]
E -->|si| F[es una instantanea: se queda en el contexto]
E -->|no| G[es un derivado: calculalo al vuelo]
style C fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b
style G fill:#89dceb,color:#11111b

El refactor: devolver el dato a su dueño

La cura tiene tres movimientos y se puede aplicar sin detener el desarrollo. Primero, extrae la clave: convierte el mapa del contexto en un identificador y una función que construya la clave del recurso, sin tocar todavía nada más. Segundo, delega la lectura: sustituye el estado transitorio que consultaba la frescura por un actor que llama a la cache, porque esa decisión ya la toma ella y hacerlo dos veces solo produce discrepancias. Tercero, adelgaza el contexto: elimina las copias, deja los identificadores, las instantáneas con significado y los derivados mínimos que el flujo necesita para sus guardas.

type Contexto = {
  fichaId: string
  precioAceptado: number | null
  intentos: number
}

const leerFicha = fromPromise(({ input, signal }: { input: { id: string }; signal: AbortSignal }) =>
  qc.fetchQuery({
    queryKey: ['ficha', input.id],
    queryFn: () => fetch(`/api/fichas/${input.id}`, { signal }).then((r) => r.json()),
    staleTime: 60_000,
  })
)

El contexto resultante se lee en tres líneas y cada campo tiene una justificación distinta e irreductible: fichaId es identidad del flujo, precioAceptado es una instantánea con consecuencias, intentos es historia del procedimiento. Ninguno es una copia de algo que viva mejor en otro sitio, y esa es toda la prueba que el refactor necesita pasar. La guarda de frescura desaparece porque staleTime la expresa donde corresponde, y el estado transitorio que la consultaba se puede borrar entero.