La mitad de los bugs de conexión "funciona en dev, se rompe en prod" se reducen a lo mismo: los detalles de conexión se escribieron de tres formas diferentes en tres lugares diferentes. El appsettings.json tenía una lista de hosts, el runbook de operaciones pegó otra en una sesión de PowerShell, y la cadena que alguien copió de una wiki tenía un token obsoleto incrustado directamente en ella.

Zaris saca de la mesa toda esa clase de problema con un único formato de connection string agnóstico de plataforma. La exacta misma cadena funciona cuando tu aplicación .NET la lee de la configuración, cuando un operador se la entrega a un cmdlet de PowerShell, y cuando alguien la copia directamente de la consola web. Una ortografía canónica, en todas partes.

Este post desglosa la cadena parte por parte, muestra las tres formas de usarla, y defiende la única regla que más importa en producción: nunca pongas un token en crudo en la cadena.

La forma más rápida de asegurarte de que TLS se omita es forzar un único modelo de confianza sobre todos. Un desarrollador que ejecuta un almacén en una laptop no quiere levantar una CA. Un banco con una raíz offline en un HSM no quiere que tu herramienta acuñe certificados en absoluto. Entrega un almacén que solo conozca uno de esos casos, y la mitad de tus usuarios desactivarán la seguridad para poder trabajar.

Por eso Zaris no elige por ti. Su confianza TLS es enchufable a lo largo de cuatro modos de autoridad certificadora, desde el autofirmado sin configuración hasta certificados que aprovisionas enteramente fuera de banda. Eliges el modo que coincide con la PKI que ya ejecutas, y Zaris encaja en ella en lugar de pedirte que la reconstruyas a su alrededor. TLS no es una talla única, y tratarlo así es exactamente por qué la seguridad se pospone.

Llevar un almacén distribuido a Kubernetes es fácil. Llevarlo ahí con TLS activado, alcanzable desde fuera del clúster, y un cliente que realmente se conecta es donde la mayoría de los recorridos se detienen silenciosamente. Zaris incluye un chart de Helm, y hemos validado todo el camino — incluida la configuración asegurada y alcanzable externamente — de extremo a extremo en un clúster local.

Este post es ese recorrido. Lo ejecutamos en kind (Kubernetes-in-Docker) para que puedas reproducir cada paso en una laptop, y tomamos el camino más difícil a propósito: TLS habilitado, certificados con los subject alternative names correctos, acceso externo activado, y un cliente conectándose por el endpoint asegurado. A esto lo llamamos la configuración Model B — alcanzable externamente y asegurada, frente a un clúster solo interno.

Una regla de corrección hace tropezar a casi todos los primeros despliegues, y no tiene nada que ver con los certificados: el nombre del almacén en tu connection string debe ser igual al clusterId del despliegue. Señalaremos exactamente dónde muerde eso. Todo lo demás es idéntico en un clúster de producción — kind solo nos da un lugar limpio y desechable para demostrarlo.

Ejecuta Zaris en Kubernetes y el camino feliz es sencillo: los clientes dentro del clúster alcanzan los pods por sus direcciones internas — IPs de pod y nombres de DNS del clúster como zaris-0.zaris.svc — y todo se enruta limpiamente. En el momento en que un cliente vive fuera del clúster, eso se rompe. Una aplicación externa no puede marcar zaris-0.zaris.svc ni una IP de pod; esos nombres y direcciones solo resuelven y enrutan dentro de la red del clúster.

Esto no es una rareza de Zaris — es la división fundamental entre la red interna del clúster y el mundo exterior. Muerde con más fuerza a los clientes conscientes de la topología. Un cliente Redis en modo cluster, o cualquier cliente que descubre nodos y enruta por clave, obtiene un mapa de topología del servidor y se conecta a las direcciones que contiene. Si esas direcciones son internas, un cliente externo recibe un mapa lleno de endpoints que nunca podrá alcanzar.

Zaris resuelve esto con direcciones anunciadas, gestionadas como una "vista de frontera" por listener.

Zaris expone un front-end con protocolo Redis (RESP) para que cualquier cliente Redis, en cualquier lenguaje, pueda apuntar a un clúster de Zaris y usarlo como almacén drop-in. Pero "cualquier cliente Redis" esconde un problema real: los ecosistemas de clientes Redis no se ponen de acuerdo sobre cómo descubrir la topología ni cómo recuperarse cuando un nodo desaparece. Un cliente simple espera un único endpoint estable. Un cliente basado en Sentinel espera preguntarle a un servicio de descubrimiento "¿quién es el master?". Un cliente en modo cluster espera hash slots y redirecciones MOVED/ASK.

Si un almacén hablara solo uno de esos dialectos, toda una clase de clientes quedaría excluida. Por eso el front-end RESP de Zaris admite tres modelos de failover, cada uno acorde a cómo ya espera funcionar una familia concreta de clientes Redis. Eliges el modelo por despliegue; el cliente se comporta exactamente como lo haría contra Redis real.

Una nota honesta de entrada, porque condiciona todo lo que sigue: los tres modelos se sitúan delante del mismo almacén Zaris replicado y particionado. El modelo que elijas cambia la semántica de descubrimiento y redirección — cómo un cliente encuentra un nodo y qué hace cuando uno falla — no dónde reside realmente tu data.

Zaris ya habla en colecciones: hashes, listas, conjuntos y conjuntos ordenados que viven en el servidor y se replican como cualquier otra clave. Los Streams son el quinto tipo, y son el que convierte a Zaris de un almacén en una pieza de infraestructura de mensajería.

Un stream de Zaris es un verdadero registro de solo anexado: las entradas obtienen IDs monótonos, puedes leer rangos y puedes adjuntar grupos de consumidores para que un grupo de trabajadores se reparta el registro entre ellos, haga seguimiento de las entradas pendientes por consumidor y confirme lo que ha procesado. También puedes hacer una lectura bloqueante: un consumidor se detiene y espera a que lleguen nuevas entradas en lugar de iterar en caliente.

Y como es una colección nativa de Zaris, el registro está particionado y replicado exactamente como todo lo demás. Un stream sobrevive a la conmutación por error de un nodo, que es la razón misma para recurrir a la mensajería duradera en primer lugar.

Zaris 1.x almacenaba valores. Zaris 2.0.0 almacena colecciones. Los hashes, listas, conjuntos y conjuntos ordenados son ahora tipos de primera clase, del lado del servidor, con APIs de .NET reales y tipadas y, lo que es igual de importante, se comportan como todo lo demás en el almacén.

Esa última parte es lo que la gente suele entender mal. En muchos sistemas, las "estructuras de datos" son una ilusión del lado del cliente: una biblioteca serializa un diccionario en un blob, lo hace Put y lo llama un hash. Funciona hasta que dos clientes tocan la misma colección a la vez, o hasta que te preguntas qué pasa en una conmutación por error. En Zaris, un hash es un hash en el servidor. Reside en la partición propietaria de su clave, se replica a la réplica de esa partición y sobrevive a la pérdida de un nodo exactamente igual que una clave simple.

Hoy lanzamos Zaris 2.0.0, la mayor versión desde que Zaris alcanzó la disponibilidad general, y la primera con un salto de versión mayor. Convierte a Zaris de un almacén clave/valor rápido y replicado en un servidor completo de estructuras de datos: hashes, listas, conjuntos, conjuntos ordenados, pub/sub y Redis Streams nativos, todos particionados y replicados de la misma forma que ya lo están tus claves.

Y abre la puerta a todos los demás. Cada nodo ahora puede exponer un front-end del protocolo de Redis (RESP), de modo que una aplicación en Python, Ruby, Java, Go —cualquier lenguaje con un cliente de Redis— puede apuntar a Zaris y usarlo como reemplazo directo, sin un SDK nativo y sin reescribir una línea.

El número de versión es un 2, no un 1.x, por una razón: la 2.0.0 cambia el protocolo de cable. Lee la nota de actualización de más abajo antes de implementarlo.

Zaris es un almacén clave/valor distribuido construido de forma nativa para .NET. Sus clientes de primera clase hablan un protocolo binario eficiente y, si tu stack es .NET, esa es la ruta que quieres: APIs asíncronas reales, tipos de .NET, primitivas de coordinación, reemplazos directos de IDistributedCache y HybridCache.

Pero la mayoría de los sistemas no son solo .NET. Hay un servicio en Python haciendo trabajo de datos, un sidecar en Go, un ejecutor de trabajos en Ruby, una pasarela en Node. Reescribir todos ellos sobre un cliente nuevo para probar un almacén nuevo es inviable. Así que, en la 2.0.0, cada nodo de Zaris también puede exponer un listener del protocolo de Redis (RESP2): apunta un cliente de Redis existente a él y usa Zaris como almacén clave/valor de reemplazo directo, en cualquier lenguaje, sin cambiar una sola línea de código del cliente.

Este artículo trata de cómo funciona realmente ese front-end: el modelo de enrutamiento, el modelo de datos, los modelos de conmutación por error y exactamente qué comandos entran y salen.

Redis es rápido. También es, por diseño, monohilo en la ruta de datos: un bucle de eventos, un núcleo, un comando a la vez. Ese es un diseño genuinamente bueno: hace que Redis sea fácil de razonar y elimina toda una categoría de errores de concurrencia. Pero tiene un techo del que no puedes salir a base de dinero. Dale a un motor de un solo bucle de eventos una máquina de 4 núcleos, una de 8 núcleos, una de 32 núcleos, y el rendimiento de lectura acaba en el mismo lugar. Los núcleos extra permanecen inactivos.

Zaris toma el otro camino. Las claves están particionadas y cada partición tiene un propietario, de modo que las lecturas de claves diferentes aterrizan en núcleos diferentes y se ejecutan al mismo tiempo. El resultado es un rendimiento que se mueve cuando añades núcleos: en lugar de una línea plana, una pendiente.