Pídele a un almacén distribuido una clave y el costo lo domina un solo número: el viaje de ida y vuelta al nodo que la posee. La búsqueda en sí es nanosegundos; la red es microsegundos. Ahora pide mil claves. Si iteras y llamas a Get mil veces, pagas ese viaje de ida y vuelta mil veces, en serie, y el almacén gasta casi todo el tiempo de reloj sentado ocioso esperando paquetes. Las claves podrían estar repartidas sobre cuatro nodos que podrían haber respondido en paralelo —pero un bucle ingenuo nunca les da la oportunidad.

Zaris tiene tres APIs masivas —GetManyAsync, PutManyAsync, DeleteManyAsync— y un ExecuteBatchAsync mixto por debajo de ellas, y toda su razón de existir es convertir "mil claves" en "una solicitud por nodo propietario, emitidas en paralelo". Este artículo es la ruta de fan-out de principio a fin: cómo el cliente agrupa claves por propietario, por qué las cuatro APIs colapsan sobre un único motor, cómo un campo Index mantiene las respuestas en orden a través de dos capas de concurrencia, y por qué —a diferencia de una transacción multiclave— una operación masiva es por ítem y el éxito parcial es normal.

El modelo de costos: viajes de ida y vuelta, no operaciones​

Lo que una API masiva combate no es la CPU. Un GET de clave única en un nodo propietario es una búsqueda en diccionario —el piso de latencia es un microsegundo de trabajo real dentro de diez de plomería. La parte cara es la plomería: la solicitud tiene que cruzar la red al propietario y la respuesta tiene que volver. Llama a ese tiempo de ida y vuelta R, típicamente decenas a cientos de microsegundos en una red de datacenter, órdenes de magnitud más que la búsqueda.

Un bucle en serie de N claves cuesta aproximadamente N × R, porque cada llamada espera a que el paquete de la anterior vuelva antes de enviar la siguiente. Esa es la trampa. El arreglo no es una búsqueda más rápida —es dejar de pagar R por clave. Si las N claves viven en M nodos propietarios, el piso es R pagado M veces concurrentemente, es decir, alrededor de un R en total sin importar cuántas claves sostenga cada nodo. Para mil claves en cuatro nodos esa es la diferencia entre mil viajes de ida y vuelta en serie y, en efecto, uno. Todo el diseño de abajo existe para colapsar N × R a ~R.

Un motor: todo es un lote de ítems​

Lo primero sorprendente en el cliente de clúster es que GetManyAsync, PutManyAsync y DeleteManyAsync no son tres implementaciones separadas. Cada una es una fina capa (shim) que convierte sus argumentos en una lista de KvBatchItems y los entrega al único método que hace el trabajo real, ExecuteBatchAsync. Aquí está GetManyAsync haciendo exactamente eso:

var list = keys.Select((k, i) => new KvBatchItem
{
    Index = i,                 // caller's position — the correlation key
    Op    = KvBatchOp.Get,
    Key   = k,
    GetOptions = options?.ToGetOptions()
}).ToList();

var resp = await ExecuteBatchAsync<T>(
    new KvBatchRequest
    {
        Items = list,
        DefaultConsistency = options?.Consistency ?? Defaults.DefaultConsistency
    }, ct).ConfigureAwait(false);

PutManyAsync y DeleteManyAsync hacen lo mismo con KvBatchOp.Put y KvBatchOp.Delete. Así que la distinción que los ejemplos trazan entre Bulk (un tipo de operación a la vez) y Batch (una mezcla de PUT / GET / DELETE en una llamada) es una conveniencia de superficie: los ayudantes masivos son solo un lote donde cada ítem resulta compartir una operación. Hay exactamente un motor de fan-out, y es agnóstico a la operación.

Nota Index = i. Cada ítem se estampa con su posición en la lista del llamador antes de que nada se agrupe, reordene o envíe. Ese sello es lo que sobrevive a los dos saltos concurrentes por venir y permite que la respuesta final se devuelva en orden. Agárrate a él.

El fan-out: agrupar por propietario, una solicitud cada uno​

Aquí está el corazón de todo el artículo —el despacho de lotes del cliente de clúster, esencialmente completo:

var table   = _routing;
var buckets = new Dictionary<ZarisRemoteClient, List<KvBatchItem>>();

foreach (var item in batch.Items)
{
    var seg    = SegmentMapper.ComputeSegmentId(item.Key, table.TotalSegments);
    var client = GetClientForSegment(seg, table);

    if (!buckets.TryGetValue(client, out var list))
        buckets[client] = list = new List<KvBatchItem>();

    list.Add(item);
}

var tasks = buckets.Select(kv =>
    kv.Key.ExecuteBatchAsync<T>(new KvBatchRequest
    {
        Items = kv.Value,
        DefaultConsistency = batch.DefaultConsistency
    }, ct));

var perOwner = await Task.WhenAll(tasks).ConfigureAwait(false);

return new KvBatchResponse
{
    Results = perOwner.SelectMany(r => r.Results)
                      .OrderBy(r => r.Index)
                      .ToList()
};

Léelo como cuatro movimientos:

1. Resuelve cada clave a su propietario, localmente. SegmentMapper.ComputeSegmentId es la misma función de ubicación que usa la ruta de clave única —CRC16 sobre el hash-tag, módulo el conteo de segmentos— y GetClientForSegment mapea ese segmento a la conexión ya abierta de su nodo propietario. Sin proxy, sin coordinador: el cliente computa la propiedad él mismo, exactamente como se describe en un salto al propietario. La diferencia es que aquí lo hace para cada clave del conjunto a la vez.

2. Agrupa. Las claves poseídas por el mismo nodo se amontonan en la lista de ese nodo. Mil claves repartidas sobre cuatro propietarios se convierten en cuatro listas. Aquí es donde N operaciones se convierten en M solicitudes.

3. Despacha concurrentemente. buckets.Select(...) construye una llamada ExecuteBatchAsync por propietario y Task.WhenAll deja que todas vuelen a la vez. Cuatro nodos responden en paralelo; el tiempo de reloj es la respuesta del nodo más lento, no la suma.

4. Recombina en orden. Cada propietario devuelve su porción de resultados; SelectMany los aplana y OrderBy(r => r.Index) restaura el orden original del llamador. El llamador recibe de vuelta una lista cuya posición i es la respuesta para la clave i, aunque las claves viajaron a nodos distintos y volvieron en el orden que sea que la red entregó.

Esa es la afirmación completa de amortización hecha concreta: el número de viajes de ida y vuelta es igual al número de nodos propietarios distintos en el conjunto de claves, no al número de claves.

Dentro de un propietario: concurrente de nuevo, ordenado de nuevo​

Cada sub-lote por propietario aterriza en el BatchCommandHandler de ese nodo. Tampoco ejecuta los ítems uno tras otro —los ejecuta todos a la vez y luego reordena:

var items = batchReq.Request.Items.Cast<KvBatchItemWire>().ToArray();

// Execute every item in the sub-batch concurrently.
var tasks   = items.Select(item => ExecuteItemAsync(item)).ToArray();
var results = await Task.WhenAll(tasks).ConfigureAwait(false);

return new ZarisResponse
{
    Payload = new BatchResponsePayload
    {
        Response = new KvBatchResponse
        {
            Results = results.OrderBy(r => r.Index).ToList()
        }
    }
};

ExecuteItemAsync es un pequeño switch sobre la operación que despacha cada ítem al almacén —GetRawAsync, PutRawAsync o DeleteRawAsync— así que un lote mixto de lecturas y escrituras se maneja ítem por ítem dentro de la misma solicitud. (Para los routers en proceso y de un solo nodo la misma forma aparece como un Parallel.ForEachAsync sobre las claves, acotado por MaxDegreeOfParallelism —una opción MaxParallelism o Environment.ProcessorCount por defecto— que es por qué las lecturas escalan con los núcleos: un sub-lote gordo mantiene ocupado cada núcleo en lugar de uno.)

Así que el sello Index se gana el sustento dos veces. La concurrencia desordena el orden en el nodo, así que el handler ordena por Index antes de responder. El fan-out desordena el orden en el cliente, así que el cliente ordena por Index después de fusionar. El llamador nunca ve ninguno de los dos desórdenes. Un pequeño entero, llevado en cada ítem desde el momento en que se construye la solicitud, es el mecanismo entero que hace seguro exponer "lánzalo todo al clúster en paralelo" como una lista ordenada.

Una operación masiva no es una transacción​

Esta es la distinción que la gente más a menudo entiende mal, así que vale la pena enunciarla con nitidez. Cada ítem en un lote lleva su propio resultado. El tipo de resultado por ítem registra el éxito, el estado y —para las operaciones que los tienen— la revisión, la versión y el TTL de esa única clave:

private static KvBatchItemResult MapKvToBatch(int index, KvBatchOp op, KvResult r) => new()
{
    Index   = index,
    Op      = op,
    Success = r.IsSuccess,
    Status  = r.Status,          // e.g. Success, NotFound, Moved
    Revision = r.Revision?.Value,
    ItemVersion = r.Version?.Version,
    Ttl     = r.TimeToLive
};

No hay punto de confirmación compartido. Un GetMany sobre cien claves donde treinta no existen devuelve setenta resultados Success y treinta resultados NotFound, intercalados por índice —no un error, no una lista vacía. Un PutMany donde el segmento de una clave está a mitad de migración devuelve ese único ítem con estado Moved y el resto Success. El éxito parcial es la forma normal y esperada de la respuesta, y se espera que el llamador inspeccione cada ítem.

Eso es exactamente lo opuesto de una transacción multiclave, que es todo-o-nada por construcción: un commit de dos fases coordinado por el cliente sobre versiones optimistas donde o cada clave se mueve o ninguna lo hace. Las dos características parecen similares desde fuera —ambas toman muchas claves en una llamada— y están construidas para necesidades opuestas. Recurre a un lote cuando las claves son independientes y quieres throughput; recurre a una transacción cuando un invariante abarca las claves y un resultado a medio aplicar lo corrompería. Zaris las mantiene como APIs separadas precisamente para que la semántica nunca sea ambigua: un lote nunca revierte silenciosamente, y una transacción nunca confirma silenciosamente a medias.

Sobrevivir a una propiedad que se mueve a mitad de lote​

Una operación masiva es un blanco más amplio que un solo GET para el problema de que la propiedad cambie por debajo. Entre el momento en que el cliente agrupa una clave al nodo A y el momento en que el nodo A maneja el sub-lote, un cut-over de partición puede haber movido ese segmento al nodo B. El nodo A responderá esos ítems con estado Moved en lugar de adivinar.

El cliente de clúster envuelve todo el fan-out en un reintento acotado exactamente para esto:

public override async Task<KvBatchResponse> ExecuteBatchAsync<T>(
    KvBatchRequest batch, CancellationToken ct = default)
{
    return await RetryHelper.RetryAsync(
        () => ExecuteBatchClusterAsync<T>(batch, ct),
        maxAttempts: 2,
        backoffMillis: 100,
        logger: _logger).ConfigureAwait(false);
}

En un reintento la tabla de enrutamiento usualmente se ha refrescado, así que el re-agrupamiento envía las claves movidas a su nuevo propietario. El reintento es deliberadamente superficial —dos intentos, un backoff corto— porque el objetivo es aguantar una tabla de enrutamiento que está momentáneamente obsoleta, no empapelar un nodo que realmente está caído. Esta es la misma disciplina descrita en reintentos bajo churn de propiedad, aplicada a todo un conjunto de claves a la vez: el reintento re-ejecuta el agrupamiento, no solo el envío, así que cada intento refleja la propiedad más reciente en lugar de reproducir un plan obsoleto.

Un bug real, porque la forma de cable tiene dos variantes​

Vale la pena mostrar un lugar donde esta ruta se rompió, porque dice algo sobre las operaciones masivas específicamente. El valor de un resultado GET puede llegar por el cable en dos formas —envuelto en un sobre ZarisEntry, o como un valor serializado en bruto— dependiendo de cómo se almacenó (ver lo que cruza el cable). El decodificador original de GET masivo asumía solo la forma envuelta y lanzaba una excepción con la en bruto.

Para un solo GET eso es un fallo de una clave. Para un GetMany era catastrófico de forma sutil: cada clave en el lote fallaba, porque la única codificación no manejada lanzaba antes de que se decodificara cualquier resultado. Una corrida de certificación lo marcó como "fallos de get masivo", y el arreglo fue enrutar la decodificación a través de un ayudante compartido de codificación-dual que maneja ambas formas:

// Decode through the shared helper (handles both the ZarisEntry-wrapper and
// the raw-value forms the server can emit). The old inline code assumed only
// the wrapper and threw, failing every key of a bulk GET.
var obj = KvBatchItemResultExtensions.GetValue<T>(r);

La lección que generaliza: en una ruta masiva, un defecto en la maquinaria por ítem compartida se multiplica por el tamaño del lote, y un error que es una molestia para una clave es una interrupción para mil. El modelo de resultado por ítem es lo que contiene el radio de explosión —una vez que la decodificación es correcta, un valor malformado falla un ítem y deja los otros 999 intactos.

Qué compra el fan-out​

Junta las piezas y la forma de la victoria es clara. Una llamada masiva estampa cada ítem con su índice, resuelve el propietario de cada clave con la misma aritmética de ubicación que usa la ruta de clave única, agrupa las claves para que N operaciones se conviertan en una solicitud por nodo propietario, dispara esas solicitudes concurrentemente, y reensambla las respuestas en el orden del llamador —sobreviviendo a una tabla de enrutamiento que cambia en pleno vuelo y reportando el destino de cada clave independientemente. El conteo de viajes de ida y vuelta cae del número de claves al número de nodos, que es el único número que alguna vez iba a importar.

Nada de ello requirió una nueva ruta de almacenamiento o un nuevo registro de cable. Las APIs masivas son una capa de planificación sobre las primitivas que Zaris ya tiene: la ubicación consciente de particiones que le dice al cliente quién posee qué, el contrato por registro que cada resultado de ítem reutiliza, y la ejecución núcleo-paralela que mastica un sub-lote una vez que aterriza. La parte difícil de ir rápido en muchas claves nunca fueron las claves —era negarse a pagar por la red una clave a la vez.

Hay dos formas honestas de construir un cliente de caché distribuida. La primera es elegir cualquier nodo, enviarle la solicitud, y dejar que el clúster la reenvíe internamente a quien posea la clave —simple en el cliente, pero cada solicitud que aterriza en el nodo equivocado paga un salto de red adicional dentro del clúster. La segunda es hacer al cliente lo bastante listo como para saber qué nodo posee la clave antes de enviar nada, para que el primer socket que toque sea el que realmente puede responder. Zaris toma la segunda vía. Un GET sale de tu proceso ya dirigido al nodo que sostiene la clave —sin proxy, sin salto de reenvío, sin coordinador en el medio.

Este artículo es la vista interna de cómo funciona eso: la función que convierte una clave en un propietario, la tabla de búsqueda que el cliente mantiene en memoria, y —la parte que es fácil de equivocar— cómo el cliente se mantiene correcto cuando la propiedad se mueve mientras tu tráfico está en vuelo.

La afirmación, enunciada con precisión​

Cuando llamas a client.GetAsync("user:42"), el cliente hace tres cosas antes de que ningún byte toque la red:

1. Hace hash de la clave a un segmento. Una función pura mapea la cadena de la clave a uno de los segmentos del clúster.
2. Busca el propietario del segmento. Un arreglo en memoria mapea ese segmento directamente a la única conexión que alcanza su nodo propietario activo.
3. Envía directo-al-propietario. La solicitud va por esa conexión y ninguna otra.

Ningún paso consulta un router central. El paso 1 es aritmética, los pasos 2 y 3 son un índice de arreglo y una escritura de socket. El cliente sostiene una conexión por nodo y una pequeña tabla de enrutamiento, y ese es todo el aparato. La ingeniería interesante no es la ruta feliz —es mantener esa tabla honesta.

Paso 1 — la clave se convierte en un segmento​

Zaris hace hash de las claves exactamente del modo en que lo hace un cliente de Redis Cluster, a propósito. La función de ubicación vive en SegmentMapper, y su comentario de documentación es contundente sobre por qué se ve como se ve:

// Maps a key to its segment. Placement is aligned to the Redis Cluster slot model so a Redis cluster client
// (which routes by CRC16(key) % 16384) and Zaris agree on where a key lives: the key's Redis slot is
// computed the exact Redis way (XMODEM CRC16 over the hash-tag, mod 16384), then the 16384 slots are mapped
// proportionally onto the cluster's segments.
// This is the SINGLE shared placement function used by both the client and the server.

Esa última línea es la que más importa. No es "el cliente computa la ubicación de una forma y el servidor la valida de otra". Es el mismo código, compilado en el ensamblado del cliente y el ensamblado del servidor, produciendo el mismo segmento para la misma clave cada vez. Si el cliente y el servidor discreparan sobre dónde vive una clave, cada escritura sería un lanzamiento de moneda entre aterrizar en el propietario y aterrizar en un nodo que tiene que rechazarla. Compartir la función hace esa clase de bug irrepresentable.

La computación en sí son dos movimientos:

public static ushort ComputeSegmentId(string key, int shardCount, ...)
{
    var slot = ComputeSlot(key);                 // CRC16(hash-tag) % 16384
    return SlotToSegment(slot, shardCount);      // proportional slot -> segment
}

// The Redis Cluster key slot: XMODEM CRC16 over the hash-tag (or the whole key), mod 16384.
public static int ComputeSlot(string key)
{
    var (start, len) = HashTagRange(key);
    return Crc16(key, start, len) % RedisSlots;  // RedisSlots = 16384
}

Primero la clave se reduce a un slot en el rango fijo [0, 16384) usando XMODEM CRC16 —el mismo polinomio CRC16-CCITT (0x1021, init 0x0000) que usa Redis. Luego los 16384 slots se mapean proporcionalmente sobre cuantos segmentos tenga realmente el clúster:

public static ushort SlotToSegment(int slot, int shardCount)
    => (ushort)((long)slot * shardCount / RedisSlots);

Dos slots pueden caer en el mismo segmento; un segmento es un rango contiguo de slots. Esa alineación es lo que permite a Zaris responder CLUSTER SLOTS correctamente para un cliente de Redis Cluster mientras sigue enrutando por su propio modelo de segmentos internamente —las dos vistas son la misma vista a distintas resoluciones.

Hash tags: decidir qué se co-ubica​

Hay una escotilla de escape deliberada en el hashing de claves. Si una clave contiene un grupo {...} con al menos un carácter dentro de las llaves, solo los bytes dentro de las llaves se hashean:

// Redis hash tag: if the key contains "{...}" with at least one char between the braces, only that
// substring is hashed (so "{u1}:a" and "{u1}:b" co-locate). Otherwise the whole key is hashed.

Así es como fuerzas claves relacionadas al mismo segmento. {u1}:profile y {u1}:sessions ambas hashean sobre u1, así que comparten un segmento y por tanto un propietario —que es exactamente lo que necesitas para una transacción multiclave o cualquier operación que tenga que tocar varias claves atómicamente en un nodo. Las claves sin un tag se reparten por todo el espacio de claves. El cliente y el servidor coinciden en esto también, porque es el mismo HashTagRange en ambos lados.

Un detalle más que vale la pena notar para la ruta caliente: el bucle CRC16 tiene una ruta rápida todo-ASCII que hashea los caracteres como bytes sin asignación, y solo recurre a una codificación UTF-8 para claves no-ASCII. Enrutar cada operación significa que esto corre en cada operación, así que se escribió para no asignar en el caso común.

Paso 2 — el segmento se convierte en una conexión​

Ahora el cliente tiene un número de segmento. Necesita el nodo que actualmente lo posee. El cliente mantiene una RoutingTable inmutable cuyos campos son toda la historia:

// one live connection per node, keyed by node id
public ImmutableDictionary<string, ZarisRemoteClient> Clients { get; init; }

// segment -> the active-owner client it routes to (the precomputed answer)
public ZarisRemoteClient?[] SegmentMap { get; init; }

// segment -> partition, and partition -> owning node id
public ushort[] SegmentToPartition { get; init; }
public ImmutableDictionary<int, string?> RuntimeOwners { get; init; }

La elección de diseño clave es SegmentMap. Es un arreglo, indexado por segmento, cuyas entradas están ya resueltas a la conexión del propietario de ese segmento. Enrutar una clave no es un recorrido de grafo de segmento a partición a nodo a conexión en el momento de la solicitud —esa resolución se hace de antemano cuando se construye la tabla, así que el costo por solicitud es un único índice de arreglo:

internal ZarisRemoteClient GetClientForKey(string key)
{
    var table = _routing;
    return GetClientForSegment(
        SegmentMapper.ComputeSegmentId(key, table.TotalSegments),
        table);
}

private static ZarisRemoteClient GetClientForSegment(ushort segment, RoutingTable table)
{
    if (segment >= table.SegmentMap.Length)
        throw new InvalidOperationException($"No client mapped for segment {segment} — map may be mid-update, retry");

    if (table.SegmentMap[segment] is not { } client)
    {
        var partitionId = segment < table.SegmentToPartition.Length
            ? table.SegmentToPartition[segment] : -1;
        throw new PartitionUnavailableException(partitionId, segment);
    }
    return client;
}

Clients sostiene exactamente un ZarisRemoteClient —una conexión— por nodo. El cliente no abre un socket fresco por solicitud o por clave; multiplexa todo el tráfico de un nodo sobre la única conexión de ese nodo, y SegmentMap simplemente apunta muchos segmentos al mismo objeto de conexión (la igualdad por referencia los deduplica cuando el cliente necesita el conjunto distinto de propietarios activos, por ejemplo para hacer fan-out de un escaneo). Así que el costo de memoria de la consciencia de particiones es una conexión por nodo más un par de arreglos dimensionados al conteo de segmentos —no crece con el número de claves o solicitudes.

El beneficio es que no hay nodo en el clúster cuyo trabajo sea recibir solicitudes mal enrutadas y reenviarlas. Cada solicitud bien enrutada la sirve el primer nodo que alcanza. Eso elimina todo un nivel del presupuesto de latencia y, igual de importante, de la superficie de fallo —no puedes perder una solicitud en un salto de reenvío que no existe. (La pieza compañera sobre el piso de latencia recorre lo que sí queda en el presupuesto una vez que el salto de proxy se ha ido.)

Paso 3 — el mapa se mueve por debajo​

Aquí está la parte difícil. La tabla de enrutamiento es una caché de un hecho —"el segmento S es propiedad del nodo N"— que el clúster puede cambiar en cualquier momento. Un propietario puede fallar y una réplica es promovida; una partición puede migrarse para hacer crecer o drenar un nodo. En el instante en que eso ocurre, el SegmentMap[S] del cliente apunta a una conexión que ya no es el propietario. Un cliente que confiara en su tabla ciegamente enviaría escrituras a un nodo que correctamente las rechazará.

Zaris mantiene la tabla honesta de tres formas, en orden de preferencia.

Push — el servidor le dice al cliente. Cuando la propiedad cambia, el clúster emite un RuntimeOwnershipChangedEvent, y el cliente tiene un handler suscrito a él:

public Task HandleAsync(IServerEvent @event)
{
    if (@event is RuntimeOwnershipChangedEvent runtimeEvent)
        _router.TryUpdateRuntimeOwnership(runtimeEvent);
    return Task.CompletedTask;
}

TryUpdateRuntimeOwnership no reconstruye toda la tabla. Clona el arreglo SegmentMap, re-apunta solo los segmentos cuya partición realmente cambió de propietario, e intercambia la tabla inmutable con una única asignación de referencia. Los lectores nunca ven una tabla a medio actualizar —o leen la vieja o la nueva, nunca una mezcla rota. Esto es enrutamiento copy-on-write: el caso común (nada cambió) no cuesta nada, y un cambio toca solo los segmentos afectados.

Poll — un respaldo lento. Un temporizador refresca el mapa del clúster cada diez segundos sin importar nada, así que incluso si un evento push se pierde (una reconexión, una notificación dejada caer), la vista del cliente se auto-sana dentro de un intervalo:

private readonly TimeSpan _pollInterval = TimeSpan.FromSeconds(10);

React — la propia solicitud corrige el mapa. La última línea de defensa es la solicitud que enruta mal. Si el cliente envía a un nodo que ya no es el propietario, el nodo no lo reenvía silenciosamente —devuelve un estado que le dice al cliente que su mapa está obsoleto, y el ayudante de reintento refresca e intenta de nuevo:

private static bool RequiresMapRefresh(KvStatus status)
    => status == KvStatus.Moved
       || status == KvStatus.ReplicaWriteRejected
       // Ownership is mid-handoff: the client must force-fetch the updated
       // ownership and retry against the node that now owns the segment.
       || status == KvStatus.OwnershipChanging;

Cuando una operación reintentable vuelve Moved, OwnershipChanging o ReplicaWriteRejected, el cliente llama a su gancho de refresco y reintenta —un bucle acotado de unos pocos intentos con un backoff corto, no un giro sin fin. Hay una lección sutil horneada en el código actual aquí: una versión anterior refrescaba el mapa en cada intento de reintento, lo que bajo churn intenso de nodos convertía una sola operación fallida en docenas de refrescos todos serializados detrás de un lock. El arreglo fue refrescar solo cuando el estado realmente dice "tu mapa está mal", no meramente porque un intento falló. El tratamiento más profundo de esa disciplina de reintentos es su propio artículo —reintentos bajo churn de propiedad— pero la versión de una línea es: un mapa obsoleto es una condición auto-correctiva, y la corrección es barata precisamente porque es rara y dirigida.

Los tres mecanismos se superponen: el push hace el caso común instantáneo, el poll hace que un push perdido sea eventualmente consistente, y el reintento reactivo hace invisible cualquier obsolescencia residual para tu llamada —solo toma un viaje de ida y vuelta extra en el momento en que la propiedad se movió, y es correcto desde la siguiente llamada en adelante.

¿Por qué hacerlo en el cliente en absoluto?​

El enrutamiento consciente de particiones del lado del cliente cuesta algo. El cliente tiene que llevar un modelo del clúster, mantenerlo fresco, y enviar la misma lógica de ubicación que usa el servidor. Un diseño basado en proxy empuja todo eso al clúster y deja que el cliente siga siendo tonto. Entonces, ¿por qué pagar?

Porque la alternativa paga en cada solicitud individual, para siempre. Un proxy o un diseño de "envía a cualquier lado, lo reenviaremos" añade un salto a la ruta caliente de cada operación —un salto que es pura sobrecarga, presente incluso cuando nada ha fallado y nada se está moviendo. Zaris paga el costo del enrutamiento una vez, por adelantado, y solo de nuevo cuando la propiedad realmente cambia— lo que, en un clúster saludable, es casi nunca. El estado estable es un índice de arreglo y una escritura de socket al nodo correcto. Esa es la razón entera por la que las lecturas escalan con tus núcleos en lugar de embotellarse en un nivel intermedio: no hay nivel intermedio donde embotellarse.

Y compone con todo lo demás. La misma resolución GetClientForKey es por la que un key-watch, un incremento de contador, un compare-and-swap y una operación de estructura de datos de clave única enrutan todos, así que todos heredan la entrega directa-al-propietario y el mismo mapa auto-sanante. El cliente no es una tubería tonta con enrutamiento atornillado; el enrutamiento es la cosa que el cliente es.

Los compromisos honestos​

El enrutamiento directo-al-propietario no está libre de bordes, y vale la pena nombrarlos.

• El cliente debe alcanzar cada nodo. Como no hay proxy, el cliente abre una conexión a cada nodo al que enruta. En una red plana eso es un no-problema; a través de una frontera —digamos un cliente fuera de Kubernetes— esos nodos tienen que ser direccionables individualmente. Ese es exactamente el problema que el direccionamiento de clientes externos existe para resolver, y es una consecuencia directa de que no haya una única puerta de entrada.
• Un breve retraso del mapa es posible, no una pérdida. En la ventana entre que la propiedad se mueve y que el cliente se entera, una solicitud puede enrutar al propietario viejo. Se rechaza y reintenta, no se mal-aplica —la ruta reactiva de arriba garantiza que el reintento aterrice en el propietario real. Pagas un viaje de ida y vuelta, no una respuesta errónea.
• La función de ubicación es un contrato de compatibilidad. Como el cliente y el servidor comparten SegmentMapper, no puedes cambiar cómo las claves hashean a segmentos sin que ambos lados coincidan —que es precisamente por qué el hashing se alineó al modelo de slots estable de Redis en lugar de a un esquema interno que podría derivar.

Enunciado sin rodeos: el cliente de Zaris sabe dónde viven tus claves, mantiene ese conocimiento actual sin que lo pienses, y gasta un salto de red —el que realmente hace el trabajo— en cada operación. La astucia no está en la ruta rápida, que es deliberadamente aburrida. Está en los tres mecanismos silenciosos que mantienen correcta la ruta rápida mientras el clúster se reconfigura por debajo.

Un failover cubre el momento en que un propietario muere: el clúster elige un superviviente y sigue sirviendo. Una migración planificada cubre mover la partición de un propietario sano a propósito. Este artículo trata del tercer acto, el que corre después de que las sirenas se apagan —el proceso propietario original reinicia, se reúne al clúster, y quiere su partición de vuelta. Su almacén de nada-en-disco, todo-en-memoria volvió vacío. Los datos de los que es responsable siguen vivos, pero están vivos en las réplicas que siguieron sirviendo mientras estaba caído.

Todo el problema de corrección está contenido en una frase: al propietario reiniciado no se le puede permitir confiar en su propia vacuidad. Un almacén vacío se ve exactamente como un almacén que alguien limpió deliberadamente. Si el nodo asume "soy el propietario y no tengo datos, por lo tanto esta partición está vacía", servirá alegremente NotFound para millones de claves vivas y, peor, dejará que su estado vacío fluya de vuelta a las réplicas y las elimine. Este artículo recorre las cinco políticas pequeñas y puras que Zaris usa para asegurar que eso nunca ocurra.

Por qué la vacuidad es indecidible desde dentro​

Empieza con la trampa, porque cada regla de abajo está moldeada por ella. Un nodo que arranca sosteniendo cero registros para un segmento que posee está en uno de dos estados, y no puede saber cuál solo con información local:

1. Está vacío porque acaba de reiniciar y nunca extrajo sus datos de vuelta. Debe extraer.
2. Está vacío porque autoritativamente limpió o expiró esas claves, y una réplica que estuvo brevemente caída todavía sostiene las copias obsoletas. Si extrae, resucita datos eliminados.

Estos dos son localmente indistinguibles —el almacén está vacío de cualquier modo. Una versión anterior de Zaris intentó resolver esto con una señal de anomalía EmptyActive y se eliminó precisamente porque la señal es una conjetura. No puedes preguntar "¿estoy vacío por una buena razón?" y obtener una respuesta confiable del nodo vacío.

Así que Zaris no le pregunta nada a la vacuidad. Enruta la decisión a través de un hecho distinto: un flag pegajoso a nivel de partición llamado certified (certificado), que significa exactamente "mi sincronización de arranque se completó y mi almacén es ahora autoritativo". Un nodo lo establece solo después de haber demostrado la posesión. Un propietario recién reiniciado está, por definición, sin certificar— y un propietario sin certificar no tiene autoridad para estar vacío. Debe extraer de quien sea que sostenga los datos. Un propietario certificado es autoritativo y se deja estrictamente en paz, así que una limpieza legítima nunca se resucita.

Ese único reencuadre —de vacuidad (indecidible) a certificación (un hecho demostrado y pegajoso)— es lo que hace segura el resto de la recuperación.

Paso 1 — el propietario reiniciado extrae, en lugar de asumir​

Cuando el nodo se reúne, el mapa todavía lo asigna como propietario de su partición vieja. El disparador de sincronización inversa decide si cada segmento poseído debería ser extraído de una réplica viva en lugar de tratarse como localmente autoritativo:

public static bool ShouldReverseSyncOwnedSegment(
    bool partitionCertified,
    bool isMapPreferredPrimary,
    bool liveNonSelfReplicaExists)
    => !partitionCertified && liveNonSelfReplicaExists;

Tres cosas sobre este diminuto predicado son portantes, y cada una es un bug que alcanzó una corrida de certificación antes de que la regla se escribiera.

Ignora isMapPreferredPrimary. Ese parámetro todavía se pasa —como contexto-de-decisión documentado— pero la decisión deliberadamente no lo lee. Una versión anterior solo disparaba la sincronización inversa cuando el nodo era también el primario preferido del mapa. Un nodo que es el activo en tiempo de ejecución pero no el primario del mapa —el estado exacto en el que aterriza un propietario re-ubicado o promovido-tras-recuperación— tenía sus segmentos poseídos omitidos por completo. Nunca solicitaba sus datos y quedaba varado vacío para siempre mientras una réplica viva sostenía cada registro (una corrida de certificación: activo sosteniendo 0 vs réplica sosteniendo 4600 en quince segmentos, nunca convergió a lo largo de ocho minutos). La propiedad de la extracción de datos no puede estar condicionada a ser el primario preferido; tiene que dispararse para cualquier activo sin certificar.

La señal es !partitionCertified, no la vacuidad. Este es el arreglo de la indecidibilidad de la sección anterior, en código. Un activo sin certificar nunca ha demostrado posesión, así que extrae; uno certificado es autoritativo y se omite.

liveNonSelfReplicaExists es una guarda, no una cortesía. Si la réplica configurada está caída, no hay nada de lo que sincronizar. Impulsar la recuperación contra una fuente muerta gira para siempre (RECOVERY STUCK source=self synced=0/128). Así que cuando no existe una réplica viva, el activo es la única copia superviviente —es la autoridad, y certifica de inmediato en lugar de esperar a una fuente que nunca responderá. La extracción en sí está bloqueada por revisión (revision-fenced) y acotada por marca de agua (watermark-bounded), lo que la hace un no-op inofensivo cuando la réplica resulta no sostener nada.

Paso 2 — no sirvas una clave que todavía no has alcanzado​

Extraer no es instantáneo, y la ventana mientras corre es donde las lecturas confirmadas se convierten silenciosamente en NotFound. Una compuerta ingenua es un único booleano, IsSynced, que significa "una pasada de sincronización terminó". Ese booleano no es suficiente, y tres fallos de certificación separados lo probaron: un activo que reclamaba promovió 34 claves corto; un traspaso perdió una clave confirmada; un activo que se reunía sirvió NotFound para 57 claves durante el churn. En cada caso una pasada de sincronización había terminado —pero la fuente (el activo temporal que siguió sirviendo) había desde entonces aceptado más escrituras que el nodo en recuperación no había extraído. IsSynced era verdadero y el nodo seguía atrasado.

El arreglo es condicionar sobre una posición, no un flag. La revisión del log de operaciones es un número replicado y comparable entre nodos: el activo la asigna y la envía, así que una réplica al día converge a la misma cabeza. La compuerta de servicio compara cabezas:

public static SegmentServeDecision Decide(bool isSynced, long localHeadRevision, long sourceHeadRevision)
{
    if (!isSynced)
        return SegmentServeDecision.HoldUnsynced;

    // A watermark of 0 carries no information — do not block on it; trust the completed sync pass.
    if (sourceHeadRevision > 0 && localHeadRevision < sourceHeadRevision)
        return SegmentServeDecision.HoldBehindSource;

    return SegmentServeDecision.Serve;
}

HoldBehindSource es el nuevo estado que importa: una pasada de sincronización se completó, pero la cabeza de la fuente (capturada en esa sincronización) va por delante de la nuestra, así que la fuente aceptó escrituras que no hemos extraído. Servir ahora devolvería NotFound para exactamente esas claves. El nodo se mantiene hasta que su cabeza local alcanza la marca de agua. Nota la degradación deliberada: una marca de agua registrada de 0 significa "sin información de marca de agua", y la compuerta recae en el comportamiento solo-IsSynced en lugar de bloquear para siempre sobre datos faltantes. La regla nunca bloquea sobre la ausencia de un hecho —solo sobre un hecho que dice vas atrasado.

Paso 3 — extrae, pero no pisotees​

Ahora la dirección peligrosa: aplicar la instantánea que la réplica envía de vuelta. El instinto es limpiar el almacén local y copiar la instantánea al por mayor. Ese instinto es correcto exactamente la mitad de las veces, y catastróficamente erróneo la otra mitad. La pregunta decisiva es de quién son las revisiones comparables con las de quién:

public static ResyncApplyMode Decide(
    bool digestMatches,
    bool isPassiveSubordinateReplica,
    bool priorReconcileShortfall = false)
    => digestMatches
        ? ResyncApplyMode.Skip
        : (isPassiveSubordinateReplica && !priorReconcileShortfall)
            ? ResyncApplyMode.Reconcile
            : ResyncApplyMode.Wipe;

Tres resultados:

• Skip — los digests de contenido ya coinciden. Nada que transferir, nada que aplicar. (Ver el protocolo de cut-over para por qué un digest de contenido, no un conteo de revisiones, es lo que vale la pena comparar.)
• Reconcile (no destructivo) — el nodo local es un subordinado pasivo puro del único activo vivo. Sus revisiones por clave todas vinieron de ese único activo, así que son directamente comparables. La instantánea se fusiona bloqueada-por-revisión: un PutRaw conserva el registro localmente-más-nuevo y rellena las claves faltantes; las tombstones se aplican vía DeleteRaw. Crucialmente, esto preserva las escrituras que la réplica acumuló sobre el canal vivo durante un arranque lento en lugar de tirarlas limpiando primero.
• Wipe (limpieza destructiva + copia) — el nodo local es o fue él mismo un activo para esta partición. Dos nodos independientemente-activos tienen revisiones por clave incomparables: el mismo número de revisión en cada uno se refiere a escrituras distintas. Fusionarlas intercalaría silenciosamente dos historias. Así que el único movimiento seguro es descartar el estado local y adoptar la instantánea autoritativa al por mayor.

El valor por defecto es la copia destructiva segura; Reconcile se desbloquea solo al demostrar que el nodo es un subordinado puramente pasivo. Este es el "wipe-guard": previene el merge peligroso entre dos ex-activos, y simétricamente previene que una limpieza al por mayor descarte buenas escrituras del canal vivo en una réplica simple.

Hay un matiz más codificado en priorReconcileShortfall, y sale directamente de un aborto de certificación de doce horas. Una reconciliación bloqueada-por-revisión puede bloquear fuera registros que debería haber aplicado y completar mientras sigue atrasada respecto a la instantánea autoritativa —un segmento atascado en 12643/15435 a lo largo de 232 sesiones de sincronización, reconciliando los mismos registros fuera de la ventana cada vez, girando para siempre. El flag dice: si una reconciliación anterior se completó pero nos dejó cortos, deja de reconciliar y escala a una limpieza para que la instantánea congelada se adopte entera y realmente converjamos. Solo se establece tras un déficit medido —una réplica adelantada-o-igual nunca lo dispara, así que las escrituras del canal vivo nunca se descartan para perseguir un fantasma.

Paso 4 — el otro lado: un propietario sin certificar aún puede ser una buena fuente​

La recuperación no es solo sobre el nodo que va atrasado. Considera el caso espejo: el nodo A reinicia, y el nodo B —una réplica que ha estado caída— ahora quiere sincronizar desde A. ¿Debería A servir la solicitud mientras A mismo todavía está sin certificar?

La guarda ingenua dice que no: "sin certificar significa que mi almacén está vacío, así que servir sobrescribiría los datos válidos de B con mi hueco". Pero esa premisa es falsa en el momento en que A realmente sostiene la copia autoritativa —lo que ocurre de dos formas: A era un primario preferido que verificó la puesta al día antes de la promoción pero cuya ruta de promoción nunca llamó a CertifyPartition (así que el flag pegajoso quedó atascado en falso mientras los datos están todos ahí), o A tomó la propiedad mediante una recuperación de fallo-total-de-partición y sostiene los datos completos como el activo sin ser nunca estampado IsSynced. En ambos, la copia de A es la fuente de verdad, y rechazar varó la réplica en cero (un volcado: 1.792 solicitudes rechazadas; otro: los 128 segmentos rechazados para toda una partición).

Así que la guarda del lado de la fuente se hace consciente-de-datos:

public static bool ShouldRefuse(
    bool selfIsRuntimeOwnerMapPrimary,
    bool partitionCertified,
    bool segmentSynced,
    bool selfHoldsSegmentData)
    => selfIsRuntimeOwnerMapPrimary && !partitionCertified && !segmentSynced && !selfHoldsSegmentData;

Niégate a servir solo cuando el nodo es el propietario, está sin certificar, y el segmento está a la vez sin sincronizar y no sostiene datos —el único caso genuino de "a mitad de recuperación y realmente vacío" donde servir un hueco podría dejar que el solicitante certifique contra él. Como el receptor aplica cada chunk bloqueado-por-revisión, servir datos reales siempre es seguro; la guarda estrecha el rechazo al único estado donde no hay nada seguro que servir.

Paso 5 — declarar la victoria, exactamente una vez​

Finalmente el activo en recuperación ha extraído cada segmento poseído y ha puesto al día cada uno hasta la cabeza de su fuente. Es autoritativo de nuevo, y necesita decirlo —girar el flag certified pegajoso— para que el disparador de sincronización inversa del Paso 1 deje de re-entregar sus segmentos y el clúster registre la partición como convergida.

public static bool ShouldCertify(
    bool selfIsRuntimeActive,
    bool partitionCertified,
    int ownedSegmentCount,
    int syncedSegmentCount)
    => selfIsRuntimeActive
       && !partitionCertified
       && ownedSegmentCount > 0
       && syncedSegmentCount >= ownedSegmentCount;

La certificación es la completación simétrica del disparador: el disparador encola los segmentos de un activo sin certificar para extraer; esto gira el flag una vez que cada segmento poseído está sincronizado, y la partición se asienta. La ruta de certificación preexistente solo corría para el primario preferido del mapa, así que un activo re-ubicado no-primario extraía todos sus datos correctamente y luego nunca certificaba —re-encolaba la sincronización inversa para siempre, y el clúster nunca se registraba como convergido (una corrida: 30 checkpoints agotando el tiempo ~106 segundos después del inicio, mientras Missing=0 y los conteos nunca divergían —los datos estaban bien, solo faltaba el asentamiento).

Y nota el único atajo que esta política deliberadamente rechaza: no hay ruta de "sin réplica viva, así que certifica mi vacuidad como autoridad" para un activo no-primario. Un activo no-primario no es la autoridad del mapa; certificarlo vacío mientras una réplica temporalmente-caída todavía sostiene los datos dejaría que esa réplica después sincronizara desde este nodo vacío y perdiera todo. El atajo de autoridad-para-estar-vacío pertenece solo al primario preferido del mapa, en su propia ruta de reconciliación. En todos los demás lugares, la vacuidad no gana nada.

La forma del todo​

Da un paso atrás y las cinco políticas son una idea aplicada en cinco lugares: la posesión se demuestra, nunca se asume.

• Un propietario reiniciado está sin certificar, así que extrae en lugar de confiar en su almacén vacío (Paso 1).
• No servirá un segmento hasta que la cabeza de su log de operaciones alcance la de la fuente —una pasada de sincronización terminada no es lo mismo que estar al día (Paso 2).
• Fusiona en lugar de pisotear cuando las revisiones son comparables, y pisotea en lugar de intercalar cuando no lo son (Paso 3).
• Como fuente, sirve siempre que genuinamente sostenga los datos, y rechaza solo cuando está verdaderamente vacío a mitad de recuperación (Paso 4).
• Certifica —gira el flag autoritativo pegajoso— solo ante la prueba de que cada segmento poseído está sincronizado, sin atajo de vacuidad-como-autoridad para un no-primario (Paso 5).

Cada una de estas reglas es un predicado puro y sin E/S —un puñado de booleanos y dos números de revisión de entrada, una decisión de salida— que es por lo que son unit-testables de forma aislada y por lo que cada una pudo fijarse al fallo de certificación exacto que la motivó. Son la vista interna del invariante que la certificación de caos de doce horas demuestra desde fuera: mata un propietario en pleno vuelo, deja que sus réplicas lleven la carga, tráelo de vuelta, y observa cómo Missing=0 se sostiene a lo largo de millones de operaciones confirmadas. La razón por la que el reinicio no pierde una escritura es que al propietario que regresa nunca se le permite ni una sola vez creer en su propia vacuidad. Tiene que ganarse sus datos de vuelta —de las réplicas que los mantuvieron seguros.

Si quieres las piezas en las que esto se apoya: el log de operaciones reproducible es lo que hace de "pon al día mi cabeza con la cabeza de la fuente" una operación real y sin agujeros, y leer tus propias escrituras es la promesa de cara al cliente que la compuerta de servicio del Paso 2 existe para mantener.

La mayor parte de lo que se escribe sobre almacenes distribuidos trata del estado estable —lecturas, escrituras, replicación— o de los fallos dramáticos: un failover cuando muere un propietario, un cut-over cuando se mueve una partición. Pero hay un momento más silencioso que decide si algo de eso funciona: el momento en que el clúster se forma. Antes de poder enrutar una sola clave, los nodos tienen que ponerse de acuerdo sobre quién está en el clúster, quién posee qué porción del espacio de claves y —el paso que la mayoría de los sistemas resuelven mal— si es seguro empezar a servir siquiera.

Este artículo sigue esa secuencia de arranque en el orden en que Zaris realmente la ejecuta: membresía, el mapa de particiones y las compuertas de disponibilidad que se interponen entre "el proceso está en marcha" y "el nodo está aceptando tráfico". También traza una línea, con honestidad, entre lo que Zaris implementa por sí mismo y lo que hereda del runtime de clúster subyacente sobre el que está construido.

Quién está en el clúster: membresía​

Lo primero honesto que hay que decir es dónde está la frontera. El transporte de membresía de bajo nivel —heartbeats entre pares, detección de fallos y elección de líder— lo provee la capa Clustron.Nodus sobre la que está construido Zaris. Zaris la consume a través de una interfaz INodusNode: le pregunta a Nodus quiénes son los miembros, cuál ostenta el liderazgo y recibe notificaciones cuando se pierde o falla el heartbeat de un par. Zaris no reimplementa Raft ni un protocolo de descubrimiento basado en gossip; superpone su propio plano de control de particiones y propiedad sobre esa base.

Lo que Zaris añade es una máquina de estados de membresía explícita que traduce los eventos de heartbeat en bruto a decisiones relevantes para la propiedad. Vive en MembershipStateTracker, y sus estados son deliberadamente más matizados que "arriba / abajo":

Los estados caen en dos grupos, y esa división es todo el objetivo. Alive, Suspected y Unreachable afectan únicamente a la propiedad en tiempo de ejecución —pueden disparar la promoción de una réplica o marcar una partición como temporalmente no disponible, pero nunca mutan el mapa de particiones. Solo Lost, Evicted y Decommissioned hacen que un nodo sea elegible para la regeneración del mapa.

Esa distinción existe porque regenerar el mapa de particiones es caro y, hecho con demasiada prisa, peligroso: puede reorganizar innecesariamente particiones sanas. Así que cuando falla el heartbeat de un nodo, Zaris no reescribe el mapa de inmediato. Mueve el nodo a Unreachable e inicia una ventana de gracia (30 segundos por defecto). Durante esa ventana el clúster solo hace failover en tiempo de ejecución —promover una réplica para que las lecturas y escrituras sigan fluyendo— mientras le da al nodo la oportunidad de volver. Un flapeo, una pausa de GC, un breve corte de red: ninguno de ellos debería reescribir la propiedad. Solo si la ventana de gracia expira el nodo pasa a Lost, y solo cuando un grupo de partición completo ha sido expulsado se dispara la única ruta de regeneración del mapa impulsada por fallo. La regla de diseño, enunciada sin rodeos en el código que la conecta, es: un nodo que se va nunca regenera el mapa por sí solo.

Cómo se encuentran los nodos​

El descubrimiento es basado en roster, no en descubrimiento por gossip. La lista autorizada de nodos es configuración, no algo que el clúster olfatee en tiempo de ejecución. En una configuración escrita a mano es el arreglo nodes —cada entrada declara un id, un host, un puerto de clúster (de pares) y un puerto de cliente. En Kubernetes, ese roster se sintetiza a partir de los ordinales de los pods del StatefulSet en lugar de mantenerse a mano, con el rol de primario preferido de un nodo derivado directamente de su ordinal.

Sí existe un mecanismo de gossip en Zaris, pero cumple una función distinta: es cómo los nodos mantienen convergente su vista del estado del clúster, no cómo descubren que los pares existen. Volveremos a él cuando hablemos de la disponibilidad.

Quién posee qué: el mapa de particiones​

Una vez conocida la membresía, el clúster necesita un plan para el espacio de claves. Ese plan es el mapa de particiones —un único documento versionado contra el que enruta cada nodo.

De una clave a un propietario, en dos saltos​

Una clave no se mapea directamente a una partición. Zaris usa un mapeo de dos niveles que está deliberadamente alineado byte a byte con Redis Cluster para que la misma aritmética de enrutamiento funcione tanto para clientes nativos como para el front-end RESP:

key --CRC16--> slot (0..16383) --proportional--> segment (0..255) --SegmentToPartition[]--> partition

El primer salto hace hash de la clave con CRC16 (CCITT/XMODEM, polinomio 0x1021) módulo 16384 —la función exacta que usa Redis Cluster, incluyendo el respeto a la co-ubicación por hash-tag, donde una clave escrita como user:{42}:profile solo hace hash de la porción dentro de las llaves para que las claves relacionadas caigan juntas. Los 16384 slots se mapean luego proporcionalmente sobre los segmentos del clúster —256 por defecto, fijos durante toda la vida del clúster— y una tabla SegmentToPartition asigna cada segmento a una partición. La partición, finalmente, es lo que tiene propietarios.

¿Por qué la capa adicional de segmentos en lugar de hacer hash directo a particiones? Porque los segmentos son una unidad estable y de grano fino que puedes mover entre particiones cuando el clúster crece o se rebalancea, sin rehashear cada clave. El paso de CRC16 a slot nunca cambia; solo cambia la asignación de segmento a partición.

Qué contiene un mapa de particiones​

El mapa en sí es un PartitionMap —un registro serializado con MessagePack cuya forma te dice con cuánto cuidado se rastrea la propiedad. Los campos que vale la pena conocer:

• Version — un contador monótono que se incrementa en cada cambio del mapa. Este es el número que hace seguro el commit (más abajo).
• TopologyVersion — se incrementa solo ante un cambio estructural real (un nodo o partición que entra o sale, un re-tile), no ante un cut-over de migración rutinario. Separar "cambió la forma" de "cambió un propietario" permite que el resto del sistema reaccione de forma proporcional.
• TotalSegments — 256 por defecto, constante durante toda la vida del clúster.
• Partitions — la lista de asignaciones, cada una con un PrimaryNodeId (el primario de ubicación), ReplicaNodeIds y una PartitionIdentity estable (un GUID acuñado en su nacimiento que sobrevive a la renumeración) más los campos de arrendamiento de propiedad: ActiveOwnerNodeId, un OwnershipGeneration acuñado por el líder y el LeaderTerm que concedió el arrendamiento —que es lo que permite al clúster aislar (fence) a un ex-líder obsoleto para que no autorice propiedad.

Nota la división deliberada entre PrimaryNodeId (dónde el mapa prefiere que viva una partición) y ActiveOwnerNodeId (quién la está sirviendo realmente ahora mismo). Esos pueden diferir durante un failover o una migración, y mantenerlos como campos separados es lo que hace esas transiciones representables sin mentir sobre el plan en estado estable. El artículo sobre el modelo de consistencia explica por qué las lecturas enrutan a ese único propietario activo.

Cómo se planifica el mapa​

El mapa no se arma de forma codiciosa. Lo produce un planificador puro y determinista —DesiredMapPlanner— que toma los ids de los nodos miembros, el conteo de segmentos, un conteo deseado de particiones y el factor de replicación, y devuelve un plan. Dos propiedades merecen mención:

1. Divisiones de segmentos equilibradas y contiguas. Los segmentos se dividen tan uniformemente como sea posible, en tramos contiguos, con las primeras particiones absorbiendo el resto cuando no divide de forma limpia.
2. Ubicación de grupos disjuntos. Los primeros N miembros se convierten en los primarios distintos de partición; los miembros restantes rellenan los espacios de réplica por turnos (round-robin), de modo que ningún nodo termina en dos grupos de partición distintos.

La razón por la que el planificador está escrito como una función pura de sus entradas es ganada con esfuerzo: hace que toda una clase de mapas defectuosos —una partición con un primario duplicado, un rango de segmentos no contiguo, una asignación degenerada— sea irrepresentable por construcción, en lugar de algo que detectas después de los hechos con un validador. Vale la pena ser honestos también sobre la limitación actual: la ubicación hoy es posicional y de grupos disjuntos; una ubicación estilo rendezvous que minimice el churn y mueva la menor cantidad posible de datos en cada regeneración es un refinamiento futuro explícito, no algo que ya se entregue. Lo que sí se entrega es un paso de ubicación pegajosa (sticky) que, en una regeneración por churn de membresía, mantiene en su sitio a un propietario vivo que está sirviendo, para que una partición sana no se mueva sin razón.

Qué significa "commit"​

El mapa lo autoriza un nodo —el líder del plano de control— y nadie más. El líder genera un mapa candidato, lo pasa por una proyección del log de propiedad (el líder es el único escritor del log de propiedad, y el mapa servido es un plegado de ese log), y luego lo confirma localmente antes de avisar a nadie. El commit es una única regla estricta impuesta en TopologyManager.ApplyMap:

// A map is accepted only if it is strictly newer.
if (_currentMap != null && map.Version <= _currentMap.Version)
    return false;

Un mapa con una versión menor o igual a la que ya tienes es rechazado, punto. Solo después de que el líder confirma difunde un MapChangedEvent, envía instantáneas directas del mapa a los pares y publica el cambio de enrutamiento a los clientes. Los seguidores extraen (pull) el mapa (en arranque en frío lo solicitan a pares ya conocidos, reintentando hasta que uno responda) y lo aplican a través de la misma guarda monótona. Como cada nodo solo acepta una versión estrictamente superior, dos nodos nunca pueden asentarse sobre mapas conflictivos de la misma versión —el número de versión es el punto de serialización.

Un matiz honesto de arranque en frío: un nodo sin líder que arranca solo puede acuñar un único mapa provisional de un solo nodo para no quedar paralizado, marcado como provisional y luego reemplazado por el mapa autoritativo multinodo una vez que el clúster se forma. Es una concesión a la disponibilidad, no la ruta de estado estable.

¿Es seguro servir?: disponibilidad condicionada a la convergencia​

Aquí está el paso que separa un almacén en el que puedes confiar de uno que meramente arranca. Tener un proceso en marcha, e incluso tener un mapa, no significa que un nodo deba aceptar tráfico. Si un nodo empieza a servir antes de que su propiedad en tiempo de ejecución se haya puesto al día con el mapa que acaba de aplicar, puede enrutar una solicitud a una partición que en realidad todavía no posee. Zaris se niega a hacer eso, con dos compuertas distintas.

Compuerta uno: estabilidad de la formación del clúster​

La primera compuerta decide cuándo se le permite al líder generar el primer mapa real. ClusterReadinessGate espera a que la membresía sea estable —al menos un número mínimo de nodos presentes de forma continua durante una ventana de duración-estable (3 segundos por defecto)— antes de confirmar un mapa. Esto evita que el líder autorice un mapa contra un clúster a medio formar donde los nodos todavía se están uniendo uno a uno, lo que significaría una regeneración inmediata un segundo después. Si la estabilidad no se alcanza dentro del timeout (30 segundos por defecto), la compuerta fuerza el arranque (force-bootstraps) de todos modos: la disponibilidad gana frente a esperar para siempre. El clúster prefiere arrancar un poco pronto a quedarse atascado.

Compuerta dos: la compuerta de tráfico por nodo​

La segunda compuerta es la que realmente decide si un nodo abre su listener de cliente. ClusterTrafficReadinessGate.IsReady() devuelve verdadero solo cuando se cumplen todas las siguientes condiciones:

• existe un mapa confirmado,
• su tabla segmento-a-partición está completamente poblada (length == TotalSegments),
• existe un mapa de propiedad en tiempo de ejecución,
• runtime.MapVersion == map.Version — la propiedad en tiempo de ejecución del nodo está alineada con la versión exacta del mapa que ha confirmado,
• y cada partición tiene una entrada en tiempo de ejecución.

Esa cuarta condición es el corazón del asunto. Un nodo no se anunciará como listo para servir hasta que su propio mapa confirmado y su propia propiedad en tiempo de ejecución estén en la misma versión. Esto es lo que señala la imagen principal en la parte superior. Hay un respaldo (backstop) de 60 segundos para que un nodo que no puede converger no cuelgue el arranque para siempre —pasado ese punto procede con una advertencia en lugar de quedarse atascado— pero en el caso normal, la compuerta mantiene la puerta cerrada hasta que los dos planos coinciden.

Mantenerse convergente: digests y detectar-y-sanar​

La disponibilidad es una propiedad del momento de arranque; mantenerse convergente es una del estado estable, y aquí es donde el gossip de Zaris realmente se gana el sustento. Cada heartbeat lleva un pequeño ClusterStateDigest —el epoch del nodo, quién cree que es el líder, su versión del mapa, su conteo de nodos y las generaciones de propiedad por partición. Sin RPC adicionales; viaja sobre el tráfico que el clúster ya envía.

Un DigestAccumulator recopila los digests de los pares y, cada pocos segundos, los compara. Si un nodo diverge de la mayoría durante dos ciclos de evaluación consecutivos, levanta una señal de deriva (drift), y un HealingOrchestrator actúa sobre ella —el líder envía directivas correctivas (con un enfriamiento para que no se descontrole), y un nodo que se encuentra como el único atípico se auto-sana re-extrayendo el mapa. Esto es convergencia por detectar-y-reparar, no por una votación de quórum previa al servicio.

Esa distinción importa para la honestidad, así que déjame ser preciso al respecto. En producción, el acuerdo sobre la versión del mapa en todo el clúster se mantiene mediante la compuerta de tráfico por nodo más este bucle de sanación impulsado por digests —no mediante una barrera global que bloquee todo el servicio hasta que cada nodo haya votado sobre una versión. La afirmación más fuerte —que cada instantánea de nodo coincida sobre un líder, un epoch de líder y una versión de mapa— es lo que el arnés de certificación de caos de 12 horas verifica continuamente como un invariante de aprobado/reprobado. La certificación prueba que la propiedad se sostiene; el runtime la logra mediante compuertas y sanación en lugar de una ronda de consenso bloqueante en la ruta de servicio.

Factor de replicación, y un valor por defecto honesto​

Una última pieza de la historia de la formación, porque cambia lo que "listo" significa para tu durabilidad. El factor de replicación por defecto es 1. Con RF=1, cada partición tiene un primario y ninguna réplica —una sola copia. El planificador coloca RF - 1 réplicas por partición, así que en el valor por defecto eso son cero. Un clúster con RF=1 se forma, converge y sirve perfectamente bien, pero la pérdida de un nodo es una pérdida de datos para las particiones que poseía, por diseño, no por accidente. Si quieres que una partición sobreviva al fallo de un nodo, pones RF >= 2, y necesitas suficientes nodos para colocar realmente esas réplicas en máquinas distintas —el artículo sobre dimensionamiento de durabilidad en Kubernetes trabaja exactamente cuántos pods hacen falta. El conteo de particiones tiene un valor por defecto igualmente honesto: si no se establece, el clúster usa una partición por nodo.

La secuencia, de principio a fin​

En conjunto, un clúster de Zaris se forma así:

1. La membresía se resuelve a partir del roster de configuración (o los ordinales de k8s), y Nodus elige un líder del plano de control.
2. El líder espera detrás de la compuerta de formación a tener una membresía estable, luego planifica un mapa con DesiredMapPlanner y lo confirma localmente bajo la estricta guarda de versión monótona.
3. El líder difunde el mapa; los seguidores lo extraen y lo aplican bajo la misma guarda, aceptando solo versiones estrictamente superiores.
4. Cada nodo se mantiene detrás de su compuerta de tráfico hasta que runtime.MapVersion == map.Version y el enrutamiento está completamente poblado —solo entonces abre su listener de cliente.
5. En estado estable, los digests transportados por heartbeat mantienen convergente la vista de cada nodo, con detección de deriva y sanación impulsada por el líder cerrando cualquier brecha.

Ninguno de estos pasos es dramático por sí solo. Juntos son la diferencia entre un clúster que está corriendo y uno que está listo —y la brecha entre esas dos palabras es donde un almacén pierde datos silenciosamente si no se toma la pregunta en serio.

Zaris es el almacén clave-valor distribuido de Clustron. Si quieres ver el plano de control desde el lado del operador, el recorrido en PowerShell crea, arranca e inspecciona un clúster en vivo; y el escalado elástico cubre qué le pasa al mapa cuando añades un servidor a un clúster que ya está sirviendo.

Tarde o temprano alguien hace la pregunta: tenemos un clúster en una región y usuarios en otra —¿no podemos simplemente añadir unos cuantos nodos allá y dejar que un clúster abarque ambas? Es un instinto razonable. Un clúster, un namespace, una cadena de conexión, datos en todas partes. El instinto también es una trampa, y vale la pena ser preciso sobre por qué.

Un clúster de Zaris está diseñado para una red de datacenter. La membresía se rastrea con heartbeats en temporizadores cortos. La propiedad de una partición se mueve entre nodos mediante un handshake que asume que el otro lado responde rápido. El failover aísla a un propietario sospechoso de estar muerto y promueve una réplica en cuestión de segundos. Cada uno de esos mecanismos está calibrado para un enlace donde el viaje de ida y vuelta se mide en microsegundos y un nodo "lento" está genuinamente enfermo —no meramente a ochenta milisegundos y un océano de distancia. Pon la mitad de los nodos al otro lado de una WAN y no habrás construido un clúster geo-distribuido; habrás construido un clúster que ahora confunde la latencia normal de WAN con un fallo, flapea la propiedad y arriesga split-brain la primera vez que el enlace entre regiones tiene un hipo.

Así que la forma correcta no es un clúster estirado. Son dos clústeres independientes —cada uno autocontenido, cada uno con su propia propiedad y failover quedándose enteramente en su propia LAN— unidos por un change feed asíncrono y reanudable. Este artículo trata sobre ese patrón: por qué la independencia es la decisión portante, y cómo el log de operaciones de Zaris ya te entrega lo único que un replicador de WAN realmente necesita —un cursor desde el cual reanudar.

Por qué un clúster estirado es la herramienta equivocada​

Ayuda nombrar las suposiciones específicas que hace un único clúster, porque cada una se rompe de forma distinta sobre una WAN.

• La membresía basada en heartbeats decide que un nodo se ha ido cuando pierde unos pocos latidos. Un enlace entre regiones que añade latencia y la partición ocasional hará saltar ese detector durante la operación saludable. El clúster declarará muertos a nodos vivos.
• El protocolo de propiedad mueve particiones entre nodos con un handshake que espera una respuesta pronta. A través de una WAN, esas transiciones se estancan, reintentan y compiten —exactamente el churn que la maquinaria de propiedad y cutover está diseñada para resolver rápidamente en una LAN.
• Los temporizadores de failover promueven una réplica cuando el propietario parece muerto. Sobre una WAN, "parece muerto" y "solo está lejos" se vuelven indistinguibles, así que obtienes promociones espurias —y si el enlace se sana con una réplica promovida en cada lado, tienes dos propietarios para una partición.

Nada de esto es un defecto. Es un almacén haciendo exactamente lo que un almacén de baja latencia en datacenter debería hacer, aplicado a una red que nunca fue pensado para abarcar. El arreglo no es aflojar cada temporizador hasta que el clúster tolere una WAN —eso también lo haría tolerar fallos reales demasiado lentamente. El arreglo es dejar de pedirle a un clúster que lo haga.

El bloque de construcción que ya tienes: un log reproducible​

Zaris mantiene, por segmento, un log de operaciones ordenado por revisión. Cada escritura aceptada avanza una revisión monótona y añade una entrada. Ese log es el sustrato que las réplicas y los nuevos propietarios de partición usan para ponerse al día sin congelar las escrituras: un consumidor que conoce la última revisión que vio puede reproducir hacia adelante desde ese punto y converger a la verdad actual.

Esa propiedad —reproducir hacia adelante desde una revisión conocida— es el fundamento entero de un replicador de WAN. Un change feed no es más que un lector de larga vida de ese log que transmite entradas en orden de revisión y recuerda dónde se detuvo. Lo que recuerda es un cursor: la revisión más alta que ha aplicado de forma durable, por segmento.

Como el log está ordenado por revisión y la reproducción comienza desde un punto que eliges, el feed tiene los dos rasgos que un enlace de WAN exige:

1. Reanudable. El enlace se caerá —ese es el hecho definitorio de una WAN. Cuando vuelve, el seguidor reconecta y pide todo lo posterior a su cursor almacenado. Sin re-copia completa, sin coordinación, solo "reanudar desde la revisión N".
2. Idempotente en la reproducción. Aplica una entrada solo cuando su revisión es mayor que la última aplicada para ese segmento. Si una reconexión re-entrega la cola, el seguidor omite lo que ya tiene. La entrega duplicada se convierte en un no-op, que es lo que permite que el feed sea al-menos-una-vez en lugar de tener que ser exactamente-una-vez.

El patrón, de principio a fin​

Dos clústeres. Llámalos A (la fuente) y B (el seguidor). Cada uno es un clúster de Zaris ordinario e independiente que no sabe nada de los internos del otro.

En el clúster B ejecutas un seguidor de replicación —un cliente que consume el change feed de A y escribe las operaciones en B localmente. Su estado es diminuto y durable: un cursor por segmento. El bucle es poco glamoroso, que es el punto:

1. Conéctate a A, solicita el change feed para los segmentos (o prefijos de clave) que quieres replicar, empezando después del cursor almacenado de cada segmento.
2. Recibe entradas en orden de revisión. Para cada una, aplica la operación a B —SET, DELETE, expiración— protegida por la comprobación de revisión para que la re-entrega sea inofensiva.
3. Avanza y persiste el cursor a medida que las entradas se aplican de forma durable.
4. Ante cualquier desconexión, vuelve al paso 1. El cursor es donde lo dejaste.

Todo lo que el seguidor necesita para sobrevivir a una interrupción vive en ese cursor. No hay transacción distribuida a través de la WAN, ni membresía compartida, ni quórum entre regiones. Un hipo en el enlace no te cuesta más que un poco de frescura.

Lo que estás negociando: el RPO no es cero, y ese es el trato​

Esta replicación es asíncrona. El seguidor siempre está a cierta distancia por detrás de la fuente —tantas revisiones como se hayan producido en A pero aún no se hayan aplicado en B. Esa distancia es tu Objetivo de Punto de Recuperación (Recovery Point Objective): si la región A desaparece en este instante, pierdes lo que aún no había llegado a B.

Eso no es un defecto por el que disculparse; es el trato que estás eligiendo explícitamente. La alternativa —hacer que las escrituras en A esperen un acuse de recibo de B antes de confirmar— pondría un viaje de ida y vuelta de WAN en tu ruta de escritura y rendiría la baja latencia que es la razón entera por la que ejecutas Zaris. La replicación síncrona entre regiones convierte cada escritura en una solicitud transcontinental. Casi nadie quiere eso en realidad una vez que ven la factura de latencia.

Así que el encuadre honesto es: tú eliges el RPO. Un seguidor bien alimentado sobre un enlace saludable se mantiene dentro de un puñado de revisiones —obsolescencia por debajo del segundo en la práctica. Un enlace saturado o que flapea lo deja derivar más. El cursor hace la deriva acotada y visible —puedes medir exactamente cuánto va B por detrás comparando su cursor con la revisión actual de A— pero no la hace cero. Dimensiona tu tolerancia en consecuencia, y alerta sobre el retraso del cursor igual que alertarías sobre el retraso de una réplica dentro de un clúster.

Cuando la fuente hace failover, al feed no le importa​

Aquí es donde construir sobre el log de operaciones rinde una segunda vez. Dentro del clúster A, la partición que tu feed está leyendo ocasionalmente cambiará de propietario —un nodo muere, una réplica es promovida, una partición migra. El log sobrevive a eso: está indexado por revisión, y un nuevo propietario continúa la misma secuencia de revisión. Para el seguidor, un failover del lado de la fuente es solo otra reconexión. Re-establece el feed contra la topología actual de A y reanuda desde su cursor. Las revisiones que ya aplicó siguen siendo las revisiones que ya aplicó; las que le faltan siguen estando después del cursor. El seguidor nunca tiene que entender quién en A posee la partición —solo qué revisión vio por última vez.

Esta es la razón silenciosa por la que el diseño de cursor-sobre-log vale más que un relé ingenuo de "sigue las escrituras y envíalas". Un relé que transmite escrituras en vivo sin una posición durable e indexada por revisión no tiene nada desde lo cual reanudar cuando la topología de la fuente cambia. El log le da al seguidor un sistema de coordenadas estable que sobrevive a cualquier propietario individual.

El alcance es una elección, y los conflictos son una frontera​

Dos cosas más sobre las que ser deliberado.

Alcance de los datos. No tienes que replicar todo. El feed es por segmento, y puedes seleccionar los segmentos o prefijos de clave que importan —un tenant específico, un dataset específico, la porción que una región de recuperación ante desastres realmente necesita. Replicar menos significa menos tráfico de WAN y un seguidor más pequeño; replicar todo te da un standby cálido completo. Decide a propósito en lugar de por defecto.

Dirección y conflictos. El patrón anterior es unidireccional: A es la fuente de verdad, B es un seguidor / standby mayormente de lectura. Ese es el caso limpio, y no tiene problema de conflictos —hay exactamente un escritor por clave. En el momento en que lo haces bidireccional —ambas regiones aceptando escrituras para las mismas claves— has introducido escritores concurrentes separados por una WAN, y ninguna cantidad de plomería de change feed lo resuelve por ti. Ahora debes una política de resolución de conflictos: last-writer-wins sobre un reloj en el que confíes, propiedad por clave para que las dos regiones nunca escriban la misma clave, o merge a nivel de aplicación. Activo-activo es un diseño real y a veces necesario, pero es una decisión de modelado de datos, no una característica de transporte. Recurre a unidireccional primero; adopta bidireccional solo cuando hayas decidido, explícitamente, cómo se reconcilian dos escritores.

La forma a recordar​

Una WAN no es una LAN lenta; es un medio distinto con las particiones como un evento normal en lugar de una emergencia. Un único clúster, correctamente, se niega a fingir lo contrario —sus temporizadores y su protocolo de propiedad están afinados para tratar un silencio largo como un fallo, porque dentro de un datacenter casi siempre lo es. Así que no estiras el clúster. Ejecutas dos de ellos, cada uno soberano en su propia red, y los unes con la única primitiva que está construida para tolerar un enlace que va y viene: un log ordenado por revisión que puedes reproducir, y un cursor que recuerda dónde estabas.

La independencia es la decisión que hace seguro todo lo demás. El change feed es solo la tubería. El log de operaciones ya te dio el cursor.

Aquí hay un número que reencuadra cómo piensas sobre un almacén clave/valor. Cuando aislamos el almacén en memoria de Zaris y le damos operaciones sin nada más en el camino —sin socket, sin serialización, sin enrutamiento— un solo hilo sirve lecturas a más de un millón por segundo, y escala limpiamente a más de ocho millones a lo largo de ocho hilos. El almacén, en otras palabras, hace el trabajo real de un GET en menos de dos microsegundos, y enfáticamente no es el cuello de botella.

Y sin embargo un GET completo sobre una conexión TCP real, en la misma máquina, se estanca en unos pocos cientos de miles por segundo. El almacén puede hacer el trabajo cinco veces más rápido de lo que el servidor puede entregarlo. Así que la pregunta de rendimiento interesante sobre Zaris no es "¿qué tan rápido es el almacén?". Es lo contrario: ¿a dónde va todo el tiempo entre el socket y el almacén? Este artículo es la respuesta, trazada operación por operación, porque la brecha entre 1,7 microsegundos de lógica y 10 a 13 microsegundos de CPU de servidor por operación no es ruido —es el piso de latencia, y casi todo él es plomería.

La medición que inicia toda la investigación​

No puedes optimizar una ruta que no has separado en capas, así que lo primero que construimos fue un conjunto de benchmarks de ablación —arneses que despojan al sistema hasta una capa a la vez.

• Solo almacén. Llama directamente al almacén en proceso de la partición, en proceso, sin red. Resultado: ~1,15M GET/s y ~0,5M PUT/s por hilo, escalando linealmente a ~8,2M / ~2,0M a ocho hilos.
• Eco de socket puro. Un socket .NET simple haciendo frames de la misma forma, sin lógica de Zaris: ~7,2M frames/s en la misma caja.
• Ruta TCP nativa completa. El cliente real hablando con el servidor real: ~300-324K ops/s, con solo unos tres de catorce núcleos lógicos ocupados en cada lado.

Lee esos tres juntos y dos sospechosos habituales caen de inmediato. El almacén no es el límite —es 3-4x más rápido que la ruta completa. El sistema operativo y el loopback tampoco son el límite —un socket puro mueve frames veinte veces más rápido. Lo que queda en el medio, entre un socket que puede hacer millones y un almacén que puede hacer millones, es la propia plomería de solicitudes de Zaris, y está gastando aproximadamente 10-13 microsegundos de CPU de servidor por operación para envolver unos 1,7 microsegundos de trabajo real.

Esa proporción es el tema. Sigamos un GET a través de ella.

La ruta de un solo GET​

Nada en ese diagrama está mal o es derrochador a primera vista —es la forma honesta de un almacén en red. El costo está en los detalles de cada flecha: cuántas veces tiene que despertar un hilo, cuántas veces se copian los bytes, y cuánto trabajo fijo por solicitud viaja junto que no tiene nada que ver con la clave que se lee. Esos detalles son donde viven los once microsegundos, y se agrupan en tres conjuntos.

Cuello de botella uno: la cadena de saltos de egreso​

El mayor costo individual no es leer el valor —es entregarlo. Enviar una respuesta de vuelta al cliente, tal como está estructurado actualmente, cruza tres canales internos, despierta tres hilos y copia la carga útil cuatro veces en su camino de salida:

1. La respuesta se entrega del shard worker a la ruta de envío del pipeline del servidor.
2. La ruta de envío la entrega a un bucle de escritura por conexión, que la codifica en un buffer agrupado (pooled).
3. El bucle de escritura la encola en la cola de envío de la conexión de transporte.
4. El transporte fusiona (coalesces) los buffers encolados en un stream y escribe al socket.

Cada entrega es un despertar de hilo, y cada despertar es un evento de planificación que el SO tiene que atender —barato individualmente, ruinoso a cientos de miles por segundo. Y en cada etapa los bytes se copian de nuevo: buffer de codificación agrupado, cola de envío, buffer de fusión, socket. En el lado entrante hay un costo equivalente: cada solicitud que llega en un hilo de completación IOCP se entrega a un shard worker antes de que ocurra cualquier trabajo, lo que es otro despertar y otra cola.

La razón por la que existe esta estructura es razonable —desacoplar recepción, despacho, codificación y transmisión hace que cada capa sea más simple de razonar y permite que los consumidores lentos apliquen backpressure sin bloquear el socket. Pero para el caso común —una lectura RF1 cuya respuesta ya está en memoria en el nodo que recibió la solicitud— es enormemente más maquinaria de la que el trabajo merece. La respuesta podría, en principio, computarse y escribirse de vuelta en la propia ruta de recepción, con una copia al buffer del socket y sin entregas en absoluto.

Ese es el primer y mayor trozo de trabajo estructural al que apunta la medición: colapsar el egreso a un salto y una copia para la ruta caliente, y ejecutar la lectura/escritura RF1 en línea en el hilo receptor en lugar de rebotarla a través del pool de workers. Esta es la diferencia entre un diseño que es fácil de dibujar y un diseño que es barato de ejecutar, y los dos no son lo mismo.

Cuello de botella dos: hashing redundante y un lock por solicitud​

El segundo grupo es sobrecarga fija por operación —trabajo que ocurre en cada solicitud sin importar qué clave toque, y que en su mayoría no debería.

CRC16, tres veces, bit a bit. Zaris enruta claves a particiones con un hash CRC16 —la misma familia de hash que usa Redis Cluster, que es cómo el front-end RESP se mantiene compatible con slots. El problema no es la elección del hash; es que la implementación es bit-serial (iterando bit por bit en lugar de usar una tabla de búsqueda) y que un solo GET lo computa tres veces mientras la solicitud pasa por el enrutamiento. A unos 260 nanosegundos por computación, eso son ~784 ns por GET gastados en hashing —más que todo el viaje de ida y vuelta de decodificación-más-codificación de MessagePack, que ronda los 533 ns. Un CRC16 basado en tabla computado una vez y transportado junto convertiría el mayor costo fijo individual en un error de redondeo.

Una comprobación de licencia que toma un lock, en cada solicitud. Más sorprendente: el punto de entrada de la solicitud consulta el servicio de licencias en cada operación individual, y esa consulta toma un lock de todo el proceso y lee el reloj de pared (DateTime.UtcNow) para decidir si el arrendamiento actual sigue siendo válido. Un lock en la ruta caliente es exactamente el tipo de cosa que no aparece en un microbenchmark de un solo hilo y luego serializa silenciosamente todo bajo concurrencia. El veredicto de la licencia cambia como mucho unas pocas veces a lo largo de la vida de un proceso —cuando un arrendamiento se concede, renueva o expira. No tiene por qué recomputarse bajo un lock en cada GET. El arreglo es publicar el veredicto en un único campo volatile que una renovación en segundo plano actualiza, y dejar que la ruta caliente lo lea sin lock y sin llamada al reloj. (La maquinaria de arrendamiento en sí es el tema del artículo sobre el ciclo de vida de licencias; el punto aquí es puramente que leer el veredicto debe ser gratis.)

Ninguno de estos es un problema algorítmico profundo. Son el tipo de costo que se acumula cuando cada pieza se escribe correctamente de forma aislada y nadie ha medido todavía cuánto cuesta la suma en la ruta que corre un millón de veces por segundo.

Cuello de botella tres: el cliente gasta tanto como el servidor​

Sería conveniente culpar al servidor de todo, pero la ablación dice otra cosa: los benchmarks locales están limitados por el cliente (client-bound), y fijar el cliente solo a núcleos de rendimiento lo llevó de 169K a 299K ops/s. El cliente gasta aproximadamente 9 microsegundos y 1,8 KB por GET, y los costos riman con los del servidor:

• Las completaciones rebotan a través del thread pool. Cada solicitud pendiente se rastrea mediante un TaskCompletionSource configurado para ejecutar su continuación de forma asíncrona, así que cuando llega la respuesta la completación se publica al thread pool en lugar de reanudarse en línea —otro salto de planificación, en cada operación.
• Se lee una variable de entorno en cada operación individual. El cliente llama a Environment.GetEnvironmentVariable("ZARIS_REQUEST_TIMEOUT") por solicitud para decidir su deadline. Leer una variable de entorno recorre el bloque de entorno del proceso; hacerlo un millón de veces por segundo es el mayor frame autoría-de-Zaris en el cliente. Debería leerse una vez al arranque y cachearse.
• Un semáforo y un lock de canal por operación, más asignaciones por solicitud —un id de cliente estampado en cada solicitud, metadatos de entrada solicitados y devueltos incluso cuando el llamador no los pidió.

El hilo conductor con el servidor es idéntico: el trabajo de un GET es diminuto, y está rodeado de saltos de planificación, locks y asignaciones que cada uno parecía gratis de forma aislada. La ruta caliente del cliente ya ha empezado a andar por el buen camino —el paso a ValueTask para las operaciones principales eliminó una asignación por llamada en la completación síncrona— y el resto de la lista es la misma idea aplicada más a fondo: cachea la variable de entorno, completa sin el rebote al thread pool, recibe en el socket con un ValueTask, y deja de asignar cosas que nadie pidió.

Entonces, ¿cuál es el piso, realmente?​

Súmalo y la imagen honesta es esta. En un portátil, la ruta TCP nativa tope alrededor de 300K ops/s no porque el almacén sea lento —puede hacer millones— sino porque cada operación arrastra 10-13 microsegundos de CPU de servidor y ~9 microsegundos de CPU de cliente a través de una cadena de saltos, copias, hashes redundantes y locks. El piso lo fija la plomería, no el trabajo.

El corolario alentador es que el piso está hecho de cosas arreglables, y la estimación de lo que arreglarlas compra es concreta. La lista estructural es:

1. Colapsar el egreso a un salto y una copia.
2. Ejecutar la ruta caliente RF1 en línea en el hilo de recepción, o por lotes por recepción.
3. CRC16 basado en tabla, hasheado una vez por operación.
4. Completaciones del cliente con cero asignación y sin rebote al thread pool.
5. Recepción de socket basada en ValueTask en el cliente.
6. Cachear la variable de entorno de timeout de solicitud en lugar de leerla por op.
7. Publicar el veredicto de licencia en un campo volatile —sin lock, sin reloj, en la ruta caliente.
8. Una dieta general de asignaciones: respuestas agrupadas, sin id de cliente por solicitud, sin metadatos no solicitados.

Juntas se estima que llevan la CPU de servidor por operación de ~10 a ~3-4 microsegundos —que es la diferencia entre necesitar una docena de núcleos ocupados para un millón de ops/seg y necesitar unos cuatro.

Las advertencias honestas​

Dos cosas mantienen este artículo veraz en lugar de triunfalista.

Primero, los números absolutos aquí son números de portátil, y probablemente son 2-4x bajos frente a hardware de servidor real con máquinas cliente dedicadas. Lo que se transfiere entre entornos no es el throughput absoluto —es la atribución relativa: el almacén no es el cuello de botella, el egreso es el mayor costo del servidor, y el cliente gasta tanto como el servidor. Esas conclusiones son independientes de la máquina; la cifra final de ops/seg no lo es, y la validación real está a escala en Kubernetes, no en una estación de trabajo.

Segundo, la replicación cambia el techo. Todo lo anterior es la historia de RF1 —una sola copia, el caso rápido. Un PUT RF2 tiene que replicar de forma durable a un backup antes de poder confirmar, y esa es una ruta genuinamente distinta y más cara; un objetivo realista para ella es 400-500K por nodo, no un millón. Y cuando no necesitas viajes de ida y vuelta por operación en absoluto, la ruta por lotes amortiza casi todo este costo fijo a lo largo de muchas operaciones y puede alcanzar un millón por nodo hoy. La cifra de un millón de ops de un solo nodo para operaciones individuales es un objetivo que el trabajo estructural anterior pretende alcanzar —no un número que estemos citando como entregado.

Esa distinción es toda la disciplina del trabajo de rendimiento en el que vale la pena confiar: separar lo que la medición prueba (el almacén es rápido, la plomería es el piso, y aquí es a dónde va cada microsegundo) de lo que promete (un número específico tras una lista específica de cambios). Lo primero está hecho y sólido. Lo segundo es ingeniería que ahora podemos hacer con un mapa en lugar de una conjetura —que es la razón entera por la que instrumentas la ruta antes de tocarla.

Un failover es lo que ocurre cuando un propietario muere —el clúster tiene segundos para elegir a un superviviente y el mapa de particiones nunca se mueve. La migración es la prima más tranquila y más peligrosa: el propietario está perfectamente sano, y quieres mover una partición fuera de él a propósito —para hacer crecer el clúster, para rebalancear, para drenar un nodo que estás a punto de retirar. Nada ha fallado, que es exactamente por qué el listón está más alto. A un failover se le permiten unas pocas escrituras de cola honestamente perdidas en el peor caso; a una migración planificada no. Si mover una partición del nodo A al nodo B puede perder una sola escritura confirmada, la migración no es una característica, es un pasivo.

Este artículo recorre el protocolo de cut-over que Zaris realmente ejecuta, en orden, y dedica la mayor parte de su tiempo al único paso que todos resuelven mal: el momento en que la fuente finalmente queda "libre" para descartar su copia. Ese paso es un arma cargada, y la ingeniería interesante es el seguro que lleva.

La forma del problema​

Una partición es un conjunto de segmentos, y un segmento es un saco de registros clave-valor, cada uno con una revisión monótona. La migración mueve los datos de un segmento de un nodo fuente a un nodo destino y luego gira la propiedad para que los clientes enruten al destino. Todo ello ocurre mientras el segmento está vivo: las lecturas y escrituras siguen llegando todo el tiempo.

Esa vitalidad es el problema. Si haces una instantánea de la fuente, envías los bytes y giras la propiedad, cada escritura que llegó durante el envío está en la fuente y no en el destino —y en el instante en que giras, esas escrituras se desvanecen de la vista enrutada. Las confirmaste; al cliente se le dijo "confirmado"; ahora se han ido. La migración ingenua pierde exactamente las escrituras que ocurrieron mientras estaba ocupada siendo cuidadosa con las que ocurrieron antes.

Así que el protocolo tiene que hacer dos cosas que están en tensión: seguir sirviendo escrituras en la fuente justo hasta el giro, y garantizar que el destino tenga cada una de esas escrituras antes de que el giro surta efecto. La forma en que Zaris reconcilia esa tensión es una secuencia de cinco pasos, cada uno de los cuales se niega a avanzar hasta que el anterior esté demostrablemente completo.

Paso 1 — una instantánea anclada a una revisión, con el piso de recorte fijado​

El destino arranca pidiéndole a la fuente los datos del segmento (SegmentMigrationRequest). La fuente no serializa simplemente su diccionario actual; toma una instantánea anclada a una revisión. Registra la revisión actual del segmento —llámala R— y captura los registros vivos tal como están en R.

Dos sutilezas viven en este único paso. Primero, la fuente arma su log de operaciones antes de capturar el ancla. Zaris puede omitir el log de operaciones para un segmento de primario único (RF1) como optimización de la ruta de escritura; armarlo primero significa que cada escritura desde este punto en adelante se registra, así que una escritura que antes se omitía del log aún tiene una revisión en o por debajo de R y la lleva la propia instantánea. El delta que computamos después —"ops después de R"— es entonces demostrablemente sin agujeros.

Segundo, la fuente fija el piso de recorte de su log de operaciones en R:

var (snapshotRevision, snapshotEntries) = _store.CreateSegmentSnapshot(segmentId);
// Pin BEFORE streaming so any op the source acks between the snapshot and the
// new owner's final-delta request is still replayable — the floor cannot advance past R.
_store.PinSegmentTrim(segmentId, snapshotRevision.Value);

Normalmente el log de operaciones recorta entradas viejas para recuperar memoria. Durante una migración eso sería un desastre: si el piso avanzara más allá de R mientras la transferencia masiva está en vuelo, las escrituras entre R y el giro serían no reproducibles, y el delta final sería silenciosamente parcial. Fijar el piso en R garantiza que esas escrituras sobrevivan hasta que el destino las tenga. La fuente entonces transmite las entradas de la instantánea —y sigue sirviendo lecturas y escrituras todo el tiempo. Sigue siendo el propietario enrutado. Nada se ha movido todavía.

Paso 2 — el destino espera, deliberadamente​

El destino aplica la instantánea masiva y luego hace algo que parece inacción pero es el corazón del diseño: mueve el segmento a un estado de espera-de-cut-over y se detiene. No acusa recibo a la fuente. No reclama propiedad. No le dice al líder que ha terminado. El comentario en el código es contundente sobre por qué:

NO Ack to the source (it is still the routed owner), NO ownership claim, and NO completion notify yet — the completion is withheld until the fenced final delta confirms this node holds everything the source acked.

Este es el contrato "old-owner-authoritative" (propietario-antiguo-autoritativo). Hasta el giro, exactamente un nodo responde por el segmento, y es la fuente. Un destino que se adelantara —empezara a servir desde una instantánea que ya está obsoleta por unos cientos de escrituras— sería un split brain. Así que el destino se mantiene, y pide lo único que le permitirá probar que está al día: el delta final.

Paso 3 — el delta final con escrituras bloqueadas y la prueba por digest​

El destino envía un SegmentMigrationFinalDeltaRequest anclado en R. Aquí es donde la fuente hace la parte cuidadosa.

// Fence FIRST, then capture a revision after the fence — so no acked write can exist beyond it.
var fenceEpoch = _topologyManager.EngageMigrationWriteFence(seg, request.CreationMapVersion);
var fenceRevision = _localStore.GetSegmentCurrentRevision(seg);

Engancha un bloqueo de escritura (write fence) en el segmento y luego lee la revisión actual. El orden importa: bloquear primero, medir después, para que no haya ventana en la que una escritura se cuele más allá de la medición. Luego lee cada entrada del log de operaciones después de R —el delta de todo lo que llegó durante la transferencia masiva— y computa un digest de contenido del estado vivo del segmento. Ese digest es la clave de todo el protocolo, así que la fuente lo registra como la prueba de cut-over:

response.Operations = finalOps.ToList();
response.SourceDigest = _localStore.ComputeSegmentLiveDigest(seg);
// Record this served digest as the cut-over PROOF: the post-cut-over orphan drop will refuse to
// destroy this segment's data unless its live digest still equals this exact value.
_localStore.RecordCutoverProofDigest(seg, response.SourceDigest);

Hay un modo de fallo honesto conectado justo aquí. Si el piso de recorte sí avanzara de algún modo más allá de R —una fijación perdida o retrocedida— entonces "ops después de R" estaría incompleto, y enviar ese delta descartaría silenciosamente escrituras confirmadas. La fuente se niega:

if (!_localStore.TryGetSegmentOperationsAfter(seg, request.SnapshotRevision, out var finalOps))
{
    response.Aborted = true;
    response.AbortReason = "FinalDeltaBelowTrimFloor";
    // release the fence, re-snapshot, retry — a loud abort, never a silent partial cut-over.
}

Un aborto por-debajo-del-piso no es una pérdida; derriba y re-instantánea desde un ancla fresca. La regla que el código sostiene es aborto ruidoso antes que parcial silencioso —la migración prefiere reiniciar a girar sobre un delta incompleto.

Paso 4 — la compuerta: el destino prueba que domina​

El destino aplica el delta, luego recomputa su propio digest de contenido del segmento y lo compara con el de la fuente:

var localDigest = _localStore.ComputeSegmentLiveDigest(seg);
var matchesSource = string.Equals(localDigest, response.SourceDigest, StringComparison.Ordinal);

Si los dos digests son iguales, el destino tiene byte a byte lo que la fuente tenía en el bloqueo —el estado del destino es un superconjunto de cada escritura que la fuente confirmó. Si difieren, casi siempre es porque la instantánea transmitida todavía se está aplicando cuando se computa el primer delta (la señal de completación puede adelantarse a los lotes de datos encolados), así que el destino se mantiene pendiente y deja que un reintento espaciado re-solicite el delta en lugar de girar en vano. Un desajuste nunca gira. El giro está condicionado a una prueba positiva de igualdad, no a la ausencia de un error.

Hay una cosa más que el destino hace antes de declarar la victoria, y es una garantía que la mayoría de las implementaciones de migración omiten. La fuente no es la única copia que podría ir por delante —una réplica del segmento podría tener una escritura que la fuente bloqueada se perdió. Así que antes de completar, el destino pliega la cola de solo lectura de cada réplica viva:

The flip may fire only when the new owner's digest dominates the source and every live replica of the segment.

El plegado preserva las revisiones: los registros más viejos de una réplica rezagada son ignorados por la compuerta de revisión, y una réplica adelantada aporta exactamente la escritura que la fuente no tenía. Solo cuando el destino domina a la fuente y a cada réplica viva avanza. Este es el invariante "durabilidad antes que propiedad" —la propiedad es una recompensa por la posesión demostrable, no una precondición para ella.

Paso 5 — el giro, y el descarte que casi pierde tus datos​

Ahora el destino le dice al líder que ha terminado (SegmentMigrationCompletionNotify). El líder valida la completación contra el override de migración vivo y arma una regeneración atómica de cut-over del mapa de particiones —un único cambio de mapa versionado que gira el propietario del segmento al destino y elimina el override de migración. Después de que ese mapa se aplica, el destino es el propietario enrutado. Los clientes enrutan a él. El movimiento está, en lo que respecta al clúster, hecho.

Y la fuente, ahora sosteniendo un segmento para el que ya no posee un rol, ejecuta un barrido de limpieza para descartar la copia huérfana y recuperar la memoria. Esta es el arma cargada.

Aquí está la trampa, y es lo bastante sutil como para haber sobrevivido a una corrida de certificación antes de ser atrapada (Missing=8629 claves confirmadas desaparecidas). Un bloqueo de escritura reduce la confirmación de escrituras pero, en un segmento de copia única bajo carga, no lo aquieta perfectamente a cero de forma instantánea. Así que esta secuencia es posible:

1. La fuente sirve el digest del delta final como la prueba. El destino lo iguala y gira.
2. En la rendija entre servir la prueba y el aterrizaje del giro, se confirma una escritura más en la fuente.
3. El destino nunca recibió esa escritura —la prueba que igualó era de antes de ella.
4. La fuente, ahora huérfana, descarta su copia para recuperar espacio.
5. Esa última escritura existía solo en la fuente. Se ha ido. A un cliente se le dijo que se confirmó.

El arreglo es hacer el descarte condicional a que la prueba siga siendo verdadera. La fuente no destruye ciegamente un segmento huérfano. Compara el digest vivo actual del segmento con el digest que registró como la prueba de cut-over, y solo destruye los datos si siguen coincidiendo:

public static bool ShouldRetainAfterCutover(bool hasCutoverProof, string? currentLiveDigest, string? proofDigest)
{
    if (!hasCutoverProof || string.IsNullOrEmpty(proofDigest))
        return false; // not a proof-carrying cut-over segment -> this policy does not intervene
    return !string.Equals(currentLiveDigest, proofDigest, System.StringComparison.Ordinal);
}

Si una escritura llegó después de la prueba, el digest actual difiere del digest de la prueba, ShouldRetainAfterCutover devuelve true, y la fuente conserva su copia:

if (CutoverDropSafetyPolicy.ShouldRetainAfterCutover(hasProof, currentDigest, proofDigest))
{
    Log.CutoverDropRetainedUnprovenTail(_logger, store.Count, segmentId);
    continue; // keep the store — a post-proof tail exists that the new owner has not received
}

La asimetría es todo el punto. La retención siempre es segura: la fuente ya no es el propietario enrutado, así que una copia conservada es un huérfano redundante y no servido —nunca puede causar un split brain, solo cuesta un poco de memoria hasta que un re-servicio re-entrega la cola al nuevo propietario y un barrido posterior, al encontrar que los digests coinciden de nuevo, la descarta limpiamente. La destrucción sobre una prueba obsoleta nunca es segura: es la única operación que puede borrar permanentemente una escritura confirmada. Así que la política es deliberadamente estrecha —solo anula un descarte que de otro modo ocurriría, y solo para un segmento que lleva una prueba registrada cuyo digest ya no coincide. Los segmentos sin prueba (una expulsión, un giro inmediato, un segmento nunca migrado) conservan su comportamiento existente intacto. La compuerta añade una retención; nunca añade un descarte.

¿Por qué el digest, y no un número de revisión?​

Podrías preguntar por qué la prueba es un digest de contenido y no simplemente "la revisión más alta que el destino confirmó". La respuesta es que un número de revisión te dice qué tan lejos llegó el destino, pero un digest te dice si lo que obtuvo es lo que tú tenías. Los dos pueden divergir en las costuras —un plegado de réplica, un reintento re-anclado, una instantánea aún drenándose— y la única pregunta que mantiene los datos seguros es la pregunta de contenido: ¿tiene el nuevo propietario exactamente esto? Un digest responde eso directamente. Una marca de agua solo responde un proxy de ello, y los proxies son donde las escrituras confirmadas van a morir.

Qué compra esto, honestamente​

Enunciado sin rodeos, la garantía es: una migración planificada de partición no pierde una escritura confirmada. Cada escritura que la fuente confirmó antes del bloqueo está en la instantánea o el delta; cada escritura que confirmó después de la prueba mantiene viva la copia de la fuente hasta que el nuevo propietario también la tenga. El protocolo abortará y reiniciará ruidosamente en lugar de girar sobre un delta incompleto, y pliega las réplicas vivas para que el nuevo propietario domine cada copia, no solo la fuente.

Lo que no es, es gratis. El delta final bloqueado es un viaje de ida y vuelta síncrono que brevemente bloquea las escrituras en el segmento que se está traspasando —una pausa corta y acotada en un segmento, no la partición y no el clúster. Una migración que no puede converger (un piso de recorte que sigue avanzando, una cola de réplica que no puede expresarse desde su log) re-instantánea y reintenta en lugar de forzar el progreso, lo que bajo churn patológico significa que una migración tarda más en lugar de tomar un atajo a través de tus datos. Esos son los compromisos correctos para una operación planificada: un movimiento que elegiste hacer nunca debería ser la razón por la que una escritura confirmada desaparece.

Esta es la misma columna vertebral que la certificación de caos de doce horas ejercita desde el exterior —detén un nodo a mitad de migración, agita el mapa, y observa cómo las escrituras confirmadas sobreviven. Este artículo es la vista interna de una de las costuras que esa corrida demuestra cerradas: el momento en que una partición cambia de manos, y el seguro del gatillo que evita que el traspaso se coma las mismísimas escrituras que fue construido para proteger. Se apoya en otras dos piezas que vale la pena leer por su cuenta —el log de operaciones reproducible que hace de "ops después de la revisión R" una consulta real y sin agujeros, y el escalado elástico que es la razón más común por la que una partición necesita moverse siquiera.

Un GET de clave única es fácil de razonar: haz hash de la clave, encuentra su propietario, pregunta a ese único nodo. SCAN es el tipo de operación opuesto. No tiene clave —hace una pregunta sobre todo el espacio de claves: dame cada clave en este rango, una página a la vez. Y en un almacén particionado y replicado ese espacio de claves no es una sola cosa en un solo lugar. Está dividido en 256 segmentos repartidos sobre cuantos nodos ejecutes, cada nodo sosteniendo solo las porciones que posee actualmente, y todo el conjunto se está escribiendo mientras iteras. No hay índice ordenado global que recorrer. Entonces, ¿de dónde viene el orden, a qué apunta exactamente un token de reanudación, y qué le pasa a tu escaneo cuando una clave se escribe —o una partición se mueve— a mitad de camino?

Este artículo sigue un SCAN a través de las tres capas que realmente lo sirven: un solo segmento, un solo nodo, y el cliente que cose los nodos entre sí. Cada capa resuelve una pieza del problema, y los límites honestos de la operación caen de cómo esas piezas encajan.

La solicitud: un rango y un tamaño de página, no una clave​

Un escaneo se describe con dos objetos pequeños. Un KeyRange dice qué claves —un inicio, un fin o un prefijo, cualquiera de ellos opcional:

public sealed class KeyRange
{
    public string? Start  { get; set; }
    public string? End    { get; set; }
    public string? Prefix { get; set; }
}

Y ScanOptions dice cómo entregarlas —qué tan grande una página, si enviar valores o solo claves, un límite duro opcional, y un token de reanudación para continuar una llamada previa:

public sealed class ScanOptions
{
    public int     PageSize       { get; set; } = 100;
    public bool    IncludeValues  { get; set; } = true;
    public bool    IncludeMetadata{ get; set; } = false;
    public string? ResumeToken    { get; set; }
    public int?    LimitCount     { get; set; }
}

Nada aquí nombra un nodo o un segmento. Ese es el punto: el llamador describe lo que quiere, y las tres capas de abajo calculan dónde vive y en qué orden entregarlo.

Capa uno: un segmento se escanea a sí mismo, sin locks y en orden​

La unidad más pequeña que puede responder parte de un escaneo es un segmento —la unidad de almacenamiento particionado de Zaris, respaldada por un ConcurrentDictionary de registros vivos. Un diccionario no tiene orden, así que lo primero que un escaneo de segmento necesita es una vista ordenada de sus claves. Construir eso en cada página sería ruinoso, así que cada segmento mantiene una instantánea de claves ordenadas, cacheada e inmutable y la reconstruye solo cuando el conjunto de claves cambia:

// No lock held during scan — the snapshot is immutable once built.
var sortedKeys = GetOrBuildSortedKeys();

int startIdx = BinarySearchKey(sortedKeys, startKey, StringComparer.Ordinal);
if (startIdx < 0) startIdx = ~startIdx;

El arreglo se asigna una vez y nunca se muta; una reconstrucción concurrente simplemente produce un nuevo arreglo e intercambia la referencia. Eso significa que el recorrido del escaneo en sí no toma ningún lock en absoluto —hace búsqueda binaria hasta la clave de inicio y avanza en orden ordinal, leyendo registros vivos del diccionario concurrente a medida que avanza. Las lecturas y escrituras al segmento nunca bloquean el escaneo, y el escaneo nunca las bloquea a ellas.

Dos tipos de clave se pasan por alto silenciosamente mientras avanza:

if (!_data.TryGetValue(key, out var record)) continue;        // vanished since snapshot
if (record.IsDeleted || ExpirationManager.IsExpired(record, now)) continue;  // tombstone / TTL

Una clave eliminada es una tombstone (lápida) —un registro real marcado como IsDeleted, porque una eliminación tiene que ser un registro, no una ausencia, para que la replicación la lleve. El escaneo las filtra, junto con las claves cuyo TTL ha transcurrido pero cuyo barredor (sweeper) todavía no se ha disparado. Así que la instantánea de claves ordenadas es un superconjunto de lo que verás; la expiración y la eliminación se resuelven contra el registro vivo en el momento de lectura, no se congelan en la instantánea.

El recorrido se detiene en PageSize y devuelve un ResumeToken. Aquí está el primer detalle honesto: a nivel de segmento, el token es esencialmente un offset —un conteo de cuántas entradas coincidentes ya se devolvieron (ReturnedSoFar). Un escaneo de segmento reanudado vuelve a hacer búsqueda binaria hasta la misma clave de inicio y omite esa cantidad de coincidencias antes de emitir. Es una posición-por-conteo, no una búsqueda de posición-por-clave.

cursor.ReturnedSoFar += taken;
bool hasMore = results.Count >= pageSize && cursor.ReturnedSoFar < totalLimit;

Esa elección importa para lo que la operación promete, y volveremos a ella.

Capa dos: un nodo fusiona sus segmentos en un único stream ordenado​

Un nodo posee muchos segmentos —no los 256, solo los mapeados a las particiones que sirve actualmente. Un escaneo a nivel de nodo tiene que presentar todos ellos como un único resultado ordenado, porque el llamador preguntó por un rango, no por el segmento 42. Este es un problema clásico de fusión: cada segmento puede producir sus claves en orden ordenado, y quieres la unión ordenada.

Así que la primera página de un escaneo de nodo hace exactamente eso. Reúne un fetcher para cada segmento poseído localmente y ejecuta una fusión k-vías sobre ellos con una cola de prioridad, comparando claves ordinalmente:

var heap = new PriorityQueue<(KvResult<ZarisEntry> Item, int Source), KvResult<ZarisEntry>>(comparison);
// seed with the head of each segment, then repeatedly pop the smallest
// key and pull the next from that segment's enumerator

El resultado fusionado y ordenado se materializa en un buffer sostenido por un RouterQueryCoordinator —una sesión del lado del servidor de corta vida registrada bajo un QueryId recién acuñado:

coord = new RouterQueryCoordinator();
await coord.InitScanAsync(fetchers, ct);     // drains + merges every owned segment
var id = _coordManager.Register(coord);
cursor = new QueryCursor { QueryId = id, ReturnedSoFar = 0 };

Cada página subsiguiente es solo una porción de ese buffer, y el token de reanudación del nodo lleva el QueryId para que la siguiente llamada encuentre la misma sesión:

if (!string.IsNullOrEmpty(options?.ResumeToken))
{
    cursor = QueryCursor.Deserialize(options.ResumeToken);
    if (!_coordManager.TryGet(cursor.QueryId, out coord))
        throw new InvalidOperationException($"Search session {cursor.QueryId} not found (expired or cleaned).");
}

Este es el segundo detalle honesto, y es un compromiso real. Un escaneo a nivel de nodo es con estado (stateful): la paginación es estable y el orden por nodo es exacto, pero el precio es que el nodo materializa todo su espacio de claves poseído y fusionado en un buffer cuando el escaneo comienza, y sostiene una sesión durante toda la vida de la iteración. Los escaneos son una herramienta administrativa y de iteración masiva, no un cursor de streaming de memoria constante sobre miles de millones de claves —y un token de reanudación solo es válido contra el nodo y la sesión que lo acuñaron. Deja que esa sesión expire, o intenta reanudarla en otro lugar, y obtienes un ruidoso "session not found" en lugar de una respuesta silenciosamente errónea.

Capa tres: el cliente hace fan-out e intercala a los propietarios​

Un nodo responde por los segmentos que posee. Un escaneo de clúster tiene que cubrir a cada propietario, así que el ScanClusterClient del lado del cliente abre un escaneo contra cada nodo en paralelo e intercala sus páginas a medida que llegan, en lugar de drenar un nodo antes de empezar el siguiente:

var enumerators = clients
    .Select(c => c.Scan.ScanAsync(range, options, ct).GetAsyncEnumerator(ct))
    .ToList();

// advance all owners concurrently; yield whichever produces next
var finishedTask = await Task.WhenAny(pending.Select(p => p.Task));

Ese paralelismo es por qué LimitCount necesita cuidado. Cada nodo trata el límite como un tope por nodo; si el cliente no lo impusiera también, un LimitCount de 1.000 contra cuatro propietarios podría devolver hasta 4.000 filas una vez fusionadas. Así que la capa de clúster aplica el límite como un tope total duro y deja de entregar una vez que se alcanza —mientras sigue drenando la página en vuelo de cada propietario hasta completarla, porque desechar un enumerador asíncrono a mitad de movimiento no está permitido y los resultados por nodo ya están acotados de todos modos:

if (emitted < limit)
{
    yield return enumerator.Current;
    emitted++;
}
// keep draining siblings even past the cap; do not yield-break mid-move

La consecuencia a dejar clara: dentro de la contribución de cualquier nodo, las claves llegan en orden; entre nodos se intercalan por llegada, así que un escaneo de clúster completo no está ordenado globalmente a menos que lo pidas explícitamente. (La ruta relacionada Search sí lleva SortFields y fusiona con un comparador exactamente por esa razón.) Si necesitas cada clave del clúster en orden ordinal, ordena el resultado ensamblado; SCAN en sí garantiza el orden por propietario y la completitud, no un orden global.

Qué promete —y qué no promete— un SCAN​

Junta las tres capas y el contrato real de la operación es visible, sin que nada de él esté oculto:

• No es una instantánea puntual del clúster. Cada nodo materializa su propio buffer fusionado cuando su escaneo comienza, y esos momentos no coinciden. Las escrituras que llegan a un nodo antes de que su buffer se construya se incluyen; las posteriores no. No hay congelación de todo el clúster.
• Las claves eliminadas y expiradas nunca aparecen. Las tombstones y los registros con TTL transcurrido se filtran contra el registro vivo a medida que se recorre el segmento, así que un escaneo refleja el contenido lógico, no el físico.
• La reanudación es posición-por-conteo dentro de una sesión. Como el cursor por segmento es un offset, una clave insertada o eliminada antes de la posición actual entre dos páginas puede desplazar la frontera —un escaneo concurrente con mutación intensa del rango escaneado puede, en principio, repetir u omitir una clave alrededor de la costura. Un escaneo de un rango inactivo es exacto. Esta es la misma familia de garantía que da SCAN de Redis —una iteración completa de mejor esfuerzo, no un nivel de aislamiento de instantánea— y es el compromiso correcto para un almacén no ordenado y escrito concurrentemente.
• El espacio de claves puede moverse bajo tus pies. El cliente hace fan-out a los propietarios que existen cuando el escaneo comienza. Las particiones pueden migrar o hacer failover a mitad de iteración; un escaneo es un barrido de mejor esfuerzo de un clúster vivo, que es por qué es la herramienta para exportación masiva, reindexación y consultas administrativas en lugar de para lecturas transaccionales. Para read-your-writes sobre una sola clave, enruta al propietario en su lugar.

Ninguno de estos es un bug que empapelar; son la forma honesta de iterar un espacio de claves no ordenado, fragmentado y mutante sin detener el mundo. El diseño hace que el caso barato y común sea rápido —una instantánea ordenada sin locks y una fusión por nodo— y es explícito sobre los bordes.

Una nota sobre el front-end RESP​

Los clientes de Redis alcanzan la misma maquinaria a través de KEYS y SCAN en el front-end RESP, que se mapean sobre el escaneo nativo. Una advertencia que vale la pena declarar sin rodeos: el SCAN de RESP hoy es de un solo disparo —drena el escaneo nativo y responde con el cursor 0 (iteración completa) en un viaje de ida y vuelta, en lugar de enhebrar el cursor incremental de Redis a través de cada llamada. Es honesto sobre la completitud, no todavía incremental. El cliente nativo es el que pagina con un token de reanudación.

Una operación, tres capas honestas​

Un GET toca un propietario y una clave; un SCAN toca a cada propietario y pide a cada uno que produzca su porción de un todo ordenado. El trabajo se divide limpiamente: un segmento convierte un diccionario no ordenado en un recorrido ordenado y sin locks; un nodo fusiona sus segmentos en un único stream ordenado y paginado de forma estable detrás de un cursor de sesión; el cliente hace fan-out entre propietarios, intercala sus páginas, e impone el único tope que el fan-out de otro modo rompería. Cada capa es simple por sí sola, y las garantías de la operación —orden por propietario, completitud sobre un rango inactivo, sin aislamiento de instantánea, sin congelación global— son exactamente lo que esas tres capas simples pueden entregar honestamente juntas.

Aquí hay una pregunta que suena simple y no lo es: ¿qué ocurre cuando un almacén en memoria se queda sin memoria?

La respuesta ingenua es "se cae" —el proceso trepa hasta que el sistema operativo lo mata. La respuesta un poco menos ingenua es "rechaza escrituras". Zaris no hace ninguna de las dos por defecto. Un nodo de Zaris es un almacén en memoria, pero deliberadamente no es uno ilimitado: cada nodo es un buffer acotado con un techo duro, y cuando los datos que posee se acercan a ese techo el nodo expulsa sus datos más fríos para hacer espacio. Las escrituras siguen teniendo éxito; el límite se sostiene; el proceso no se hincha. El nodo se comporta como una caché, porque por debajo, lo es.

Cada nodo es un buffer acotado​

Un nodo de Zaris no crece sin límite. Cada nodo contabiliza continuamente el tamaño de los datos que posee activamente y mantiene ese total corriente por debajo de un techo configurado. La contabilidad nunca es opcional —un nodo es siempre un buffer acotado. Lo único que configuras es qué tan grande es el techo y, en principio, qué hace el nodo cuando lo alcanza.

El techo por defecto es 1 GiB de datos poseídos activamente por nodo. No hay, por diseño, un ajuste "ilimitado". Si no estableces un techo, obtienes el valor por defecto —nunca obtienes accidentalmente el infinito.

Una sutileza importa para cómo razonas sobre la huella de un clúster: el techo cubre los datos que un nodo posee activamente —las copias primarias que sirve a los clientes. Las copias de réplica que un nodo sostiene para otras particiones se rastrean por separado y no cuentan contra el techo de propietario activo. Así que la memoria residente real de un nodo es su working set poseído más cualesquiera copias de réplica que lleve para sus pares; el techo gobierna lo primero, no la suma.

Dos formas de mantener la línea​

Hay exactamente dos cosas que un buffer acotado puede hacer cuando una escritura lo empujaría más allá de su techo: descartar algo viejo para hacer espacio, o rechazar la nueva escritura.

Con la expulsión activada, un nodo es una caché: bajo presión descarta los datos menos valiosos para que las escrituras sigan fluyendo. Con la expulsión desactivada, es un almacén de rechazo-en-capacidad que protege los datos existentes rechazando las nuevas escrituras.

Aquí está la parte honesta. En la versión actual un nodo siempre se ejecuta con la expulsión habilitada, usando la política LRU. El modo sin-expulsión y las políticas alternativas (LFU, consciente de TTL) existen en el motor, pero todavía no son seleccionables mediante configuración. La consecuencia práctica es que CapacityExceeded —el estado de rechazo-en-capacidad— es esencialmente inalcanzable hoy: un nodo lleno expulsa en lugar de rechazar. Es un estado real y tipado contra el que puedes escribir código, pero bajo la política LRU siempre activa normalmente no lo verás. La única perilla de memoria que realmente controlas ahora mismo es el tamaño del propio techo, memory.maxSizeBytes.

La corrida de expulsión monta una banda tranquila​

La ingeniería interesante no es que un nodo expulse —es cómo, porque un diseño ingenuo de "expulsar en cada escritura una vez que estás lleno" se descontrola miserablemente. Imagina un nodo sentado exactamente en su techo: cada escritura entrante dispararía una expulsión para hacer espacio para sí misma, y pagarías ese costo en la ruta caliente para siempre.

Zaris evita eso con dos movimientos. Primero, la expulsión la impulsa un bucle en segundo plano, no la escritura individual —la escritura que empuja a un nodo por encima del borde se admite, y el bucle recupera espacio poco después, fuera de la ruta de solicitud. Segundo, el bucle usa histéresis: un disparador alto y un objetivo más bajo, de modo que recupera en ráfagas y luego se queda tranquilo en lugar de dispararse continuamente en el borde.

• Disparador: una corrida comienza cuando el uso activo sube por encima del 80% del techo.
• Objetivo: una vez iniciada, la corrida sigue expulsando hasta que aproximadamente el 30% del techo esté libre de nuevo —hasta que el uso caiga de vuelta a alrededor del 70%.
• Cadencia: el bucle despierta en un intervalo fijo (un segundo por defecto) y muestrea un conjunto acotado de ítems candidatos cada ciclo.

Como el objetivo post-expulsión (70%) se sitúa estrictamente por debajo del disparador (80%), cada corrida deja caer el uso a una banda tranquila en lugar de detenerse justo en el punto que la re-dispararía de inmediato. Ese es el diente de sierra de la imagen principal: el uso trepa al 80%, una corrida lo limpia de vuelta al 70%, y trepa de nuevo —nunca presionado contra el techo, nunca descontrolándose con una expulsión por escritura.

La política de expulsión en sí es LRU —least recently used (menos usado recientemente)— y es muestreada, no estricta. En lugar de mantener una lista ordenada globalmente de cada clave (que costaría memoria y contención de locks en la ruta caliente), Zaris estampa señales aproximadas de recencia en el lugar, en la ruta de lectura y, cuando una corrida se dispara, muestrea un pequeño conjunto de candidatos y descarta los de menor puntuación. Es el mismo enfoque muestreado que usa Redis, y el mismo compromiso: renuncias al orden perfecto de "expulsar la única clave más vieja" a cambio de una expulsión que cuesta casi nada mantener y nunca necesita un índice separado.

El otro techo: tamaño por ítem​

El techo de memoria general es un límite sobre el total. Hay un segundo límite independiente sobre cualquier ítem individual: por defecto un valor no puede exceder 4 MiB. Esto se comprueba en cada escritura sin importar el modo de expulsión, y es donde una escritura alcanza un rechazo genuinamente alcanzable.

La distinción importa porque los dos fallos significan cosas opuestas y quieren respuestas opuestas:

var result = await client.PutAsync("report:2026-07", payload);

if (!result.IsSuccess)
{
    switch (result.Status)
    {
        case KvStatus.ItemTooLarge:
            // This one value is too big. No amount of eviction helps —
            // split it, or store a reference to it elsewhere.
            break;

        case KvStatus.CapacityExceeded:
            // The node is full and eviction is disabled (not the default).
            // Retry later or shed load.
            break;
    }
}

ItemTooLarge es un resultado vivo y alcanzable en todos los modos —la expulsión no puede hacer espacio para un valor que está por encima del tope por ítem, porque el tope no es sobre espacio libre, es sobre un valor patológico. CapacityExceeded, como se cubrió arriba, solo aparece en el modo sin-expulsión que todavía no puedes seleccionar. Tratarlos idénticamente es un bug esperando a ocurrir: reintentar una escritura ItemTooLarge para siempre nunca tendrá éxito.

Un matiz relacionado vive en la frontera entre este tope por ítem y el runtime de .NET: los valores de aproximadamente 85.000 bytes en adelante aterrizan en el Large Object Heap, así que subir maxItemSizeBytes para admitir valores grandes es una decisión deliberada con consecuencias de GC, no un dial gratuito. Si estás actualizando en caliente valores grandes y planos, trocearlos en piezas sub-LOH es el mecanismo que evita que el LOH se agite —una característica separada con sus propios compromisos, que desglosamos en Almacenar objetos grandes sin agitar el heap.

Qué configuras, y qué no​

El techo de memoria vive en la configuración del almacén bajo la sección memory:

{
  "memory": {
    "maxSizeBytes": 2147483648
  }
}

Eso son 2 GiB. Establece maxSizeBytes en null, o déjalo fuera, y obtienes el valor por defecto de 1 GiB. En la versión actual este es el ajuste de memoria que controlas —la política LRU, los umbrales de histéresis del 80%/70%, y la cadencia de 1 segundo son valores por defecto fijos, no perillas. Vale la pena tener claro esto: los artículos del blog y el motor describen un espacio de políticas más rico del que la superficie de configuración expone actualmente, y este artículo describe lo que realmente puedes establecer hoy.

Qué significa para dimensionar un clúster​

Como cada nodo es un buffer acotado, la capacidad total de un almacén es aproximadamente el techo por nodo multiplicado por el número de particiones que un nodo posee, ajustado por el factor de replicación (las réplicas sostienen copias adicionales que viven fuera del techo de propietario activo). Dos consecuencias prácticas se desprenden de eso:

• Dimensiona el techo a tu working set más margen de expulsión, no a tus datos totales. Un nodo ejecuta una caché LRU siempre activa hoy, así que los datos fríos se descartan bajo presión en lugar de rechazarse. Si tu working set cabe por debajo de ~70% del techo con espacio para que la banda respire, la expulsión se mantiene tranquila y el conjunto caliente permanece residente. Si dimensionas el techo por debajo de tu working set, has construido una caché que está constantemente expulsando datos que está a punto de necesitar de nuevo —correcto, pero lento, y el diente de sierra se convierte en una trituración.
• No olvides la huella de las réplicas. El techo gobierna los datos poseídos, pero la RAM real de un nodo son los datos poseídos más las copias de réplica. Cuando aprovisionas memoria por pod o por máquina, presupuesta para ambos, o un nodo dimensionado "a su techo" aún correrá más caliente de lo que el techo implica.

Para la aritmética de capacidad en el contexto de particiones, factor de replicación y conteos de pods, Dimensionar un clúster de Zaris para durabilidad en Kubernetes recorre el cálculo completo.

La conclusión​

Un almacén en memoria que crece sin límite no es una característica —es una interrupción esperando un pico de tráfico. Zaris trata cada nodo como un buffer acotado con un techo real (1 GiB por defecto, sin opción ilimitada), una caché LRU muestreada siempre activa por debajo, y una banda de histéresis que recupera espacio en ráfagas tranquilas en lugar de descontrolarse con una expulsión por escritura en el borde. El techo total y el tope por ítem son dos límites distintos con dos estados tipados distintos, y el que realmente es alcanzable hoy —ItemTooLarge— quiere una respuesta distinta de un bucle de reintento. Dimensiona el techo a tu working set, presupuesta para las copias de réplica encima, y el nodo mantiene su línea sin que lo vigiles.

El modelo completo, incluyendo las políticas que el motor lleva pero todavía no expone, está en Memoria y expulsión; los campos y valores por defecto exactos están en la referencia de configuración, y cada estado de capacidad está catalogado en la referencia de estados y excepciones.

La mayor parte de lo que Zaris hace bien —replicar una escritura a un backup, poner al día a una réplica rezagada, traspasar una partición a un nuevo propietario— se reduce a una pregunta silenciosa: ¿cuál es, exactamente, la unidad de datos que se mueve entre nodos? Si esa unidad está bien, la convergencia es casi aburrida. Si deja caer un campo o lleva el equivocado, obtienes una clave eliminada resucitada, una réplica que no puede distinguir lo obsoleto de lo fresco, o la contabilidad de un nodo filtrándose en otro.

En Zaris esa unidad es un solo tipo —StoredRecord— y vale la pena desmontarlo campo por campo, porque cada decisión en él es portante. Este artículo es la anatomía: qué contiene el registro, cómo se enmarca en el cable, por qué una eliminación viaja como un registro en lugar de como una ausencia, por qué hay dos números de versión distintos, y —igual de importante— qué deliberadamente se deja atrás en cada nodo y nunca cruza el cable en absoluto.

Una carga útil, en todas partes​

Un almacén clave/valor tiene un número sorprendente de lugares donde "un valor" tiene que describirse con precisión: el mapa en memoria, el stream de replicación, la instantánea de migración, el log de operaciones. Zaris usa la misma forma de registro para todos ellos. La cosa que está en el diccionario del segmento es la misma cosa que recibe una réplica, es la misma cosa que recibe un nuevo propietario durante el cut-over. Esa uniformidad es por qué el log de operaciones puede hacer dos trabajos a la vez y por qué una instantánea de migración y un backfill de réplica no necesitan codificaciones separadas.

Aquí está todo el tipo, despojado a su superficie de cable:

[MessagePackObject]
public class StoredRecord
{
    [Key(0)] public ZarisEntry Entry { get; set; }     // key + value + metadata
    [Key(1)] public Revision Revision { get; set; }    // segment-wide ordering
    [Key(2)] public ItemVersion Version { get; set; }  // per-key CAS version
    [Key(3)] public DateTime TimestampUtc { get; set; }
    [Key(4)] public bool IsDeleted { get; set; } = false;  // tombstone flag

    [IgnoreMember] public long AccountedBytes { get; set; }      // node-local
    [IgnoreMember] public object? MaterializedValue { get; set; } // node-local
}

Cinco campos cruzan el cable. Dos más viven en el objeto pero están marcados [IgnoreMember] y nunca viajan. El resto de este artículo es por qué cada uno está donde está.

El enmarcado: MessagePack con claves posicionales​

Zaris serializa los registros con MessagePack, y los atributos [Key(N)] son la razón por la que el cable se mantiene pequeño. MessagePack puede serializar un objeto de dos formas: como un mapa de nombre-de-campo → valor (autodescriptivo, pero cada mensaje repite cada nombre de campo como una cadena), o como un arreglo posicional donde cada campo se identifica por un índice entero. Los atributos [Key(0)], [Key(1)], … seleccionan la forma de arreglo. En el cable un registro es un arreglo corto de valores en un orden fijo —sin nombres de campo, sin puntuación estilo JSON, solo las cargas útiles.

Eso importa porque este registro es la estructura de datos caliente de todo el sistema. Se serializa en cada escritura replicada y cada clave migrada; a cientos de miles de escrituras por segundo la diferencia entre enviar "TimestampUtc" como una cadena un millón de veces y enviar nada más que la posición no es una micro-optimización, es el presupuesto.

El esquema posicional también fija la regla para evolucionar el formato de forma segura: las claves enteras son solo-de-adición (append-only). Un nuevo campo recibe el siguiente índice sin usar; los índices existentes nunca cambian de significado. Un nodo más viejo que no conoce el índice 7 simplemente lo ignora; un nodo más nuevo leyendo un registro viejo encuentra el índice 7 ausente y recurre a un valor por defecto. Veremos un campo —las etiquetas (labels) en la clave de mapa 3 dentro de los metadatos— que se apoya exactamente en este comportamiento de "ausente significa por defecto" para no costar nada cuando no se usa.

Dentro de la entrada: clave, valor y metadatos no nulos​

ZarisEntry es el campo Entry —la parte que un usuario reconocería como "sus datos":

[MessagePackObject]
public class ZarisEntry
{
    [Key(0)] public string Key { get; set; } = string.Empty;
    [Key(1)] public object Value { get; set; } = default!;
    [Key(2)] public EntryMetadata Metadata { get; }  // getter guarantees non-null
}

Dos detalles aquí son del tipo que solo aprendes quemándote una vez. Primero, Value está tipado object, no byte[] o string —la forma concreta del valor es lo que sea que el escritor puso ahí, enmarcado dentro de la entrada, que es cómo el mismo tipo de registro lleva una cadena simple, un contador, o toda una colección replicada sin que el registro necesite saber cuál.

Segundo, Metadata se sirve a través de un getter que nunca puede devolver null:

private EntryMetadata? _metadata;
[Key(2)]
public EntryMetadata Metadata
{
    get => _metadata ??= new EntryMetadata();
    set => _metadata = value;
}

MessagePack omite el constructor durante la deserialización y llama a los setters directamente, así que un inicializador simple = new() no sobreviviría a un viaje de ida y vuelta —un registro que llegara sin metadatos deserializaría con unos nulos, y cada sitio de llamada downstream necesitaría una comprobación de null. El getter hace la garantía estructural en su lugar: los metadatos están siempre ahí, incluso cuando el cable no llevó ninguno. Un lugar donde imponer el invariante, cero guardas de null en todos los demás.

Metadatos que no cuestan nada cuando están vacíos​

EntryMetadata lleva los atributos opcionales de una clave —CreatedAt, Ttl, ContentType, un handle opcional de arrendamiento o lock, y etiquetas. El campo de etiquetas es una pequeña clase magistral sobre no pagar por lo que no usas. La mayoría de las claves no tienen etiquetas, y un Dictionary ingenuo inicializado por entrada es puro desperdicio —en un almacén real, 390K entradas sin etiquetas sostenían cada una un diccionario vacío de 80 bytes, unos 31 MB de nada.

El arreglo es de dos lados. En el heap, las entradas sin etiquetas comparten un único diccionario vacío estático, así que los lectores aún ven un mapa no nulo (vacío) pero no asignan nada. En el cable, la superficie serializada es null cuando no hay etiquetas:

[Key(3)]
public Dictionary<string, LabelValue>? LabelsSerialized
{
    get => _labels != null && _labels.Count > 0 ? _labels : null;
    set => _labels = value != null && value.Count > 0 ? value : null;
}

Una entrada sin etiquetas escribe nil en el índice 3 y el lector restaura "sin etiquetas" a partir de ello. Este es el esquema de claves solo-de-adición ganándose el sustento: el caso común cuesta un byte, y la característica está ahí en pleno en el momento en que una clave realmente necesita una etiqueta.

Dos números, dos trabajos: Revision e ItemVersion​

El punto de confusión más común sobre los registros de Zaris es que llevan dos números que aumentan monótonamente. No son redundantes —responden preguntas distintas, y confundirlos rompería uno de los dos trabajos.

ItemVersion es por clave. Comienza en 1 e incrementa en uno cada vez que esa clave se escribe. Es el número que el cliente ve y el número contra el que las comprobaciones de compare-and-swap optimistas verifican: "confirma solo si esta clave sigue en la versión 7". Cuando el almacén aplica un put, la nueva versión es simplemente la versión de la clave vieja más uno:

long newVersion = (existing?.Version.Version ?? 0) + 1;

Revision es por segmento. Es un único contador compartido por cada clave en la partición, incrementado en cada escritura y cada eliminación:

revision = new Revision(Interlocked.Increment(ref _storeRevision));

Eso hace de Revision un orden total sobre todas las mutaciones en un segmento, que es exactamente lo que la replicación y la recuperación necesitan. A una réplica no le importa que la clave user:1 esté en su 7.ª versión; le importa qué revisiones de todo el segmento ya ha visto para poder pedir todo lo posterior a ese punto. El log de operaciones está indexado por revisión, el protocolo de puesta al día solicita "todo lo posterior a la revisión R", y la resolución de conflictos entre un registro entrante y uno local compara revisiones, no versiones por clave:

// An incoming record older than what we already hold is stale — ignore it.
if (existing is not null && existing.Revision.Value >= record.Revision.Value)
    return;

Así que: ItemVersion es la unidad de concurrencia optimista visible al cliente sobre una clave; Revision es la unidad de orden y convergencia entre nodos a lo largo de todo el segmento. El mismo registro, dos relojes, cada uno haciendo un trabajo que el otro no puede.

Una eliminación es un registro, no una ausencia​

Aquí está el campo que más sorprende a la gente: IsDeleted. Cuando eliminas una clave en Zaris, el almacén no simplemente quita la entrada de su diccionario. Escribe un StoredRecord con IsDeleted = true —una tombstone— lo estampa con la siguiente revisión del segmento, y lo añade al log de operaciones como una eliminación:

var revision = new Revision(Interlocked.Increment(ref _storeRevision));
_deleteRevisions[key] = revision.Value;
AppendOperationLog(revision.Value, key, ReplicationOperation.Delete, new StoredRecord
{
    // ...
    Revision = revision,
    IsDeleted = true,
});

La razón es todo el punto del formato de registro. Si una eliminación fuera meramente una ausencia —la clave desvaneciéndose silenciosamente de un mapa— no habría nada que replicar. Una réplica que se perdiera el momento de la eliminación seguiría sirviendo el valor viejo para siempre, porque "nada" no viaja y no puede ordenarse contra las escrituras a su alrededor. Al hacer de la eliminación un registro de primera clase con su propia revisión, la eliminación fluye por la misma ruta exacta de replicación y puesta al día que una escritura, y encaja en el orden total del segmento en el lugar correcto.

Las tombstones también defienden contra un fallo más sutil: una escritura obsoleta resucitante. Imagina una eliminación en la revisión 50 y un put más viejo para la misma clave, revisión 48, todavía en vuelo a través de la red. Sin una memoria de la eliminación, el put tardío aterrizaría y traería la clave de vuelta de entre los muertos. Zaris registra la revisión de eliminación y rechaza cualquier cosa en o antes de ella:

private bool HasDeleteRevisionAtOrAfter(string key, long revision)
    => _deleteRevisions.TryGetValue(key, out var deleteRevision)
       && deleteRevision >= revision;

El reverso de las tombstones es que no pueden acumularse para siempre, o una carga de trabajo con muchas eliminaciones filtraría memoria. Zaris recorta las revisiones de eliminación una vez que están con seguridad por debajo de la revisión más vieja que cualquier réplica todavía necesita —la misma lógica de marca de agua baja (low-water-mark) que recorta el log de operaciones— así que la tombstone hace su trabajo de convergencia y luego se recupera. (La disciplina de recorte es el tema del artículo sobre el log de operaciones.)

Lo que se queda en casa: los campos [IgnoreMember]​

Los dos campos que el registro lleva pero nunca serializa son tan deliberados como los cinco que sí. Ambos están marcados [IgnoreMember], y ambos son locales al nodo por diseño —correctos solo para el nodo que los computó.

AccountedBytes es la memoria contra la que se cobra este registro en el presupuesto del almacén, estampada una vez en el momento de escritura para que el almacén pueda reportar deltas de bytes sin re-medir el registro anterior. Explícitamente no se serializa, porque cada nodo lo computa a partir de la propia clave y valor del registro bajo sus propias reglas de contabilidad. Si viajara por el cable, un registro replicado desde el nodo A llevaría la estimación de bytes de A a los libros del nodo B —la contabilidad de un nodo distorsionando silenciosamente la de otro. Mantenerlo [IgnoreMember] significa que cada nodo lo recomputa independientemente, y un registro que llega vía replicación o migración lo contabiliza el nodo que ahora lo sostiene.

MaterializedValue es una forma en memoria viva, construida perezosamente, de una colección nativa (un hash, lista, set o sorted set) cacheada para que las operaciones por elemento no re-deserialicen todo el valor cada vez. Es pura aceleración local. La forma autoritativa es siempre los bytes del valor enmarcado dentro de Entry; un registro que llega de otro nodo materializa esta caché perezosamente en el primer acceso. Serializarla sería enviar el estado de borrador privado de un nodo como si fuera datos.

La disciplina aquí es limpia y vale la pena enunciarla en voz alta: el cable lleva la verdad, el nodo lleva las conveniencias. Cualquier cosa que un nodo pueda recomputar a partir del registro en sí —su costo de memoria, su estructura materializada— se queda local y se marca [IgnoreMember]. Cualquier cosa que sea parte de la identidad y el orden del registro —clave, valor, metadatos, los dos números de versión, el flag de tombstone— cruza el cable. La frontera del atributo es exactamente la frontera verdad/conveniencia, y mantenerla afilada es lo que hace seguro copiar el registro entre nodos sin pensarlo dos veces.

Por qué esto es comprobable, y comprobado​

Como la forma del registro es portante para la convergencia, su comportamiento en el cable está fijado por pruebas en lugar de dejado a inspección. Dos invariantes en particular ganan sus propias aserciones: el flag de tombstone debe sobrevivir a un viaje de ida y vuelta (un IsDeleted dejado caer resucita una clave eliminada en una réplica), y AccountedBytes debe volver como cero tras un viaje de ida y vuelta (probando que nunca viajó):

back.IsDeleted.Should().BeTrue(
    "a dropped tombstone flag resurrects a deleted key on the replica");

back.AccountedBytes.Should().Be(0,
    "AccountedBytes is [IgnoreMember]; each node recomputes it, it must not cross the wire");

Estas se leen casi como la tesis de todo el artículo escrita como aserciones: las cosas que deben cruzar el cable se demuestran que sobreviven a él, y las cosas que no deben se demuestran que se desvanecen.

El registro es el contrato​

Es fácil pensar en los problemas difíciles de un almacén distribuido como si vivieran en las partes vistosas —el protocolo de failover, el handshake de cut-over, las pruebas de caos. Lo hacen. Pero esos protocolos son solo tan correctos como la cosa que mueven, y la cosa que mueven es este único registro pequeño. Una tombstone en lugar de una ausencia es por qué una eliminación converge. Dos números de versión son por qué la concurrencia optimista de una clave y el orden de todo un segmento se mantienen desenredados. Las claves posicionales de MessagePack son por qué la ruta caliente se mantiene barata y el formato aún puede crecer. Y un par de campos [IgnoreMember] son por qué la replicación puede copiar un registro entre nodos y confiar en que nada local al nodo vino de polizón.

Acierta la unidad de datos y los grandes protocolos tienen algo sólido sobre lo que apoyarse. Ese es todo el caso para dedicar un artículo de blog a cinco campos y dos que se quedan en casa.

Aquí hay un resultado de benchmark que parece una contradicción. Un nodo de Zaris sirviendo una carga de trabajo intensiva en lecturas tope en poco menos de medio millón de ops/seg y se niega a trepar —añade más conexiones de cliente, más generadores de carga, y el número no se mueve. El diagnóstico obvio es "está saturado". Excepto que el gráfico de CPU dice otra cosa: el nodo está al cuarto de su CPU disponible, aproximadamente. Tres núcleos de cada cuatro están ociosos, y el throughput está plano.

Eso no es un nodo limitado por núcleos, y —si lo has descartado con cuidado— tampoco es un benchmark limitado por el cliente. Es una tercera cosa, y es un clásico: el pool de workers de despacho de solicitudes era más estrecho de lo que el trabajo quería ser, así que las solicitudes se encolaban mientras los núcleos estaban de brazos cruzados.

Primero, descarta a los sospechosos habituales​

Dos explicaciones tienen que irse antes de que esta esté siquiera sobre la mesa, porque son mucho más comunes.

Limitado por núcleos. Si el nodo está en o cerca del 100% de CPU y el throughput está plano, genuinamente te has quedado sin CPU —la respuesta es más núcleos o más nodos, y Zaris escala las lecturas añadiendo núcleos. Ese no es este caso: aquí la CPU está ociosa.

Limitado por el cliente. Un solo generador de carga se satura mucho antes que el servidor, y entonces estás midiendo tu cliente, no Zaris. Si el throughput está plano a medida que añades núcleos de servidor, sospecha de tu cliente primero —añade generadores y conexiones hasta que el número del lado del servidor realmente responda. Cubrimos esta trampa en el artículo sobre lecturas, y es la que hay que eliminar antes de seguir adelante.

Lo que queda después de esos dos es el caso interesante: suficiente carga ofrecida para mantener ocupado al nodo, mucho margen de CPU, y el throughput todavía plano. Cuando el cuello de botella está dentro del servidor pero no es la CPU, lo que hay que mirar es la concurrencia —cuántas solicitudes el nodo trabajará a la vez.

El pool de despacho es el límite de concurrencia​

Cada solicitud que llega a un nodo de Zaris se entrega a un pool de workers de despacho de solicitudes. Un worker la recoge, la enruta a la partición que posee la clave, ejecuta la operación contra el almacén en proceso de esa partición, y escribe la respuesta de vuelta. Para una lectura, la operación en sí es una búsqueda en memoria a escala de microsegundo —genuinamente diminuta.

El ancho de ese pool —cuántos workers pueden estar a mitad de solicitud simultáneamente— fija un techo duro sobre las solicitudes en vuelo, y ese es un número distinto de "qué tan rápido es una operación". El valor por defecto original derivaba el ancho de un pequeño múltiplo de Environment.ProcessorCount. En un nodo de 4 vCPU, un pool de un par-de-veces-los-núcleos son solo un puñado de workers.

Aquí está la sutileza que hace que el gráfico de CPU parezca equivocado. Si cada worker gastara toda su ranura quemando CPU en la búsqueda, un pool dimensionado a los núcleos sería exactamente correcto y el nodo sí alcanzaría el 100% de CPU. Pero los workers no gastan toda su ranura en CPU. Un worker ocasionalmente se estaciona (parks) —una continuación de await, una escritura de socket que no se completa síncronamente, un breve lock sobre una estructura compartida. Un worker estacionado no quema CPU, pero aún sostiene su ranura del pool. Con solo un puñado de ranuras, unos pocos workers estacionados bastan para estancar todo el nodo: las nuevas solicitudes se encolan detrás de ellos, y como los workers ocupados están mayormente esperando en lugar de computando, los núcleos nunca se encienden. Throughput plano, CPU ociosa. El ancho del pool era el techo, no el silicio.

La señal que distingue esto de un benchmark limitado por el cliente: las solicitudes se encolan en el servidor (la latencia trepa, el throughput está plano) mientras la CPU del servidor se mantiene baja. Limitado por el cliente se ve distinto —el servidor está ocioso porque nada llega lo bastante rápido. Aquí, el trabajo está llegando; el nodo simplemente no acepta suficiente de él a la vez.

El arreglo: dimensiona el pool para el trabajo, no para el conteo de núcleos​

La reparación no es exótica. Las lecturas son búsquedas en memoria a escala de microsegundo, así que el pool debería estar fijado ancho por defecto —lo bastante ancho como para que un puñado de workers estacionados no pueda hambrear al nodo— y debería ser ajustable, porque el ancho correcto depende del nodo y la carga de trabajo, no de un múltiplo fijo del conteo de núcleos.

El ancho de pool por defecto ahora es CPU count × 16, acotado a una banda sensata de 64–1024, con un piso de max(4, CPU count × 4). Dos variables de entorno lo anulan:

# A node with spare CPU and requests queuing — widen the pool.
ZARIS_SERVER_MAX_WORKERS=512 ZARIS_SERVER_MIN_WORKERS=64 \
  dotnet Clustron.Zaris.Server.dll

Una propiedad que vale la pena señalar: este es un cambio del lado del servidor y nada más. El protocolo de cable no cambia, el SDK del cliente no cambia, y no hay un bump de NuGet que perseguir —afinas un nodo reiniciándolo con un entorno distinto, y cada cliente existente sigue hablando con él sin cambios.

Afínalo con honestidad: ensanchar no es gratis​

El reflejo tras leer esto es subir ZARIS_SERVER_MAX_WORKERS al tope en cada nodo. No lo hagas. Un pool más ancho ayuda en exactamente una situación y no hace nada —o perjudica levemente— en las demás.

• Ayuda cuando las solicitudes se encolan mientras la CPU está ociosa. Ese es el caso de todo este artículo: la concurrencia en vuelo es el límite, así que admitir más de ella llena los núcleos. Aquí es donde verás saltar el throughput.
• No hace nada cuando ya estás limitado por CPU. Si el nodo está al 100% de CPU, más workers no conjurarán throughput de la nada —solo añaden sobrecarga de cambio de contexto a una máquina que no tiene ciclos de sobra. Más workers no es más cómputo.
• Puede perjudicar si lo llevas a un ancho absurdo. Miles de workers machacando un nodo de 2 vCPU gastan tiempo real cambiando de contexto en lugar de servir. Por eso hay un acotamiento, y por eso la perilla tope en 4096 en lugar del infinito.

El bucle de afinado honesto es: busca la firma —latencia trepando y throughput plano mientras la CPU está muy por debajo de la saturación— sube MAX_WORKERS, y mide. Si la CPU trepa y el throughput la sigue, el pool era tu techo. Si nada se mueve, no lo era, y deberías devolver la perilla y mirar en otro lugar (la ruta de red, el cliente, o genuinamente necesitar más nodos).

Mide la CPU donde es realmente cierta​

Toda esta investigación depende de confiar en el número de CPU, y ese número es fácil de obtener mal.

• Lee la CPU del cgroup, no de una estimación del metrics-server del clúster. En Kubernetes especialmente, la cifra del metrics-server se retrasa y suaviza —te dirá que un nodo está al 40% cuando la contabilidad del cgroup dice que está clavado, o al revés. Diagnostica un caso de "throughput plano, CPU ociosa" desde el cgroup, o perseguirás un número que no es real.
• Los benchmarks locales están limitados por el host y ocultarán el techo. En un portátil, el generador de carga y el servidor pelean por los mismos núcleos, así que nunca presentas al servidor con carga limpia y suficiente —la meseta que mides es tu plataforma de prueba, no Zaris. El techo real del pool de workers apareció a escala en un clúster gestionado con la carga impulsada desde máquinas separadas, no en una caja de desarrollador. Valida el throughput donde el cliente no pueda ser el cuello de botella.

La conclusión​

Una curva de throughput plana tiene tres causas muy distintas, y el gráfico de CPU te dice cuál estás mirando. Al 100% de CPU, estás limitado por núcleos —añade nodos. Con el servidor ocioso porque nada llega lo bastante rápido, estás limitado por el cliente —arregla la prueba. Pero un nodo que está plano al cuarto de su CPU, con solicitudes visiblemente encolándose, no es ninguno de los dos: es un límite de concurrencia, y en Zaris ese es el pool de workers de despacho. El valor por defecto ahora es lo bastante ancho como para que la mayoría de las cargas de trabajo nunca lo alcancen, y ZARIS_SERVER_MAX_WORKERS está ahí para las que sí —para subirse deliberadamente, cuando el gráfico de CPU se lo ha ganado.

Para la superficie completa de variables de entorno y los valores por defecto exactos, consulta la referencia de configuración. Si estás dimensionando un clúster para throughput, la guía de benchmarking recorre los ajustes que realmente mueven los números, y Lecturas que escalan con tus núcleos cubre la otra mitad de la historia —por qué, una vez que el pool está fuera del camino, añadir núcleos añade capacidad de lectura en lugar de chocar con un muro de bucle-de-eventos-único.

Una conmutación por error es el momento en que un almacén distribuido es más honesto sobre lo que realmente es. En estado estable todos los almacenes se ven iguales: una escritura llega a un dueño, se confirma, y sigues adelante. El diseño solo se muestra cuando el dueño desaparece a mitad de frase: un nodo tiene la copia activa de una de tus particiones, le están llegando escrituras ahora mismo, y de pronto ya no está. Eliminado en seco. Particionado por la red. Muerto por OOM. El clúster tiene unos segundos para darse cuenta, acordar un nuevo dueño y hacer que el tráfico vuelva a fluir; y que lo haga correctamente decide si tu escritura confirmada sobrevive o se evapora silenciosamente.

Esta entrada sigue esa secuencia de principio a fin, en el orden en que Zaris realmente la ejecuta, y nombra los casos en los que la respuesta es genuinamente "la escritura se pierde", porque una entrada sobre conmutación por error que solo describe el camino feliz no vale la pena leer.

El único invariante que hace tratable el resto​

Antes de la línea de tiempo, la única decisión de diseño de la que cuelga todo lo demás: Zaris separa el mapa de particiones del runtime de particiones.

El mapa de particiones es la asignación lenta y deliberada —qué nodos son responsables de la partición P: un primario preferido y sus réplicas—. Cambia solo ante eventos de topología reales (un nodo se une o se va permanentemente, un escalado horizontal, un rebalanceo) y cambia mediante una regeneración planificada y versionada.

El runtime es la respuesta rápida y en vivo a una pregunta distinta —qué nodo asignado es el dueño activo que sirve P ahora mismo, y con qué salud—. Durante una conmutación por error el mapa no se mueve en absoluto. Solo se mueve el activo del runtime. Ese es el invariante declarado en el propio servicio de conmutación por error: una única señal independiente de fallo abre la compuerta de conmutación del runtime, "PartitionMap remains stable and only PartitionRuntimeMap.Active is allowed to move during failover."

Por qué importa: regenerar un mapa de particiones es caro y peligroso; puede reordenar particiones sanas y disparar migración de datos. Que un nodo muera no debería disparar eso. Debería disparar una decisión de runtime barata y local: elegir una réplica superviviente de la misma partición y hacerla el activo. El mapa sigue diciendo "P es propiedad de n1, n2, n3"; el runtime cambia de "activo = n1" a "activo = n2". Mantener estos dos planos separados es lo que permite que la conmutación sea rápida sin ser imprudente.

Paso 1 — detectar, pero no creerse el primer rumor​

La conmutación por error está coordinada por el líder. Un nodo del clúster es el líder electo, y solo el líder promueve: un no-líder que oye un evento de nodo-salido simplemente lo ignora. Eso evita que dos nodos elijan independientemente dos nuevos dueños distintos para la misma partición.

Cuando el líder recibe una señal NodeLeft para un nodo, no promueve inmediatamente réplicas para cada partición que ese nodo poseía. La promoción se señala en el código como "an irreversible, high-impact action", y está protegida:

if (string.Equals(activeOwner, nodeId, StringComparison.Ordinal))
{
    // A NodeLeft message can race ahead of the peer-table update.
    // If the "dead" owner is in fact still reachable, do NOT fail it over.
    if (IsNodeAlive(nodeId))
    {
        Log.NodeUnavailableRejectedReachable(/* ... */);
        continue;
    }
    await PromoteOrMarkUnavailableAsync(partition, nodeId, runtime, ct);
}

La protección existe porque el mensaje de fallo y la tabla de pares de la capa de membresía se actualizan de forma asíncrona. Un NodeLeft puede llegar un latido antes de que la tabla de pares lo refleje, o estar rotundamente equivocado. Así que antes de la acción de alto impacto, el líder vuelve a comprobar la vitalidad directamente. Un dueño "muerto" todavía alcanzable se deja exactamente donde está.

Hay un segundo camino, más lento, para el caso que el primero no puede cubrir: un dueño activo que se ha quedado en silencio sin un NodeLeft limpio. Un barrido periódico de reconciliación (HandleUnavailableActiveOwnersAsync) recorre cada partición, y para un dueño que no está vivo pero no ha sido confirmado como caído, arranca un temporizador de sospecha en lugar de actuar:

var suspectedSince = _suspectedUnavailableSinceUtc.GetOrAdd(activeOwner, _ => DateTime.UtcNow);
if (DateTime.UtcNow - suspectedSince < _suspectEscalationTimeout)
{
    Log.UnconfirmedActiveOwnerFailure(/* ... */);
    continue;   // not yet — give it until the escalation timeout
}
ConfirmNodeUnavailable(activeOwner, "RuntimeOwnershipSuspectEscalationTimeout");

Solo después de que el dueño haya estado inalcanzable durante toda la ventana de escalada (diez segundos por defecto) el líder lo confirma como caído y procede. El diseño es deliberadamente asimétrico: marcar una partición como degradada por pérdida de réplica es barato y reversible, así que se dispara de inmediato; promover un nuevo activo es irreversible, así que espera a tener pruebas.

Paso 2 — elegir un superviviente, y subir la época​

Una vez confirmado que el dueño está caído, el líder elige una réplica para promover. La selección es primero la disponibilidad: entre las réplicas asignadas de la partición, prefiere la que ha sincronizado más segmentos, el nodo con más probabilidades de poder servir pronto.

La promoción en sí es una única difusión que avanza una época por partición:

var nextEpoch = GenerateNextEpoch(partition.PartitionId, runtime, "ReplicaPromotion");
// ...
await _runtimeOwnership.BroadcastAsync(
    partition.PartitionId, promotedNodeId, nextEpoch.Value, promotionState, ct);

La época es el token de delimitación (fencing token), y es el héroe silencioso de todo el mecanismo. Es monótona por partición, y el generador se niega a retroceder: una época propuesta que no sea estrictamente mayor que la más alta ya observada se rechaza de plano:

var nextEpoch = baseEpoch + 1;
if (nextEpoch <= highestObservedEpoch)
{
    Log.StaleEpochGenerationRejected(/* ... */);
    return null;   // never regress ownership
}

Así que tras la promoción, el activo de la partición es "n2 en la época 8". Si el antiguo dueño n1 estaba meramente particionado (no muerto) y vuelve creyendo que sigue siendo el activo en la época 7, su época obsoleta pierde toda comparación. No puede reclamar la propiedad, y cualquier escritura que intente aceptar como "activo" queda delimitada fuera (fenced). Así es como Zaris evita el split-brain de dos primarios que de otro modo dejaría que un antiguo dueño sanado-pero-confundido aceptara escrituras que nadie volverá a ver jamás.

Paso 3 — la prueba de posesión: ¿servir o sincronizar primero?​

Aquí está la parte sutil, y la parte que requirió depuración real para hacerla bien. Habiendo elegido la réplica más disponible, ¿puede realmente empezar a servir lecturas de inmediato?

No necesariamente, porque "más segmentos sincronizados" no es lo mismo que "tiene todas las claves confirmadas". Una réplica puede estar al día en el recuento de segmentos y aun así ir por detrás de los datos verdaderos en los segmentos que tiene. Promueve tal nodo directamente a un estado de servicio y se convierte en un activo incompleto: responde NotFound a claves que fueron confirmadas de forma durable en el dueño muerto y que sí existen en un hermano más completo. Eso es pérdida silenciosa de datos disfrazada de lectura exitosa.

Así que antes de permitir que el nodo promovido sirva, Zaris aplica una prueba de posesión. El líder mantiene una tabla fresca y emparejada por término (term-matched) de cuántas claves reporta tener cada nodo para la partición. La regla es una comparación pura:

public static PartitionHealthState ResolvePromotionState(
    long candidateHeldKeys, long bestOtherLiveHolderKeys)
    => bestOtherLiveHolderKeys > candidateHeldKeys
        ? PartitionHealthState.Recovering   // a more-complete live peer exists: sync first, do NOT serve
        : PartitionHealthState.Degraded;    // candidate is the authority: serve now

Dos resultados:

• No existe ningún poseedor vivo estrictamente más completo — el candidato es el nodo más completo, o un genuino único superviviente sin nada de lo que sincronizar. Se promueve a Degraded: un estado de servicio. No tiene nada mejor por lo que esperar, así que acuñarlo como no-servicio solo haría la partición innecesariamente indisponible. Sirve de inmediato.
• Sí existe un poseedor vivo estrictamente más completo — el candidato se promueve a Recovering: un estado sin servicio. Sincroniza primero desde esa fuente mejor y solo empieza a servir una vez que se demuestra completo. A los clientes se les dice que la partición todavía está arrancando, en lugar de entregarles un nodo que les mentiría.

La distinción entre Degraded y Recovering es exactamente la distinción entre "la redundancia está reducida pero se está sirviendo la verdad" y "no confíes todavía en este dueño para lecturas". Lograr que un único superviviente entre correctamente en Degraded importa tanto como mantener un nodo incompleto en Recovering: una única copia restante nunca debe quedar acuñada como no-servicio para siempre solo porque es la única copia que queda.

Una nota rápida sobre honestidad: esta prueba está basada en recuentos, extraída de los reportes de claves-poseídas por nodo con una marca de agua de frescura (un reporte de un nodo que se ha quedado en silencio no cuenta como fuente viva). Es una protección fuerte y barata contra promover a servicio un nodo obviamente rezagado; no es una atestación criptográfica de que dos nodos tienen datos byte a byte idénticos. La convergencia que hace las copias realmente idénticas es el camino de sincronización de réplicas, cubierto más abajo.

Paso 4 — el cliente se redirecciona, y tu reintento aterriza​

Mientras todo esto ocurre en el servidor, ¿qué ve el cliente que estaba a mitad de escritura?

Ve la verdad, como un estado tipado. Una solicitud que llega al antiguo dueño (ahora delimitado, o simplemente ido) no se cuelga ni lanza un error vago: vuelve como Moved u OwnershipChanging. El cliente de Zaris los trata como señales de redireccionamiento reintentables: refresca su mapa de propiedad, descubre el nuevo activo y reproduce la operación ahí. En el caso común tu PutAsync simplemente tarda unos milisegundos más y devuelve Ok, contra el dueño recién promovido, en la nueva época. El código de la aplicación nunca se entera de que el dueño se movió.

Esa maquinaria del cliente —la taxonomía de estados, el reintento con presupuesto-de-intentos-y-plazo, el refresco del mapa— es una historia en sí misma, contada en Reintentos que no escribes. Para esta entrada el punto es solo que el aumento de época del servidor y el redireccionamiento del cliente son dos mitades de un solo traspaso: el servidor hace al antiguo dueño no-autoritativo, y el cliente deja de hablarle.

Paso 5 — converger, luego sanar de vuelta a Healthy​

La promoción restaura la disponibilidad; no restaura la redundancia. Justo después de una conmutación por error la partición corre en Degraded con una copia menos de su objetivo. Entonces ocurren dos cosas en segundo plano.

Primero, el nodo promovido (si arrancó en Recovering) y cualquier réplica rezagada o que retorna se ponen al día reproduciendo el registro de operaciones por segmento desde una revisión conocida, el mismo sustrato reproducible que impulsa la replicación ordinaria. Un nodo que acaba de heredar el rol activo y una réplica que simplemente se quedó atrás convergen a través del mecanismo idéntico; ese es el tema de Un registro, dos trabajos.

Segundo, una vez que cada participante asignado está vivo de nuevo y sincronizado, el barrido de recuperación del líder transiciona la partición de vuelta a Healthy, pero solo mediante la misma difusión que avanza la época, y solo tras un breve enfriamiento para que un nodo oscilante no pueda arrastrar el runtime a través de una tormenta de transiciones. La máquina de estados de salud es por tanto un bucle pequeño y cerrado: Healthy → Degraded/Recovering → Healthy, cada arista un aumento de época, cada promoción delimitada.

Si no sobrevive ninguna réplica elegible en absoluto —todos los nodos asignados a la partición están caídos—, el líder hace lo único honesto: marca la partición como Unavailable (sin dueño, sin falsa promoción) e inicia una cuenta regresiva de desalojo que, si nadie retorna a tiempo, deja que una regeneración planificada del mapa reubique la partición. Una partición Unavailable falla lecturas y escrituras ruidosamente en lugar de servir una mentira.

Dónde se pierde genuinamente una escritura — dicho con claridad​

Un mecanismo de conmutación por error gana confianza siendo preciso sobre sus bordes, no insinuando que no los hay.

• Factor de replicación 1. Una partición con una sola copia y sin réplica no tiene nada que promover. Cuando ese nodo muere la partición queda Unavailable hasta que retorne; los datos no se pierden (están en la memoria de ese nodo) pero están indisponibles, y si el nodo nunca retorna, se han ido. RF1 es no-durable por diseño: es una elección deliberada para datos que te puedes permitir perder, no una garantía que el camino de conmutación pueda rescatar.
• Confirmación asíncrona. Zaris permite que una escritura se confirme en el dueño activo antes de que haya llegado a una réplica, por latencia. Ese es el camino rápido, y su coste honesto es una ventana: si el activo muere en el hueco entre confirmarle al cliente y que la operación llegue a cualquier poseedor superviviente, esa escritura confirmada se pierde. La prueba de posesión te protege de promover a servicio un nodo conocido como rezagado; no puede conjurar una operación que nunca salió del nodo muerto. Si necesitas que una escritura sobreviva a la pérdida de su dueño, debe confirmarse solo después de que sea durable en una réplica; el camino síncrono cambia un poco de latencia por exactamente esa garantía. Elige por carga de trabajo, con los ojos abiertos.
• La ventana de confirmación misma. Durante el tiempo de escalada tras que un dueño se queda en silencio, las escrituras de la partición están en el limbo: reintentadas por el cliente, aún sin aterrizar en un nuevo dueño. La corrección se preserva (nada se promueve erróneamente), pero la disponibilidad cae durante esa ventana. Apretar el tiempo de espera cambia una conmutación más rápida por más falsas promociones bajo parpadeos transitorios; es un dial, no un almuerzo gratis.

Ninguno de estos son errores que el camino de conmutación pueda diseñar para eliminar: son las genuinas disyuntivas de disponibilidad frente a durabilidad frente a latencia, y el trabajo de Zaris es hacer que la elección segura sea la predeterminada y la elección rápida sea explícita, nunca fingir que la ventana no existe.

La forma de todo esto​

Reduce la conmutación por error a lo esencial y son cuatro movimientos sobre un invariante. El invariante: el mapa se queda quieto; solo se mueve el activo del runtime. Los movimientos: confirmar la muerte antes de actuar sobre ella, promover a un superviviente detrás de una época monótona que delimita al antiguo dueño, probar la posesión para que el nuevo dueño sirva la verdad o sincronice antes de servir siquiera, y redireccionar al cliente para que su reintento aterrice en el nuevo dueño. Luego converger las copias de vuelta y sanar a Healthy.

Que se sostenga no es una cuestión de argumento: está medido. El mismo camino de promoción, posesión y convergencia corre continuamente bajo caos deliberado de eliminación de nodos durante horas seguidas, con el libro mayor revisado al final en busca de una sola escritura confirmada perdida. Esa certificación es su propia historia: Ninguna escritura confirmada se queda atrás.

La mayoría de las razones para recurrir a una caché distribuida en una aplicación .NET nunca mencionan una caché por su nombre. Añades caché de salida (output caching) y quiere un IDistributedCache. Habilitas sesiones y el middleware quiere un almacén de respaldo. Activas el uso compartido de claves de protección de datos entre instancias y, de nuevo, quiere un lugar donde poner bytes que todos los nodos puedan ver. El código de la aplicación está escrito contra una abstracción; la única pregunta es qué implementación registras al arrancar.

Zaris responde a esa pregunta con tres pequeños paquetes NuGet, cada uno apuntando a una costura específica de ASP.NET Core: un IDistributedCache simple, un HybridCache de dos niveles y un almacén de sesiones. Registras una línea al arrancar y el resto de tu aplicación —incluidas las bibliotecas de terceros que solo conocen la abstracción— cachea en un clúster Zaris sin un solo cambio en el código que usa la caché. Esta entrada recorre los tres, y es deliberada sobre dónde se detiene honestamente cada uno.

Los tres paquetes​

Los tres se apoyan en el mismo cliente .NET de Zaris. No inventan un canal lateral: resuelven un cliente Zaris normal a partir de una cadena de conexión y traducen Get/Set/Remove a los GetAsync/PutAsync/DeleteAsync del cliente. Si has leído Una cadena de conexión, cualquier plataforma, el cableado te resultará familiar: la caché es simplemente otro consumidor de un almacén con nombre.

1. El IDistributedCache estándar​

Este es el de usar y listo. IDistributedCache es la interfaz que Microsoft.Extensions.Caching.Abstractions ha expuesto durante años, y una gran parte del ecosistema .NET —sesiones, caché de salida, almacenes de tickets de autenticación, bibliotecas de terceros— depende exactamente de esa interfaz y de nada más. Registra Zaris como la implementación y todo eso queda respaldado por tu clúster.

builder.Services.AddClustronZaris("app-cache", "zaris://cache-host:7861/app-cache");

builder.Services.AddClustronDistributedCache(
    storeName: "app-cache",
    configure: o => o.KeyPrefix = "myapp:");

La primera línea registra un cliente Zaris bajo la clave de DI app-cache; la segunda registra un IDistributedCache que lo usa. A partir de aquí, cualquier cosa que acepte un IDistributedCache —incluido código que no escribiste tú— funciona:

public sealed class WeatherController(IDistributedCache cache)
{
    public async Task<Forecast> Get(string city)
    {
        var cached = await cache.GetAsync($"forecast:{city}");
        if (cached is not null)
            return Deserialize(cached);

        var fresh = await FetchForecastAsync(city);
        await cache.SetAsync(
            $"forecast:{city}",
            Serialize(fresh),
            new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            });
        return fresh;
    }
}

Por debajo, GetAsync es un client.GetAsync<byte[]> con el prefijo configurado aplicado, y un fallo de caché (la clave no existe) devuelve null, exactamente el contrato que la interfaz promete. SetAsync con AbsoluteExpirationRelativeToNow mapea esa ventana directamente a un TTL de Zaris, de modo que el almacén expira la entrada por ti.

Dos bordes honestos​

Solo se mapea la expiración absoluta relativa. El IDistributedCache de Zaris lee AbsoluteExpirationRelativeToNow y lo convierte en un TTL. Si no estableces expiración, la entrada se escribe sin TTL y vive hasta que se desaloja o se sobrescribe. SlidingExpiration en esta caché de propósito general no se respeta; su Refresh/RefreshAsync es una operación nula. Esa es una elección deliberada de alcance, no un descuido: la expiración deslizante es un asunto de sesiones, y el paquete de sesiones de más abajo la implementa correctamente en lugar de implementarla a medias aquí.

Puedes registrar más de uno, y el primero gana por defecto. Cada llamada a AddClustronDistributedCache registra una instancia de caché con nombre vinculada a un almacén específico. El primero registrado se convierte en el IDistributedCache de toda la aplicación; pasa setAsDefault: true para hacer que un registro posterior sea el predeterminado en su lugar. Si quieres varias cachés en almacenes distintos, resuélvelas explícitamente a través de IClustronCacheProvider.GetCache("other-store") en lugar de depender del predeterminado ambiental.

2. HybridCache — un nivel en proceso delante del clúster​

La abstracción más reciente de .NET, HybridCache, resuelve un problema que IDistributedCache te deja a ti: la combinación de una caché local rápida (L1) y una caché distribuida compartida (L2), más la protección contra estampidas, asegurando que cuando una clave popular expira, una estampida de solicitudes concurrentes no ejecute todas a la vez la costosa fábrica (factory).

Zaris implementa directamente la clase abstracta HybridCache. El giro es que ambos niveles son almacenes Zaris que tú nombras: apuntas L1 a un almacén embebido en proceso (sin red, sin salto de serialización fuera de la máquina) y L2 al clúster distribuido:

builder.Services.AddClustronZaris("l1", "zaris://inproc/l1");          // embedded, in-process
builder.Services.AddClustronZaris("l2", "zaris://cache-host:7861/l2"); // the cluster

builder.Services.AddClustronHybridCache(l1Store: "l1", l2Store: "l2");

El camino de lectura es la clásica búsqueda de dos niveles, y vale la pena verlo completo porque cada garantía de más abajo se desprende de él:

var product = await cache.GetOrCreateAsync(
    $"product:{id}",
    state: id,
    factory: async (pid, ct) => await db.LoadProductAsync(pid, ct),
    options: new HybridCacheEntryOptions
    {
        Expiration = TimeSpan.FromMinutes(10),          // L2 TTL
        LocalCacheExpiration = TimeSpan.FromMinutes(1)  // L1 TTL (shorter)
    },
    tags: new[] { "catalog" });

L1 se comprueba primero sin bloqueo. Ante un fallo, el llamante toma un bloqueo por clave, vuelve a comprobar L1 (por si otro llamante acaba de rellenarlo), luego L2; solo si ambos fallan ejecuta la fábrica, escribe L2 y luego escribe L1. Los TTL vienen de HybridCacheEntryOptions —Expiration para L2, LocalCacheExpiration para L1— y la implementación limita L1 a no ser más largo que L2, de modo que nunca puedes tener una copia local que sobreviva a la compartida. Omite las opciones y ambos tienen por defecto cinco minutos.

Protección contra estampidas, medida​

El bloqueo por clave es la protección contra estampidas. La propia prueba del paquete dispara veinte llamadas concurrentes a GetOrCreateAsync sobre una clave fría, cada una con una fábrica que duerme 100 ms, y comprueba que la fábrica se ejecutó exactamente una vez: diecinueve llamantes esperan en el bloqueo, y el que rellenó la caché los sirve a todos. Eso convierte un potencial martilleo de veinte vías sobre tu base de datos en una sola carga.

El borde honesto: este bloqueo vive en un ConcurrentDictionary<string, SemaphoreSlim> dentro del proceso. Colapsa la estampida dentro de una instancia de aplicación. Con diez instancias de aplicación todas frías sobre la misma clave en el mismo instante, todavía puedes ver hasta diez ejecuciones de fábrica, una por proceso, no una a nivel de todo el clúster. Esa es la forma normal de la protección contra estampidas del lado del cliente, y para el caso común (un puñado de instancias, una fábrica que es costosa pero no catastrófica de ejecutar unas pocas veces) es exactamente lo que quieres. Si necesitas estrictamente una sola carga en toda la flota, eso es un problema de bloqueo distribuido, no una característica de caché, y un trabajo mejor modelado con el patrón de reclamación por comparación e intercambio (compare-and-swap) de Coordinación sin condiciones de carrera.

Invalidación por etiquetas, y por qué es perezosa​

HybridCache te permite etiquetar entradas e invalidar un grupo entero de una vez:

await cache.RemoveByTagAsync("catalog");   // every entry tagged "catalog" is now stale

Zaris implementa esto con marcas de tiempo en lugar de un barrido activo. Cada entrada se escribe con dos etiquetas de metadatos: la hora en que se creó y sus etiquetas. RemoveByTagAsync("catalog") simplemente escribe una clave que registra "catalog fue invalidado en el instante T." En la siguiente lectura de una entrada etiquetada, la caché compara: si alguna de las etiquetas de la entrada fue invalidada después de que se creara la entrada, la entrada se trata como un fallo y la fábrica se vuelve a ejecutar. La prueba lo confirma: etiqueta una entrada, invalida la etiqueta, lee de nuevo, y la fábrica se llama por segunda vez.

La disyuntiva de diseño que hay que conocer: la invalidación es perezosa y disparada por lectura, no una purga ávida. Llamar a RemoveByTagAsync es O(1) —escribe un marcador y retorna— pero las entradas obsoletas en sí permanecen residentes en el almacén hasta que algo las lee (y obtiene un valor fresco) o su TTL expira. Obtienes una invalidación lógica barata e instantánea; no obtienes una recuperación inmediata de la memoria que esas entradas ocupan. Para datos de caché ese es exactamente el trato correcto. Simplemente no te apoyes en ello como una forma de forzar el borrado de datos por razones de corrección; para eso, RemoveAsync(key) elimina ambos niveles de plano.

3. Sesiones, con expiración deslizante real​

Las sesiones de ASP.NET Core necesitan un almacén que haga algo que la caché general deliberadamente no hace: deslizar la expiración en cada solicitud que toca la sesión, de modo que la sesión de un usuario activo nunca expire por debajo de él mientras que una inactiva eventualmente sí. El paquete de sesiones es un IDistributedCache hecho a propósito que respeta exactamente esa semántica, cableado con una llamada:

builder.Services.AddZarisSession(o =>
{
    o.StoreName        = "sessions";
    o.ConnectionString = "zaris://cache-host:7861/sessions";
    o.IdleTimeout      = TimeSpan.FromMinutes(30);
    o.CookieName       = ".MyApp.Session";
});

// ... later in the pipeline, as usual:
app.UseSession();

Dale una cadena de conexión y registra el almacén Zaris de respaldo por ti; omítela y se vincula a un almacén que ya hayas registrado bajo StoreName. En cualquier caso, luego usas HttpContext.Session exactamente como siempre lo has hecho.

La pieza que importa es Refresh. Cuando el middleware de sesión carga una sesión que fue leída pero no modificada, llama a RefreshAsync para mantenerla viva. La caché de sesión de Zaris implementa eso como una lectura-y-luego-reescritura con un TTL fresco igual al tiempo de espera de inactividad, de modo que cada solicitud que toca la sesión desliza la ventana de 30 minutos hacia delante. Una escritura (SetAsync) resuelve su TTL a partir de la expiración deslizante o absoluta de la entrada, recurriendo al tiempo de espera de inactividad configurado. El resultado es el comportamiento estándar de sesiones de ASP.NET Core, respaldado por un clúster Zaris, sobreviviendo a un reinicio de instancia de aplicación porque los datos de sesión viven en el almacén y no en la memoria de la instancia.

Una nota deliberada de implementación tomada del propio código: Refresh es una lectura-más-reescritura en lugar de una llamada nativa de "simplemente reiniciar el TTL". Eso cuesta una ida y vuelta extra, pero mantiene el deslizamiento correcto en cada despliegue de Zaris —incluido el embebido en proceso— sin depender de una primitiva de reinicio-de-TTL del lado del servidor. La corrección en cada topología superó a ahorrar una ida y vuelta en una de ellas.

Elegir el correcto​

• Recurre a IDistributedCache cuando algo ya lo pide, o cuando quieres la caché compartida más simple y una biblioteca va a consumirla por ti. Es la costura de máxima compatibilidad.
• Recurre a HybridCache en un camino de lectura genuinamente caliente donde un L1 en proceso se gana su sitio y una estampida sobre una clave popular fría dolería. Pagas por una pieza móvil extra (dos almacenes, memoria local para L1); obtienes lecturas repetidas de latencia casi nula y una estampida colapsada a una carga por instancia.
• Recurre a AddZarisSession específicamente para sesiones de ASP.NET Core; es la que tiene expiración deslizante real, y se mantiene al margen del propio IDistributedCache de tu aplicación.

Ninguno de los tres te pide aprender una API específica de caché. Se encuentran con el framework allí donde ya define la abstracción, se registran en una línea y ponen los bytes en un clúster que puedes escalar, asegurar y ejecutar en Kubernetes independientemente de la aplicación que tiene delante. La mejor integración es la que el código de tu aplicación nunca tiene que notar, y, con grata frecuencia, esa es exactamente la que obtienes.

La mayor parte de este blog ha profundizado en una cosa a la vez: compare-and-swap, transacciones multiclave, estructuras de datos nativas, streams, watch, el op-log que hay debajo. Cada artículo responde a "cómo funciona esto". Este responde a una pregunta distinta y más práctica: cuando tienes un problema delante, ¿cuál eliges?

Esa pregunta importa porque la elección equivocada rara vez es un fallo estrepitoso. Es un sistema que funciona en la demo y luego pierde una actualización bajo carga, o canaliza a mil escritores a través de una sola clave, o usa una notificación de tipo "dispara y olvida" donde hacía falta un log durable. Las primitivas no te impiden usarlas mal. Así que esto es una guía de campo: el modelo mental que las une, una tabla de decisión, un recorrido por cada rama con su encaje honesto y su límite honesto, y un diagrama de flujo al final.

Un núcleo, muchas vistas​

Empecemos por aquello sobre lo que se construye todo lo demás. Debajo de cada funcionalidad de este artículo, Zaris es un único almacén clave-valor particionado y replicado, y cada valor lleva una versión monótona propiedad del almacén. Eso es todo. Ese es el núcleo.

Todo lo demás es una de dos cosas:

• Una vista tipada, del lado del servidor, sobre las claves: un hash, una lista, un conjunto, un conjunto ordenado, un stream. No son blobs que recuperas y mutas en tu proceso; son colecciones reales del lado del servidor que viven en la partición dueña de su clave, y se replican exactamente igual que un valor plano.
• Una capa de coordinación sobre la versión: compare-and-swap, transacciones multiclave, locks, watch. Estas usan la versión (y la maquinaria de propiedad que la rodea) para que muchos clientes se pongan de acuerdo sobre lo que ocurrió sin pisarse unos a otros.

Ten presente esa imagen y toda la superficie deja de parecer un cajón de sastre de funcionalidades y empieza a parecer lo que es: un núcleo pequeño y un conjunto de herramientas hechas a medida, cada una de las cuales resuelve una clase concreta de problema por encima de él. Elige según la forma de tu problema, no por el nombre que más se le parezca.

La tabla de decisión​

El resto de este artículo es esa tabla, a cámara lenta.

KV y caché: cuando un valor es solo un valor​

Si lo único que necesitas es poner bytes en algún sitio donde todos los nodos puedan leerlos —un fragmento renderizado, un DTO serializado, una instantánea de configuración— no necesitas una capa de coordinación. PutAsync(key, value) y GetAsync<T>(key) son toda la historia, y en el lado del servidor esos bytes se particionan y replican por ti.

Dos notas honestas. Primera, la expiración no se fija en el momento de escritura. No hay un campo de TTL en las opciones de escritura; fijas un tiempo de vida con una llamada aparte —ExpireAsync(key, ttl)— y lo borras con PersistAsync(key), o lees lo que queda con GetTimeToLiveAsync(key). Segunda, si tu caso de uso es literalmente "una caché distribuida para mi aplicación ASP.NET Core", no te lo montes a mano: registra uno de los paquetes de caché listos para usar y el IDistributedCache del framework (o HybridCache, o el almacén de sesiones) queda respaldado por tu clúster con un cambio de una línea en el arranque y sin código que toque la abstracción de caché.

Usa KV plano cuando el valor no tiene ningún invariante de concurrencia: que gane el último escritor está bien, o solo hay un escritor. No lo uses en cuanto dos escritores puedan competir por la misma clave y te importe que uno sobrescriba al otro en silencio. Ese es el trabajo de la siguiente herramienta.

Compare-and-swap: cuando un valor debe seguir siendo correcto bajo concurrencia​

Un contador con un techo, un saldo que no puede quedar negativo, un objeto de configuración que dos administradores editan a la vez. El fallo que intentas evitar es la actualización perdida: leer, leer, escribir, escribir, y la segunda escritura borra la primera. CAS convierte esa pérdida silenciosa en un conflicto detectado y reintentable: lee un valor y su versión, vuelve a escribir solo si la versión no se ha movido, y obtén un Conflict en vez de una sobrescritura si alguien se te adelantó.

KvResult<int> read = await client.GetAsync<int>("counter:api");
var put = await client.PutAsync(
    "counter:api", read.Value + 1,
    new PutOptions { IfMatchVersion = read.Version });

// put.Status == KvStatus.Success  -> you won this round
// put.Status == KvStatus.Conflict -> someone wrote first; re-read and retry

Ese es todo el mecanismo, y la guía de campo de CAS muestra hasta dónde llega: un limitador de ritmo, una cartera que nunca queda en descubierto bajo mil débitos concurrentes, una reclamación de trabajo con un único ganador (mediante "crear solo si está ausente"), configuración sin actualizaciones perdidas, y el gancho de idempotencia que viene de regalo.

Usa CAS cuando el invariante vive en una clave y quieres correctitud sin mantener un lock. No apuntes a una multitud de escritores a una única clave caliente y esperes que escale: CAS deja ganar deliberadamente a un único escritor por ronda, así que una clave caliente se convierte en un punto de serialización. Particiónala (un bucket por cliente-segundo, un saldo dividido en subsaldos reconciliados) y la contención se disuelve.

Transacciones multiclave: cuando el invariante abarca varias claves​

La línea dura que traza CAS es que es atómico sobre una clave. Mover dinero de la cuenta A a la cuenta B, o mantener un índice secundario en sincronía con el registro al que apunta, y ningún compare-and-swap único cubre ambos. Eso no es motivo para fingirlo con dos escrituras CAS y cruzar los dedos: es el caso exacto para el que existe la transacción multiclave.

Abres una transacción, preparas lecturas y escrituras dentro de ella y haces commit. Por debajo es un commit en dos fases coordinado por el cliente sobre versiones optimistas: las claves pueden vivir en nodos distintos, así que el cliente agrupa el conjunto de escrituras por dueño, cada nodo comprueba que cada clave que leíste sigue en la versión en la que la leíste y toma un lock de corta duración, y solo si todos votan que sí se aplica el conjunto completo. Cualquier versión que se haya movido, y el commit devuelve Conflict sin que nada cambie.

Usa una transacción cuando dos o más claves deben moverse juntas o no moverse en absoluto. No la uses como tu camino de escritura por defecto: es un 2PC de verdad, con viajes de ida y vuelta de prepare/commit y locks de corta duración, más pesado que un único CAS. Si el invariante encaja honestamente en una clave, mantenlo en una clave.

Estructuras de datos nativas: cuando el dato es una colección​

A veces el valor no es un escalar que custodias, sino una forma. Un perfil de usuario es un mapa de campos. Un feed de actividad reciente es una lista. La pertenencia a una etiqueta es un conjunto. Una tabla de clasificación es un ranking. Podrías serializar cada uno como un solo blob y hacerle CAS, pero entonces cada edición de un solo campo reescribe el objeto entero, y has convertido una actualización O(1) en una O(n).

Zaris les da sus propios tipos de colección nativos del lado del servidor —hashes, listas, conjuntos, conjuntos ordenados— donde una operación de un solo campo o de un solo elemento toca únicamente ese elemento en el servidor, no el valor entero en tu proceso. Se particionan y replican como cualquier clave, y como el front-end RESP mapea los mismos comandos de Redis sobre las mismas colecciones del lado del servidor, un servicio .NET y un servicio Python que usan HSET tocan el mismo hash idéntico.

Usa una colección cuando tu patrón de acceso es por elemento: fijar un campo, empujar una entrada, comprobar una pertenencia, leer el top N por puntuación. No recurras a un conjunto ordenado cuando lo que realmente necesitas es un log de eventos ordenado, confirmado y reproducible. Eso es un stream.

Streams: cuando necesitas un log ordenado y reproducible​

Una cola y un log se parecen hasta que un consumidor se cae. Los streams de Zaris son un log de solo anexado de verdad: las entradas reciben IDs monótonos, puedes leer rangos, y un grupo de consumidores reparte el log entre un conjunto de trabajadores, lleva la cuenta del pending de cada trabajador (entregado pero sin confirmar) y permite que otro trabajador reclame lo que uno caído nunca llegó a confirmar. Esa maquinaria de pending y ack es lo que te compra la entrega at-least-once, lo que una notificación de tipo "dispara y olvida" no puede darte.

Usa un stream cuando necesitas eventos durables, ordenados y reproducibles con confirmación explícita y reparto de trabajo: ingesta de pedidos, un outbox, una traza de auditoría a partir de la cual una proyección se reconstruye. No lo uses como cola con prioridades ni como canal de petición/respuesta; es un log, y sus fortalezas son el orden y la reproducción, no el enrutamiento.

Watch, notificaciones y la familia del fan-out: cuando reaccionas al cambio​

Hay varias formas de enterarse de que algo cambió, y no son intercambiables: la diferencia está en si la señal es durable.

La que debes usar desde .NET es Watch: un feed de cambios nativo y a nivel de todo el clúster. Te suscribes a una clave o a un prefijo, opcionalmente incorporas una instantánea inicial para que no haya hueco entre "leer el estado actual" y "suscribirse a los cambios", y recibes eventos a medida que llegan las escrituras:

var (subscription, initial) = await client.Watch.WatchKeyAsync(
    "job:42",
    new WatchOptions { IncludeInitialSnapshot = true },
    evt => Handle(evt));

La propiedad importante es que el watch está registrado en todo el clúster y sobrevive al failover: no está atado al único nodo que casualmente procesó una escritura. Esa es también la razón por la que las notificaciones de keyspace de Redis que Zaris habla (__keyevent@0__ / __keyspace@0__, un simple PSUBSCRIBE desde cualquier cliente Redis) valen más aquí que en una sola máquina Redis: son un puente delgado sobre ese mismo watch replicado, así que un failover no deja caer en silencio el flujo de eventos.

Usa watch/notificaciones de keyspace cuando quieras reaccionar a cambios de estado: invalidar una caché, despertar a un trabajador, refrescar una proyección. No confundas el fan-out de pub/sub de mejor esfuerzo con un feed durable: si necesitas todos los eventos incluso a través de caídas y reinicios, eso es un stream, no una notificación.

Locks: exclusión mutua gruesa, con una advertencia afilada​

Zaris sí tiene un lock distribuido de primera clase: una compuerta con nombre, basada en lease, con un TTL, que se adquiere desde el cliente y se libera al hacer dispose o al expirar por caída:

await using var gate = await client.Locks.AcquireAsync("order:123", TimeSpan.FromSeconds(10));
if (gate is null)
{
    // someone else holds it — back off, do other work, or retry later
    return;
}
// critical section; the lease auto-expires if we crash, and can be renewed

Es genuinamente útil para la exclusión mutua gruesa —evitar que dos planificadores ejecuten el mismo barrido, serializar una tarea de mantenimiento— y el TTL significa que un poseedor caído no bloquea el lock para siempre.

Pero aquí está la advertencia que la versión de brochazo deja fuera, y es la frase más importante de este artículo sobre locks: un lock basado en lease no es una barrera de correctitud. Si tu poseedor se pausa —un parón de GC, una llamada al sistema lenta— el tiempo suficiente para que el lease expire, un segundo poseedor puede adquirir el "mismo" lock mientras el primero todavía cree que lo tiene, y ahora dos trabajadores están en la sección crítica a la vez. Para vivacidad y eficiencia (normalmente solo un trabajador ejecuta el trabajo, la contención es baja) un lock de lease es exactamente lo correcto. Para un invariante de correctitud que jamás debe violarse, no confíes en el lock para imponerlo: imponlo sobre los datos con compare-and-swap o una transacción, de modo que incluso un segundo actor espurio sea rechazado por una comprobación de versión en la escritura.

Usa un lock cuando quieras exclusión mutua gruesa y de mejor esfuerzo y un solapamiento ocasional sea meramente un desperdicio, no un error. Usa CAS en su lugar cuando el solapamiento corrompería datos: deja que sea la versión, no el lock, lo que diga que no.

La parte transversal: propiedad, durabilidad, consistencia​

Tres propiedades se cumplen en cada una de las primitivas de arriba, porque son propiedades del núcleo, no de ninguna herramienta en concreto:

• El dueño cambia, y no tienes que darte cuenta. Cada clave es propiedad de una partición que puede hacer failover, migrar o volver a su sitio. El cliente .NET convierte ese vaivén en una señal tipada y reintentable y reenruta al nuevo dueño, acotado por un presupuesto de intentos y un plazo de reloj de pared, de modo que un PutAsync durante un failover normalmente solo tarda unos milisegundos más y devuelve éxito.
• La durabilidad es por replicación, no por disco. Zaris mantiene los datos en memoria y los hace durables guardando copias en otros nodos. Por eso el factor de replicación no es lo mismo que la tolerancia a fallos: el número solo te protege si la topología coloca de verdad una segunda copia en un nodo que pueda sobrevivir a la pérdida del primero. Toda la columna vertebral de propiedad y recuperación existe para asegurar que ninguna escritura confirmada se pierda mientras la propiedad está en movimiento.
• Las escrituras y lecturas se enrutan al dueño actual. La maquinaria de reintento y reenrutado hace que tus operaciones encuentren el nodo que actualmente posee la clave, de modo que una lectura sigue a una escritura confirmada en vez de adelantarse al cambio de propiedad que acaba de ocurrir.

Ninguna de estas es una primitiva que elijas. Son el suelo sobre el que se apoya cada elección.

El diagrama de flujo​

La versión corta​

La longitud de la lista de funcionalidades nunca fue el punto. Zaris es un núcleo clave-valor versionado, particionado y replicado, más vistas tipadas del lado del servidor (hash, lista, conjunto, conjunto ordenado, stream) y capas de coordinación sobre la versión (CAS, transacciones, locks, watch). Haz coincidir la herramienta con la forma del problema: un escalar bajo contención quiere CAS; un invariante entre claves quiere una transacción; un dato que es una colección quiere la colección correspondiente; los eventos ordenados y durables quieren un stream; reaccionar al cambio quiere watch; la exclusión mutua gruesa quiere un lock; y cualquier cosa que jamás deba violarse quiere su garantía impuesta sobre los datos, con una comprobación de versión, no sobre un lock que puede caducar.

Elige por forma, apóyate en la versión para la correctitud, y el pequeño núcleo soporta una cantidad notable de sistema.

La mayor parte de lo que lees sobre un almacén de datos trata del camino de datos: lecturas, escrituras, el protocolo de cable, lo rápido que va. Pero antes de que nada de eso importe, alguien tiene que poner la cosa en pie: decidir cuántas particiones tiene, cuántas copias de cada una, dónde viven los puertos, arrancarla, confirmar que levantó sana y vigilarla mientras corre. Eso es el plano de control, y en Zaris vive en PowerShell.

Este es un recorrido de operador de día uno. Crearemos un workspace, aprovisionaremos un almacén, lo arrancaremos y luego volveremos a leer su estado en vivo, todo desde el módulo AdminShell. Sin consola web, nada editado a mano. Y como el sentido de una historia de operador es la confianza, seremos explícitos sobre las decisiones que New-ZrStore pone ante ti y lo que cada una cuesta de verdad.

Dos shells, dos planos​

Zaris distribuye su superficie de línea de comandos como dos módulos de PowerShell distintos, y la división no es cosmética: refleja los dos planos del sistema:

• AdminShell es el plano de control. Sus cmdlets aprovisionan, arrancan, detienen, inspeccionan y escalan almacenes. Hablan con el Servicio de gestión de Zaris (el "manager"), no con los nodos de datos directamente. Son los verbos New-ZrStore, Get-ZrNode, Watch-ZrStoreMetrics.
• ClientShell es el plano de datos. Sus cmdlets —Connect-ZrStore, Get-ZrItem, Set-ZrItem— abren una conexión directa a los nodos del almacén y mueven datos clave-valor. Esa es la superficie que usa una aplicación, y es el tema del artículo sobre cadenas de conexión.

Un operador que pone en pie un clúster vive casi por completo en AdminShell. El manager con el que habla es el componente que conoce la forma deseada de cada almacén y conduce los procesos reales hacia ella. Así que lo primero es decirle a tu shell con qué managers hablar.

Paso 0 — un workspace al que apuntar​

Un workspace es un conjunto con nombre de managers a los que apuntan los cmdlets de administración, persistido bajo ~/.clustron para que sobreviva a las sesiones. Creas uno una vez y te cambias a él cada vez que abres un shell:

# Create a workspace pointing at the cluster's managers (does not activate it)
New-ZrWorkspace -Name "prod" -Managers "10.0.0.10:7801","10.0.0.11:7801"

# Make it the active target for this and future sessions
Use-ZrWorkspace prod

Cada endpoint de manager es un observador de un clúster: enuméralos todos y los cmdlets de administración agregan el estado de todo el clúster en vez de lo que sepa una máquina cualquiera. Si tu clúster tiene la seguridad activada, registra un token de administración en el workspace (-Token) o autentica la sesión con Connect-ZrManager -Credential (Get-Credential) -Force, que intercambia un nombre de usuario y una contraseña por un token de sesión. (Connect-ZrManager es la conexión ad-hoc más antigua y sigue funcionando, pero los cmdlets de workspace son el camino actual: son a lo que se corresponden los workspaces guardados de la consola web).

Una bifurcación honesta en el camino aquí: el recorrido de abajo es el modelo supervisor, donde cada manager bifurca y posee sus procesos locales de Zaris —el despliegue nativo/Windows—. Si tus nodos corren en cambio bajo un orquestador como Kubernetes (el modelo attach), el manager no crea procesos; defines el almacén con tu orquestador y lo adoptas con Register-ZrStore en vez de New-ZrStore. New-ZrStore detecta un manager en modo attach y te lo dice en vez de fallar en lo hondo de la pila.

Paso 1 — aprovisionar el almacén​

Este es el cmdlet con las decisiones de verdad dentro. La forma mínima de producción es corta:

New-ZrStore -Name "orders" `
            -ReplicationFactor 2 `
            -BaseClusterPort 7811 `
            -BaseClientPort 7861

Eso crea un almacén llamado orders en cada máquina del workspace, con dos copias de cada partición. Cuatro parámetros llevan el peso, así que seamos precisos con cada uno.

-ReplicationFactor es el número total de copias de cada partición: la primaria más las réplicas. Para producción debe ser como mucho el número de máquinas, de modo que cada copia caiga en una máquina distinta; eso es lo que lo convierte en tolerancia a fallos y no en decoración. En una única máquina de desarrollo la restricción se relaja con un aviso: las réplicas compartirán máquina, lo cual está bien para pruebas y no te compra nada en una caída real. El cmdlet lo dice en voz alta en vez de dejarte creer otra cosa.

-PartitionsPerNode vale 1 por defecto, que es la topología de producción. El recuento total de particiones se deriva de la pertenencia al clúster en vivo —PartitionsPerNode × nodos vivos— y se recalcula en cada cambio de pertenencia, así que no es un número que congeles en el momento de creación. Lo subes por encima de 1 principalmente para pruebas locales, donde quieres observar el comportamiento sensible a particiones (enrutamiento de segmentos, rebalanceo al escalar hacia fuera) en una única máquina sin montar un rack.

-BaseClusterPort / -BaseClientPort son los primeros puertos de dos rangos: el puerto interno de gossip/clúster y el puerto de cara al cliente, incrementados una vez por proceso en cada máquina. El cmdlet valida que los dos rangos no se solapen y se niega a crear un almacén que colisionaría consigo mismo: una pequeña protección que te ahorra un confuso fallo de primer arranque.

Hay tres más que vale la pena conocer porque codifican una verdadera compensación de durabilidad:

New-ZrStore -Name "orders" -ReplicationFactor 3 `
            -BaseClusterPort 7811 -BaseClientPort 7861 `
            -ReplicationMode Sync `
            -WriteQuorumPolicy Majority `
            -AllowReplicaReads

• -ReplicationMode es Async por defecto: la primaria escribe localmente y retorna de inmediato, replicando en segundo plano. Esa es la opción más rápida y el valor por defecto correcto para una caché, pero ten claro que una escritura confirmada bajo Async todavía no tiene garantía de estar en una réplica. Elige Sync y la primaria espera la confirmación de la réplica antes de devolver Ok, cambiando latencia por durabilidad.
• -WriteQuorumPolicy solo muerde bajo Sync: All (toda réplica debe confirmar), Majority (deben confirmar floor(RF/2)+1) o BestEffort (los fallos se registran pero no hacen fallar la escritura).
• -AllowReplicaReads permite a los clientes leer de nodos réplica para repartir la carga de lectura, con la advertencia honesta de que una lectura de réplica puede devolver datos ligeramente obsoletos, porque una réplica puede quedarse detrás de la primaria. Déjalo desactivado cuando necesites leer-tus-escrituras; actívalo cuando prefieras el rendimiento y puedas tolerar el retardo.

Fíjate en lo que dicen los valores por defecto sobre la postura de Zaris: Async + lectura desde la primaria es una caché rápida y correcta por defecto. Los mandos de durabilidad están ahí cuando los necesitas, nombrados sin rodeos, cada uno con un coste que puedes ver.

Paso 2 — arrancarlo, y confirmar que levantó​

Crear un almacén define su forma; no ejecuta los procesos. Start-ZrStore enumera las instancias del almacén en cada manager y las arranca, informando del éxito o fallo por instancia:

Start-ZrStore -Name "orders"

Ahora la parte que separa a un operador de alguien que ejecutó un comando y confió. Get-ZrStore vuelve a leer el estado en vivo del almacén desde los managers: estado general, tiempo activo y el estado de ejecución de cada nodo:

Get-ZrStore orders

Store   : orders
Status  : Running
Uptime  : 2h 14m  (since 2026-10-03 09:41:12)

Nodes (4)
───────────────────────────────────────────
  ● 10.0.0.10-n0   10.0.0.10:7861   Running   up 2h 14m
  ● 10.0.0.10-n1   10.0.0.10:7862   Running   up 2h 14m
  ● 10.0.0.11-n0   10.0.0.11:7861   Running   up 2h 14m
  ● 10.0.0.11-n1   10.0.0.11:7862   Running   up 2h 14m
───────────────────────────────────────────
  Running: 4   Stopped: 0

El estado del almacén es un resumen: Running cuando cada nodo está arriba, Stopped cuando todos están abajo, y Partial cuando algunos están arriba y otros no, que es exactamente el estado que quieres que salga a la superficie a gritos, porque un almacén Partial es uno que arrancó de forma desigual. El tiempo activo es deliberadamente el tiempo de formación del clúster reportado por el núcleo —el arranque de nodo más temprano que sobrevivió al vaivén— no el proceso en ejecución más antiguo, de modo que un almacén que lleva horas sirviendo no reporte mal "unos minutos" solo porque un nodo se reinició.

Para la siguiente capa más abajo, Get-ZrNode muestra los roles y el mapa de particiones:

Get-ZrNode orders

Nodes (4)
─────────────────────────────────────────────────────────────────────────
  ● 10.0.0.10-n0   10.0.0.10:7861   Running   Primary   v7
  ● 10.0.0.10-n1   10.0.0.10:7862   Running   Replica   v7
  ● 10.0.0.11-n0   10.0.0.11:7861   Running   Primary   v7
  ● 10.0.0.11-n1   10.0.0.11:7862   Running   Replica   v7

La columna Primary/Replica es quién posee actualmente cada partición, y el v7 es la versión del mapa de particiones, el número de generación del mapa de propiedad. Cuando todos los nodos coinciden en la misma versión de mapa, la propiedad ha convergido; un nodo atascado en una versión más antigua es un nodo que no se ha puesto al día con el último reparto. Pedir detalle a un único nodo (Get-ZrNode orders 10.0.0.10-n0) expande esto hasta los IDs exactos de particiones primarias y réplicas que posee y cuándo cambió su rol por última vez: la vista a la que recurres cuando acaba de ocurrir un failover y quieres saber dónde aterrizó la propiedad.

Paso 3 — vigilarlo mientras corre​

Una instantánea te dice que el almacén está arriba. Una vista en vivo te dice lo que está haciendo. Watch-ZrStoreMetrics sondea los managers y redibuja una tabla por nodo a intervalos hasta que lo cancelas:

Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2

Coloca primero los contadores del día a día —tasa de peticiones, gets, puts, deletes, recuento de elementos, uso de memoria— y empuja al fondo los diagnósticos avanzados de replicación y sincronización, de modo que los números que miras de un vistazo estén arriba. Los contadores de errores se ponen rojos en cuanto su tasa sube por encima de cero; el rendimiento se tiñe de verde a medida que sube. También señala los cambios de rol en línea: si un failover voltea una primaria a réplica mientras miras, se imprime una línea [ROLE CHANGE] con una marca de tiempo —la señal en vivo de que una partición acaba de cambiar de manos.

Un detalle deliberado que vale la pena destacar, porque es de esas cosas que hacen que una herramienta sea usable a las 2 de la madrugada: la vista obtiene el siguiente fotograma antes de limpiar la pantalla, y un sondeo vacío transitorio mantiene el último buen fotograma en vez de quedarse en blanco. Obtienes una tabla estable, no una parpadeante, por muy lento que sea un manager en responder.

Para redondear el conjunto de solo lectura, Get-ZrInfo reporta la versión instalada, los directorios de instalación y de datos, la ubicación de ambos módulos, el runtime del host, y sondea cada manager en busca de alcanzabilidad. Un manager asegurado que responde 401 se reporta como alcanzable pero necesitando autenticación, no como "caído", de modo que puedas distinguir de un vistazo un problema de red de un token ausente.

Paso 4 — detenerlo, y la forma que subyace a todo​

Bajar un almacén es el espejo del ciclo de vida de arrancarlo:

# Fast whole-store stop (default: a hard kill, since every node goes down together)
Stop-ZrStore -Name orders

# Per-node drain and clean cluster-leave
Stop-ZrStore -Name orders -Graceful

El valor por defecto es un hard kill rápido, que es el comportamiento correcto cuando el almacén entero se va a bajar de golpe: no hay clúster superviviente al que un nodo que se marcha pueda entregar el relevo, así que drenar no compra nada. Usa -Graceful cuando quieras que cada nodo drene y deje el clúster limpiamente, lo cual importa cuando estás deteniendo un subconjunto en vez de todo.

Debajo de cada cmdlet de este artículo hay una idea: un almacén de Zaris tiene una forma deseada —una definición canónica de los servidores y particiones que se supone que debe tener— y el manager corre bajo un modelo supervisor que conduce continuamente los procesos en vivo hacia ella. New-ZrStore escribe esa forma; Start-ZrStore la realiza; Get-ZrStore y Get-ZrNode informan de cuán cerca está la realidad de ella. El mismo modelo es lo que convierte el redimensionado elástico en una línea en vez de un runbook: cambiar la forma deseada con Add-ZrServer / Remove-ZrServer y dejar que el supervisor reconcilie, que es su propia historia de escalado elástico.

El resumen honesto​

El ciclo de vida completo de día uno son cinco comandos y dos lecturas:

New-ZrWorkspace -Name prod -Managers "10.0.0.10:7801","10.0.0.11:7801"
Use-ZrWorkspace prod
New-ZrStore -Name orders -ReplicationFactor 2 -BaseClusterPort 7811 -BaseClientPort 7861
Start-ZrStore -Name orders
Get-ZrStore  orders          # is it Running, and are all nodes up?
Get-ZrNode   orders          # who owns what, and did the map converge?
Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2   # what's it doing now?

Lo que hace de esto un plano de control y no solo un montón de scripts es que los cmdlets reportan verdad en vivo y agregada —no lo que pediste, sino lo que el clúster realmente es— y que las decisiones con consecuencias reales se nombran a plena vista: el factor de replicación frente al recuento de máquinas, Async frente a Sync, las lecturas de réplica frente a la obsolescencia. Pon un almacén en pie, confirma que convergió y mantenlo vigilado, todo sin salir del shell.

La mayoría de los almacenes de datos distribuidos te hacen elegir, pronto y de forma permanente, entre dos mundos. Está el almacén "de verdad": un clúster que despliegas, al que apuntas un cliente por la red y con el que hablas a través de un protocolo de cable. Y está el almacén "falso" al que recurres en las pruebas unitarias: un diccionario en memoria, un mock, un stub hecho a mano que implementa lo justo de la interfaz para que la prueba compile. Los dos no comparten nada. Tu prueba ejercita el comportamiento del stub, no el del almacén, y el hueco entre ellos es exactamente donde se esconden los bugs.

Zaris colapsa esa elección. El mismo cliente tipado de .NET que habla con un clúster distribuido sobre TLS también ejecuta el almacén embebido dentro de tu proceso, sin socket, sin mapa de particiones y sin despliegue, y es el mismo motor de almacén, no un sustituto. Seleccionas cuál obtienes con una única cadena de conexión. Este artículo trata de cómo funciona eso, los casos para los que es genuinamente bueno y la línea dura donde el modo embebido se detiene y empieza un clúster.

Una cadena es todo el interruptor​

Un cliente de Zaris siempre se configura a partir de una cadena de conexión. La cadena lleva el transporte, los endpoints semilla, el nombre del almacén y las opciones. Hay dos formas, y la diferencia entre ellas es la diferencia entre un clúster y un almacén embebido:

zaris://inproc/orders                     # embedded — store runs inside this process
zariss://zaris.mycorp.com:7863/orders     # remote   — connect to a cluster over TLS

El token de host inproc está reservado. Cuando el cliente lo ve, no hay endpoints que marcar, ni transporte que negociar, ni handshake de TLS, ni token: el almacén se sirve desde la memoria del proceso actual. Todo lo demás de tu código permanece idéntico:

// Embedded: no server to start, no port, no network.
IZarisClient store = await ZarisClient.ConnectAsync("zaris://inproc/orders");

// Later, in production — the ONLY line that changed:
IZarisClient store = await ZarisClient.ConnectAsync("zariss://zaris.mycorp.com:7863/orders?ca=/etc/zaris/ca.crt");

En ASP.NET Core es la misma historia a través de la inyección de dependencias: la cadena de conexión suele venir de la configuración, así que el cambio es un valor de configuración, no un cambio de código:

// Program.cs — one registration, driven entirely by the connection string.
builder.Services.AddClustronZaris("orders", builder.Configuration.GetConnectionString("orders")!);

Pon zaris://inproc/orders en appsettings.Development.json y zariss://.../orders en producción, y el mismo binario corre embebido en el portátil de un desarrollador y en clúster en la nube, sin nada recompilado.

Por qué "el mismo cliente" es el punto​

La razón por la que esto importa está en el tipo que recibes de vuelta. ConnectAsync devuelve un IZarisClient —o, para toda la superficie de funcionalidades, IZaris— sin importar el modo. El modo embebido lo sirve una clase llamada ZarisInProcClient, y implementa exactamente las mismas interfaces que el cliente de clúster:

public interface IZaris : IZarisClient
{
    ILeasesClient     Leases     { get; }
    ILocksClient      Locks      { get; }
    ICountersClient   Counters   { get; }
    IScanClient       Scan       { get; }
    IWatchClient      Watch      { get; }
    IPubSubClient     PubSub     { get; }
    IHashClient       Hashes     { get; }
    IListClient       Lists      { get; }
    ISetClient        Sets       { get; }
    ISortedSetClient  SortedSets { get; }
    IStreamClient     Streams    { get; }
}

Cada una de esas superficies está presente en modo embebido, respaldada por el mismo motor de almacén que usa el clúster. Clave/valor Get/Put/Delete, bulk y batch, transacciones multielemento, TTL y expiración, compare-and-swap optimista, Watch para lecturas reactivas, Streams nativos con grupos de consumidores, las estructuras de datos replicadas: todo ello se resuelve contra el almacén embebido, no contra un mock.

Ese motor compartido es lo que hace del almacén embebido un objetivo de prueba fiel. Un bucle de compare-and-swap que depende de que un conflicto se reporte con precisión, una suscripción Watch que debe dispararse cuando una clave cambia, una transacción que debe hacer commit de forma atómica o no hacerlo en absoluto: cada uno se comporta embebido tal como se comporta en clúster, porque es literalmente el mismo camino de código evaluándolo. Un KvStatus.Conflict embebido significa lo que significa en producción. Un stub de diccionario escrito a mano no puede prometer eso.

Qué es realmente el host embebido​

Vale la pena ser preciso sobre qué levanta zaris://inproc, porque los límites honestos caen directamente de ello. El host embebido es una topología fija de un único nodo que posee cada segmento. No hay mapa de particiones, porque solo hay un participante; no hay replicación, porque no hay una segunda copia; no hay transporte, porque no hay un segundo proceso al que llegar.

Lo que sí corre es la maquinaria real que querrías en una prueba. El almacén aprovisiona su segmento de antemano, conecta el servicio de leases, el servicio de watch y las métricas locales, y arranca el barredor de TTL a su cadencia normal, de modo que una clave a la que haces ExpireAsync con un TTL de 50 ms de verdad desaparece, con un temporizador, exactamente como lo haría en un clúster. La expiración, la contabilidad de desalojo, el versionado y las notificaciones de watch están todos activos. Es un almacén completo que resulta tener un tamaño de clúster de uno.

Dentro de un único proceso, los clientes se comparten por nombre de almacén. Dos llamadas ConnectAsync("zaris://inproc/orders") en el mismo proceso se resuelven al mismo almacén embebido, así que un valor que uno escribe, el otro lo lee, útil cuando tu prueba levanta un productor y un consumidor y espera que se vean mutuamente. Nombres de almacén distintos obtienen almacenes distintos; procesos distintos obtienen almacenes embebidos enteramente separados (más sobre ese límite abajo).

Dónde el modo embebido se gana su sitio​

Pruebas unitarias e de integración que ejercitan el almacén real. Este es el uso estrella. Tu repositorio, tu capa de caché, tu coordinador de sagas: pruébalos contra zaris://inproc/test-{Guid}, obtén un almacén aislado y fresco por prueba, y ejercita la semántica genuina: versionado real para tus bucles CAS, expiración de TTL real con un temporizador real, atomicidad de transacción real, eventos de watch reales. Sin contenedor Docker que arrancar en CI, sin puerto que asignar, sin fragilidad de teardown. El almacén se crea en la primera conexión y muere con el proceso.

Aplicaciones de un solo proceso que pueden crecer más adelante. Una aplicación de escritorio, un trabajador en segundo plano, una herramienta de CLI o un servicio pequeño que necesita un almacén estructurado rápido hoy pero podría convertirse en un despliegue en clúster mañana. Empieza embebido. El día que necesites compartir esos datos entre instancias, cambias la cadena de conexión para que apunte a un clúster, y como programaste contra IZaris todo el tiempo, nada más se mueve.

Integraciones que se distribuyen embebidas por defecto. El proveedor de sesiones de Zaris para ASP.NET Core es un ejemplo concreto: conectar Zaris como tu almacén de sesiones es una llamada, y en su ejemplo corre enteramente embebido —

builder.Services.AddZarisSession(options =>
{
    options.ConnectionString = "zaris://inproc/sessions";
});

— lo que significa que un desarrollador puede hacer F5 en la aplicación y tener sesiones funcionando con cero infraestructura, y luego moverse a zariss://.../sessions para un despliegue multiinstancia sin tocar el código de sesión.

Para usar el modo embebido, referencia el paquete Clustron.Zaris.InProc junto al cliente (tiene como objetivo .NET 8). El paquete se autorregistra: el cliente descubre y carga la factoría en proceso en el primer uso, así que simplemente referenciarlo es suficiente. En un ensamblado de pruebas donde prefieras ser explícito, new InProcBootstrap().Register(); lo conecta de forma determinista.

Dónde se detiene honestamente​

El modo embebido es un almacén real, pero es un almacén de un único nodo, en memoria, y fingir lo contrario sería la pelusa de marketing que este blog intenta evitar. Tres límites duros, directos del diseño:

Sin durabilidad. El almacén embebido mantiene los datos en la memoria del proceso y en ningún otro sitio. No hay replicación ni log en disco en este modo: cuando el proceso termina, los datos se han ido. Eso es exactamente lo que quieres para una prueba (pizarra limpia en cada ejecución) y exactamente aquello en lo que no debes confiar para nada que necesites que sobreviva a un reinicio. El modo embebido no es una base de datos con la que respaldes tus datos de producción.

Sin alta disponibilidad, sin escalado hacia fuera. Un clúster de uno tolera la pérdida de cero nodos y escala a la memoria y la CPU de un único proceso. Todas las razones por las que recurrirías a Zaris distribuido —sobrevivir a un fallo de nodo sin pérdida de datos, dimensionar réplicas para durabilidad, escalar el rendimiento entre núcleos y máquinas— simplemente no aplican a un host embebido, porque solo hay uno de él. Cuando necesitas esas propiedades, necesitas el clúster.

Sin compartición entre procesos. El registro en proceso comparte un almacén por nombre dentro de un proceso. Dos procesos distintos que ambos abren zaris://inproc/orders obtienen dos almacenes independientes que no saben nada el uno del otro: no hay socket entre ellos, por definición. En el momento en que tus datos necesiten ser visibles para un segundo proceso o una segunda máquina, el modo embebido es la herramienta equivocada y un clúster es la correcta.

Ninguno de estos es un bug que haya que arreglar; son la definición de "embebido". El valor no es que el almacén en proceso sea secretamente distribuido, sino que el día que necesites distribución, lo único que cambias es la cadena que dice dónde vive el almacén.

La misma promesa, cumplida dos veces​

La propuesta es pequeña y concreta. Escribes tu aplicación contra una única superficie de cliente. En una prueba, o en un portátil, o dentro de una herramienta de un solo proceso, esa superficie la sirve un almacén de Zaris real corriendo en tu propia memoria: rápido de crear, fiel en su semántica, y desaparecido cuando el proceso termina. En producción, el código idéntico habla con un clúster distribuido sobre TLS. El comportamiento que tus pruebas fijaron es el comportamiento que envías, porque nunca fue una implementación distinta, solo un lugar distinto para que el almacén viviera.

Esa es toda la idea detrás de zaris://inproc: el hueco entre "el almacén en mi prueba" y "el almacén en producción" es del ancho de una cadena de conexión, y tú decides, por entorno, en qué lado de él estás.

Hay una pregunta que todo desarrollador acaba por hacerle a un almacén distribuido, normalmente justo después de un informe de error confuso: si escribo un valor y luego lo leo de inmediato, ¿tengo la garantía de ver lo que escribí? Suena como si debiera tener una respuesta de una sola palabra. No la tiene — ni para ningún almacén particionado y replicado, ni para Zaris. La respuesta honesta es "sí, dentro de una partición, porque las lecturas van al mismo propietario único al que fue tu escritura" — y lo interesante es todo lo que se esconde en esa salvedad.

Esta entrada reúne en un solo lugar el modelo de consistencia de Zaris. Hemos escrito sobre las piezas por separado — compare-and-swap optimista, reintentos transparentes ante cambios de propiedad, el op-log reproducible que alimenta a las réplicas, transacciones multiclave. Aquí las enlazamos desde el lado del lector y respondemos a la única pregunta que importa frente a un teclado: cuando leo, ¿qué se me promete en realidad? Incluyendo, sobre todo, dónde se detiene la promesa.

El modelo en una frase​

Zaris es un almacén con tendencia AP cuyo límite de consistencia se traza en torno a la propiedad, no en torno a cada escritura. El plano de datos se mantiene disponible — un nodo solitario sigue sirviendo los segmentos que posee — y la disciplina de escritor único que mantiene las lecturas coherentes se aplica en el plano de propiedad: hay exactamente un propietario activo por partición en cada instante. Las escrituras a una partición se serializan a través de ese único nodo. Deliberadamente no hay quórum ni consenso en la ruta de escritura, y Zaris no afirma tener linealizabilidad estricta global.

Casi todo lo que observa un lector se desprende de ese único hecho estructural, así que conviene hacer explícita la cadena:

key → segment → partition → one runtime active owner

Una clave se asigna determinísticamente por hash a un segmento; un segmento pertenece a una partición; una partición tiene exactamente un propietario activo que acepta sus escrituras y sirve sus lecturas. La propiedad es un arrendamiento (lease) que viaja en el mapa de particiones como (LeaderTerm, OwnershipGeneration) — otorgado por el líder del clúster, duradero entre reinicios y propagado a cada nodo. Ese arrendamiento es lo que garantiza el "exactamente uno" — reemplazó a un esquema anterior de "gana la época más alta" que podía reiniciarse al arrancar y producir brevemente dos nodos creyendo cada uno que poseía la misma partición.

Por qué las lecturas enrutadas al propietario te dan leer-tus-escrituras​

Aquí está la parte que responde a la pregunta inicial. En Zaris, las lecturas se enrutan al propietario activo, el mismo nodo al que fue tu escritura. Los clientes no leen de las réplicas por defecto. Así que cuando haces PutAsync de una clave y luego GetAsync de ella, ambas solicitudes se resuelven — a través de la misma tabla de enrutamiento, construida a partir del mapa de particiones más la instantánea de propiedad en tiempo de ejecución — al mismo nodo propietario, y ese nodo ya tiene tu escritura en su almacén local.

Ese es todo el mecanismo. Leer-tus-escrituras no está añadido como una garantía de sesión ni como una caché del lado del cliente; se desprende del enrutamiento. Lees tus escrituras dentro de una partición porque un único nodo es la autoridad tanto para las lecturas como para las escrituras de esa partición, y las escrituras a él se serializan de una en una. La réplica de ese diagrama podría ir retrasada unos milisegundos respecto al propietario — la replicación tiene una cola asíncrona — pero por defecto nunca lees la réplica, así que ese retraso te resulta invisible.

La salvedad "dentro de una partición" es determinante, y volveremos a lo que excluye.

La versión que se te permite ver​

Cada valor que sirve el propietario lleva dos números monótonos, y son los que hacen de "el mismo valor" una afirmación precisa en lugar de una sensación:

• una Revision propiedad del almacén — un número de secuencia estrictamente creciente que el propietario estampa en cada mutación en orden de confirmación, y
• un ItemVersion por elemento — la versión de esa clave concreta, que es lo que IfMatchVersion protege en una escritura compare-and-swap.

Como el propietario los asigna en orden de confirmación y sirve las lecturas desde ese mismo estado confirmado, las lecturas sucesivas de una clave desde el propietario avanzan la versión hacia adelante, nunca hacia atrás. No leerás la versión 42 y luego la versión 40 un momento después. Esa monotonía es exactamente lo que permite que el bucle CAS sea correcto: un lector ve una versión, calcula a partir de ella y vuelve a escribir condicionado a que siga siendo esa versión. Si el modelo permitiera que las lecturas oscilaran entre versiones, la concurrencia optimista estaría construida sobre arena. Un propietario, revisiones en orden de confirmación, lecturas servidas por el propietario — ese es el fundamento sobre el que se apoya toda la historia de coordinación de la entrada sobre CAS.

La ventana en la que una lectura dice honestamente "todavía no"​

Las lecturas enrutadas al propietario son limpias en estado estable. Los momentos interesantes son las transiciones — una conmutación por error (failover), una migración, un primario preferido recuperándose — porque durante un traspaso el nodo al que enrutarías podría no ser la autoridad en ese momento. La elección de Zaris aquí es la honesta: en lugar de servir una lectura desde un nodo que no es el propietario asentado, devuelve un estado reintentable. Una lectura (o escritura) durante una ventana así puede volver como:

• Moved — tu tabla de enrutamiento está obsoleta; la clave vive ahora en un nodo distinto.
• OwnershipChanging — la propiedad de ese segmento está en transición activa ahora mismo; es un traspaso, no un error de enrutamiento asentado.
• Migrating — el segmento está en plena migración a un nuevo propietario.
• ReplicaSyncPending — este nodo está poniendo al día la copia de un segmento y todavía no servirá una lectura posiblemente incompleta desde él.
• Unavailable — la partición no tiene un propietario alcanzable en este instante.

Ninguno de estos es una excepción que tengas que extraer de un rastreo de pila — son resultados legibles por máquina, y el cliente .NET los trata como transitorios y reintenta reenrutando, refrescando su mapa de clúster y dirigiéndose a quien el mapa ahora nombre como propietario. El efecto es que tu GetAsync simplemente tarda unos milisegundos más y luego devuelve el valor correcto. La decisión de diseño que hay debajo vale la pena enunciarla con claridad: Zaris prefiere hacerte esperar un instante que entregarte una lectura de la que no está seguro de que sea autoritativa. Un "todavía no" reintentable es mejor respuesta que una errónea con aplomo.

Por esto también sobrevive leer-tus-escrituras a una conmutación por error: el trabajo de vallado de escritura (write-fence) implica que una escritura confirmada no se queda atrás en la ventana de traspaso (llegaremos abajo al borde honesto de eso), y la promoción solo convierte a un nodo en propietario una vez que es elegible — de modo que la lectura que se reenruta tras una conmutación por error se reenruta a un nodo que tiene tus datos.

El ajuste que puedes girar — y lo que realmente hace hoy​

Zaris expone una superficie de consistencia de lectura. GetOptions lleva un ReadConsistency de Leader, Quorum o Any, y un almacén tiene una bandera AllowReplicaReads (por defecto desactivada). La intención es el compromiso clásico: dejar que las lecturas se sirvan desde réplicas para repartir la carga de lectura, a cambio de aceptar que una réplica pueda ir retrasada respecto al propietario — una obsolescencia acotada que eliges deliberadamente.

Aquí está el estado actual honesto, porque es exactamente el tipo de cosa que el texto de marketing difuminaría: hoy, las lecturas son solo del propietario. AllowReplicaReads y ReadConsistency.Any son una superficie de configuración y de modelado de solicitudes que existe y fluye a través de la definición del almacén, pero todavía no hay una ruta de código en el servidor que realmente sirva una lectura desde una réplica. En la práctica eso significa que ahora mismo obtienes el extremo fuerte del ajuste — cada lectura es una lectura del propietario, así que leer-tus-escrituras se sostiene — y no obtienes actualmente el comportamiento de lectura-de-réplica-obsoleta, aunque actives la bandera.

¿Por qué mencionar un ajuste que en efecto está fijado en un solo valor? Porque te dice qué permitirá intercambiar el contrato de consistencia, y porque la asimetría importa cuando razonas sobre obsolescencia. Cuando lleguen las lecturas servidas por réplica, activar AllowReplicaReads será el momento en que dejarías de tener garantizado leer-tus-escrituras: una lectura enrutada a una réplica puede observar una versión por detrás de la del propietario, durante todo el tiempo que la cola de replicación asíncrona vaya rezagada. Hasta entonces, la garantía es más simple y más fuerte de lo que sugiere el mando. Preferimos que lo sepas a que supongas que ya estás balanceando lecturas entre réplicas cuando no es así.

Qué significa "confirmado" para el siguiente lector​

Leer-tus-escrituras trata de que tú leas tu propia escritura en el propietario. Una pregunta distinta y más afilada es: una vez que el propietario te dice que una escritura está confirmada, ¿está esa escritura a salvo si el propietario muere después, de modo que el lector que se reenruta al nuevo propietario siga viéndola?

El contrato honesto de confirmación (ack) hoy: una escritura se confirma cuando aterriza en el almacén local del propietario activo. La replicación a las RF−1 réplicas viaja en una cola asíncrona por detrás de esa confirmación. Vale la pena planificar en torno a las consecuencias en lugar de pasarlas por alto:

• Con redundancia 1 — sin réplica sincronizada — una escritura es genuinamente de mejor esfuerzo. No debe tratarse como duradera ante un solo fallo, porque hay exactamente una copia.
• Incluso con réplicas, si se pierde el único propietario activo en la estrecha ventana después de que confirmara una escritura pero antes de que esa escritura llegara a una réplica, la escritura confirmada puede perderse.

La propiedad más fuerte — confirmar solo una vez que la escritura esté en al menos una réplica sincronizada, de modo que una escritura confirmada sobreviva a la pérdida de cualquier nodo — es el objetivo de diseño (la compuerta de confirmación "W1"), todavía no la semántica de confirmación entregada. Es la dirección hacia la que converge el trabajo del backbone de durabilidad, y esa entrada es cuidadosa con la misma distinción: la afirmación fuerte que valida está acotada a escrituras confirmadas, cuando existe una réplica sincronizada, bajo las clases de fallo que induce la ejecución de caos — no un "nada puede perderse nunca" incondicional. Los mecanismos de op-log y migración son cómo una réplica o un nuevo propietario se pone al día con el estado confirmado del propietario en primer lugar; la compuerta de confirmación trata de cuándo se le permite al propietario decir "hecho".

Así que la afirmación precisa de cara al lector es: leer-tus-escrituras en el propietario es sólido; la durabilidad ante fallos cruzados de una escritura confirmada es fuerte-y-cada-vez-más-fuerte, con la salvedad actual expuesta arriba, y un suelo duro en RF1 que ningún almacén puede sortear por ingeniería — una copia es una copia.

Entre particiones, no hay reloj compartido​

El último lugar donde muerde la salvedad "dentro de una partición": no hay ordenamiento ni instantánea global entre particiones. Cada partición se serializa a través de su propio propietario; dos particiones distintas son dos propietarios distintos con dos secuencias de revisión independientes. Si escribes la clave A (partición 1) y luego la clave B (partición 2), un lector concurrente puede observar el nuevo valor de B y el viejo de A, o viceversa — no hay un instante a nivel de clúster en el que "ambas ocurrieron". Las operaciones en bloque (bulk) y por lotes (batch) son por clave por debajo; son cómodas, no atómicas.

Cuando genuinamente necesitas que un invariante abarque varias claves — mover un saldo de A a B, mantener un índice sincronizado con el registro al que apunta — eso es exactamente para lo que existen las transacciones multiclave. Proporcionan aislamiento Serializable sobre una confirmación coordinada por el cliente a través de versiones optimistas, y son la única superficie de atomicidad entre claves. Las lecturas y escrituras multiclave ordinarias no son una transacción y no deben confundirse con una.

Qué se garantiza y qué no​

Dicho con claridad, para que puedas abarcar el modelo entero de una vez:

La forma honesta de todo esto​

Un buen modelo de consistencia no es el que tiene la lista más larga de garantías; es aquel cuyas garantías puedes nombrar de verdad y cuyos bordes puedes ver de verdad. Zaris traza su límite en torno a la propiedad y es franco sobre el compromiso: obtienes leer-tus-escrituras y lecturas monótonas dentro de una partición gratis, porque un propietario sirve ambos lados y te entrega versiones en orden de confirmación; obtienes un "todavía no" reintentable en lugar de una respuesta errónea con aplomo durante un traspaso; y renuncias a la linealizabilidad global y al orden entre particiones, que recuperas explícitamente con una transacción cuando un invariante concreto lo necesita.

Las dos salvedades que vale la pena llevar en la cabeza son las que esta entrada expuso en lugar de suavizar: el ajuste de lectura de réplica está, hoy, en efecto fijado en el valor fuerte, así que eres más consistente de lo que el mando implica; y "confirmado" significa actualmente en el propietario, con la durabilidad completa ante un solo fallo como objetivo que el trabajo de durabilidad está aterrizando, y un suelo genuino en redundancia 1. Conoce esas dos cosas y el resto del modelo es exactamente tan simple como parece: encuentra al propietario, lee tus escrituras.

Para el diseño más profundo, consulta Consistencia y Particionado y replicación en la documentación.

Las notificaciones de keyspace son una de las funciones más útiles de Redis y una de las más silenciosamente frágiles. La idea es preciosa: cada vez que se escribe, borra o expira una clave, el servidor publica un evento en un canal pub/sub bien conocido, y cualquiera a quien le interese puede hacer PSUBSCRIBE y reaccionar — invalidar una caché, despertar a un worker, refrescar una proyección. Sin sondeo, sin un GET en bucle preguntando "¿ya ha cambiado?".

La fragilidad está en la letra pequeña. Las notificaciones de keyspace de Redis son pub/sub de disparar-y-olvidar, emitidas por el nodo que procesó el comando, a los suscriptores conectados a ese mismo nodo. En un despliegue en clúster eso significa que un suscriptor solo se entera de las escrituras que aterrizaron en el nodo al que está conectado, y si ese nodo sufre una conmutación por error, la suscripción — y el flujo de eventos que transportaba — se va con él. La función funciona de maravilla en una sola máquina y se vuelve sutil rápidamente en cuanto hay más de una.

Zaris habla exactamente el mismo protocolo — CONFIG SET notify-keyspace-events, los canales __keyspace@0__ y __keyevent@0__, un PSUBSCRIBE corriente desde cualquier cliente de Redis en cualquier lenguaje. Pero la fontanería de debajo no es una reimplementación del notificador de Redis. Es un puente fino hacia una función que Zaris ya tenía: un watch nativo, a nivel de todo el clúster, replicado. Eso cambia lo que valen las notificaciones.

Activarlo — exactamente al estilo de Redis​

No hay nada específico de Zaris en cómo activas o consumes la función. Apunta cualquier cliente de Redis al front-end RESP y usa los comandos que ya conoces:

# Enable notifications for keyspace (K) and keyevent (E) channels
redis-cli -p 6380 CONFIG SET notify-keyspace-events KEA

# Subscribe to every key-event, cluster-wide
redis-cli -p 6380 PSUBSCRIBE '__keyevent@0__:*'

1) "pmessage"
2) "__keyevent@0__:*"
3) "__keyevent@0__:set"
4) "user:42"

Desde un cliente tipado — aquí StackExchange.Redis — tiene la misma forma, sin ningún SDK de Zaris de por medio:

var mux = await ConnectionMultiplexer.ConnectAsync("localhost:6380");
var sub = mux.GetSubscriber();

await sub.SubscribeAsync(
    new RedisChannel("__keyevent@0__:expired", RedisChannel.PatternMode.Literal),
    (channel, key) => Console.WriteLine($"key expired: {key}"));