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.

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.

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.

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.

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.

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.

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.

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.

La mayoría de las formas de poner autenticación delante de un almacén de datos distribuido acaban por añadir un segundo sistema distribuido para hacerla funcionar: un servicio de autenticación al que llamar, una base de datos de sesiones que replicar, un endpoint de introspección de tokens que cada nodo tiene que alcanzar en la ruta caliente. Aseguraste el almacén y te compraste una nueva dependencia de disponibilidad y una nueva fuente de latencia.

Zaris toma una ruta distinta, y es una deliberadamente aburrida: una clave de firma por clúster, y tokens que cualquier nodo puede verificar por sí mismo. Un token es un JWT firmado con la clave privada del clúster; cada manager y cada nodo tiene la mitad pública y comprueba la firma sin conexión — sin llamada a un servidor de autenticación, sin quórum, sin consulta a una base de datos. La seguridad está desactivada por defecto, y un clúster con ella desactivada se comporta exactamente como uno no asegurado. Esta entrada trata de qué se activa cuando lo enciendes: la forma del token, el modelo de roles-y-ámbitos, los dos planos donde realmente ocurre la aplicación y — porque fingir lo contrario es cómo la gente adquiere una falsa sensación de seguridad — los bordes operativos que es fácil equivocar.

Hay una línea de razonamiento tentadora cuando despliegas un almacén replicado en Kubernetes: fijé replicationFactor: 2, así que cada partición tiene un backup, así que sobrevivo a la pérdida de un nodo. Suena hermético. También es, para un tamaño de clúster sorprendentemente común, incorrecto — e incorrecto de la forma silenciosa que solo aparece la primera vez que un pod realmente muere.

Zaris en Kubernetes almacena la data en memoria y la hace durable por replicación, no por disco: el volumen de data del nodo es un emptyDir, y un pod reprogramado reconstruye a partir de la copia que tiene otro pod. Ese diseño es sólido — pero se apoya enteramente en que haya una copia en otro pod. Que esa copia exista no lo decide replicationFactor por sí solo. Lo decide la aritmética entre tu número de pods y tu factor de replicación, y si te equivocas en esa aritmética el almacén correrá perfectamente, servirá cada lectura y escritura, y en silencio sostendrá una partición que no tiene a dónde replicarse.