Diseñar con actores: granularidad, identidad y un actor por entidad

Después de tres lecciones de teoría queda la pregunta que decide si un sistema de actores será una arquitectura o un disfraz: dónde se ponen las fronteras. La respuesta no sale de la intuición ni del modelo de datos, sale de una propiedad estructural que ya conoces y que casi nadie explota como criterio de diseño. Un actor procesa un mensaje cada vez, luego un actor es un punto de serialización, luego todo lo que un actor encierra queda automáticamente protegido por exclusión mutua y todo lo que queda fuera pierde esa protección para siempre. Elegir la granularidad es, por tanto, elegir qué invariantes vas a poder mantener sin esfuerzo y cuáles vas a tener que defender con protocolos. Es la misma decisión que en el diseño dirigido por el dominio se llama trazar el agregado, y no es una coincidencia.

La frontera del actor es la frontera de consistencia

Empieza por las invariantes, no por las entidades. Escribe las afirmaciones que deben ser ciertas en todo momento sin excepción —el saldo nunca queda negativo, no se venden dos asientos con el mismo número, el pedido confirmado tiene al menos una línea— y observa qué datos toca cada una. Todo lo que participa en una misma invariante atómica tiene que caber dentro de un mismo actor, porque el turno es el único lugar donde la atomicidad es gratuita. Y todo lo que no participa debe quedar fuera, porque meterlo dentro no compra nada y sí cuesta contención.

La regla inversa es igual de operativa y menos evidente: si dos datos están en el mismo actor pero ninguna invariante los relaciona, ese actor está serializando trabajo sin motivo. Cada mensaje que llega por uno de los dos motivos hace esperar a los del otro, y el rendimiento máximo de ambos queda atado al peor de los dos. Un actor demasiado grande no falla por consumo de memoria, falla por convertirse en un cuello de botella que además concentra riesgo: cuando muera, morirá con todo lo que custodiaba.

flowchart TD
subgraph Agregado
  P[pedido] --- L1[linea 1]
  P --- L2[linea 2]
end
C[catalogo] -. consistencia eventual .-> P
E[envio] -. consistencia eventual .-> P
P -- invariante atomica --> L1
P -- invariante atomica --> L2
style P fill:#cba6f7,color:#11111b
style C fill:#89b4fa,color:#11111b
style E fill:#89b4fa,color:#11111b

Aceptar esa frontera obliga a aceptar su reverso, y es aquí donde muchos equipos se detienen demasiado tarde: entre actores no hay transacciones. Ninguna. Una operación que afecte a dos actores es, por construcción, un protocolo de varios pasos con estados intermedios visibles, compensaciones para deshacer lo que ya se hizo y la posibilidad de quedarse a medias si alguien muere en el peor instante. Eso tiene un nombre —proceso de negocio de larga duración, gestor de proceso, saga— y tiene una forma natural: otro actor, cuyo estado es precisamente en qué punto de la conversación estamos.

import { setup, assign } from 'xstate'

// El gestor de proceso: su estado ES el punto de la conversacion,
// y cada camino de fallo tiene su compensacion declarada.
export const reserva = setup({
  types: {
    context: {} as { asiento: boolean; pago: boolean },
    events: {} as
      | { type: 'ASIENTO_OK' }
      | { type: 'ASIENTO_FALLO' }
      | { type: 'ASIENTO_LIBERADO' }
      | { type: 'PAGO_OK' }
      | { type: 'PAGO_FALLO' },
  },
}).createMachine({
  initial: 'reservandoAsiento',
  context: { asiento: false, pago: false },
  states: {
    reservandoAsiento: {
      on: {
        ASIENTO_OK: { target: 'cobrando', actions: assign({ asiento: true }) },
        ASIENTO_FALLO: 'rechazada',
      },
    },
    cobrando: {
      on: {
        PAGO_OK: { target: 'confirmada', actions: assign({ pago: true }) },
        PAGO_FALLO: 'liberandoAsiento',
      },
    },
    liberandoAsiento: { on: { ASIENTO_LIBERADO: 'rechazada' } },
    confirmada: { type: 'final' },
    rechazada: { type: 'final' },
  },
})

Ese grafo diminuto es la prueba de que renunciar a la transacción no equivale a renunciar al rigor. Lo que en una base de datos era invisible —el instante en que el asiento ya está tomado pero el cobro aún no ha ocurrido— aquí tiene nombre, es observable y admite una política explícita si el proceso se interrumpe justo ahí. La consistencia entre agregados no se pierde, se hace material.

Identidad: la dirección como clave de dominio

La identidad de un actor parece un asunto de nomenclatura y es una de las decisiones más cargadas del diseño, porque una sola cadena de texto acaba cumpliendo cuatro funciones a la vez.

De esas cuatro funciones se deduce la recomendación práctica: haz que la identidad se derive de una clave estable del dominio y no de un identificador generado al azar. Una identidad derivable regala la semántica de obtener o crear —el primer mensaje dirigido a una entidad que aún no existe la trae al mundo— y elimina la necesidad de un actor directorio que traduzca claves en direcciones. Ese directorio, cuando hace falta, es un salto de red más en cada operación y, peor aún, un punto de serialización global que reproduce en el sistema entero el problema que el diseño estaba intentando repartir.

// La identidad como funcion pura del dominio: sin directorio, sin sorpresas.
type ClaveActor = `${string}:${string}`

const claveDe = (tipo: string, id: string): ClaveActor => `${tipo}:${id}`

// Obtener o crear se vuelve trivial porque la direccion es calculable.
function dirigir(mensaje: { tipo: string; entidad: string }): ClaveActor {
  return claveDe(mensaje.tipo, mensaje.entidad)
}

Cuándo un actor por entidad y cuándo no

El patrón de un actor por entidad tiene una fuerza enorme y un rango de aplicación más estrecho de lo que sugiere su elegancia. La tabla que sigue recoge las señales que he visto decidir el asunto en la práctica.

La fila de las consultas merece un párrafo porque es donde más proyectos tropiezan. Un sistema de actores responde de maravilla a la pregunta qué le pasa a esta entidad y muy mal a la pregunta cuántas entidades cumplen tal condición, porque esa segunda pregunta exige recorrer muchos buzones, no tiene una vista transaccional coherente y produce un resultado que ya era viejo cuando terminó de componerse. La solución no es forzar el modelo sino admitir que hay dos caminos distintos: los actores llevan el camino de escritura, con sus invariantes y su consistencia fuerte por entidad, y las consultas se sirven desde proyecciones construidas a partir de los eventos que los actores publican. Esa separación no es un patrón exótico añadido, es la consecuencia directa de haber elegido una frontera de consistencia pequeña.

Antipatrones: dios, cadena y anemia

El actor dios es el más frecuente y el más fácil de justificar mientras se escribe. Nace de la comodidad de tener todo el estado en un sitio y termina siendo el equivalente exacto de un candado global, con la diferencia de que ahora es un candado que además guarda datos y que, cuando falla, se lleva el sistema entero. La señal temprana es un actor cuyo protocolo tiene decenas de mensajes sin ninguna relación entre sí; si al leer su lista de eventos no puedes enunciar una invariante que los una, no es un actor, es un almacén con buzón.

La cadena síncrona disfrazada es más sutil y más peligrosa. Ocurre cuando cada actor, al recibir un mensaje, pregunta a otro y espera su respuesta antes de continuar, de modo que una operación recorre cinco actores encadenados y su latencia es la suma de todas las esperas. Se ha reinventado la llamada síncrona con más ceremonia y sin sus ventajas, y se ha añadido una forma nueva de bloqueo: dos actores que se esperan mutuamente no se desbloquean nunca, porque el mensaje que liberaría a cada uno está en el buzón que el otro no está atendiendo. El remedio es diseñar la conversación en lugar de la llamada: quien inicia entrega su dirección, cada participante avanza sin esperar y el estado de la operación vive en un actor de proceso que va recibiendo confirmaciones.

El actor anémico cierra la lista. Es el actor que no tiene protocolo, solo dos mensajes para leer y escribir un dato, y que por tanto paga íntegro el coste del modelo —serialización, indirección, asincronía, ciclo de vida— sin cobrar ninguna de sus ventajas, porque no hay invariante que proteger ni comportamiento que designar. Si un actor podría sustituirse por una entrada en un mapa sin perder ninguna garantía, sustitúyelo.