Filosofía de ingeniería: Salvatore Sanfilippo (antirez)

Ideas clave

• Su principio definitorio es hacer menos: un sistema pequeño y simple que cabe en tu cabeza le gana a uno grande y completo de funciones. Salvatore Sanfilippo, conocido en línea como antirez, construyó Redis como un almacén deliberadamente pequeño: de un solo hilo, en memoria, escrito en C limpio y ferozmente resistente a las funciones que lo harían más difícil de entender. Sus ensayos vuelven una y otra vez al mismo blanco: la complejidad que agregamos sin contabilizar su costo.¹⁵
• Creó Redis en 2009, y se convirtió en una de las bases de datos más usadas del mundo. Redis —el almacén de estructuras de datos en memoria— se publicó por primera vez el 26 de febrero de 2009, nacido de su intento de escalar su startup italiana LLOOGG, un analizador de registros web en tiempo real. Fue su único mantenedor y “dictador benevolente vitalicio” durante once años.¹²
• Redis es de un solo hilo por diseño, y eso es una función, no una limitación. En lugar de perseguir el rendimiento multinúcleo, Redis ejecuta los comandos uno a la vez en un solo hilo, lo que elimina las condiciones de carrera y la sobrecarga de los bloqueos, mantiene el modelo simple y es lo bastante rápido porque, como dice la FAQ de Redis, “no es muy frecuente que la CPU se convierta en tu cuello de botella con Redis, ya que normalmente Redis está limitado por la memoria o por la red”.⁷
• Trata el código como algo escrito por personas para otras personas. En sus ensayos “Writing system software” sostiene que el código fuente “debería leerse, además de ejecutarse, ya que está escrito por humanos para otros humanos”, y que el objetivo de un código legible es “reducir la cantidad de esfuerzo y el número de detalles que el lector debe cargar en su cabeza”.⁴

El principio

“Estamos destruyendo el software al dejar de tener en cuenta la complejidad cuando agregamos funciones u optimizamos alguna dimensión… Estamos destruyendo el software con una cadena absurda de dependencias, que vuelve todo pesado y frágil… Estamos destruyendo el software al crear sistemas que ya no escalan hacia abajo: las cosas simples deberían ser simples de lograr, en cualquier sistema.” — Salvatore Sanfilippo, “We are destroying software”⁵

La mayor parte de la ingeniería es adición. Se pide una función, así que la agregas. Una dependencia te ahorraría una semana, así que la incorporas. Una optimización ayudaría a un solo usuario, así que la integras en el núcleo. Cada paso parece razonable a nivel local, y la suma es un sistema que ya nadie puede sostener entero en su cabeza. El instinto de Sanfilippo corre en la dirección contraria. La línea de código más peligrosa, en su filosofía, es la que escribes sin preguntarte antes si podrías evitar escribirla por completo. Hacer menos. La pregunta nunca es “qué más puede hacer esto”, sino “qué puede dejar de hacer y aun así valer la pena usarlo”.⁵

La expresión más clara del principio es el propio Redis. Es de un solo hilo para la ejecución de comandos, una elección que, en 2009, parecía casi perversa cuando la industria competía por explotar los múltiples núcleos.¹⁷ Pero el razonamiento es el principio convertido en arquitectura. Un único hilo que ejecuta un comando a la vez no tiene condiciones de carrera, ni bloqueos, ni lecturas corruptas, ni errores de dos hilos mutando la misma clave. El modelo mental se reduce a algo sobre lo que una persona realmente puede razonar: los comandos ocurren uno tras otro, en orden, de forma atómica. Y en la práctica no renuncia casi a nada, porque Redis está “limitado por la memoria o por la red” mucho antes de que la CPU se vuelva el límite.⁷ La complejidad de la concurrencia era un costo que antirez se negó a pagar por un beneficio que la mayoría de las cargas de trabajo nunca necesitaron.

Esa negativa viaja con dos compañeras que la hacen asequible. La primera son las primitivas ricas: en lugar de forzar cada problema a través de un único modelo clave-valor, Redis trae cadenas, hashes, listas, conjuntos, conjuntos ordenados y streams como estructuras de datos nativas, de modo que la herramienta adecuada suele estar ya en la caja.¹ La segunda es el código escrito para las personas: él insiste en que el código fuente está “escrito por humanos para otros humanos”, y en que un buen código reduce “el número de detalles que el lector debe cargar en su cabeza”.⁴ Dale a la gente unas pocas primitivas poderosas, haz menos de lo que pide y escríbelo todo de modo que una sola persona aún pueda entenderlo. Ese es el principio, y Redis es la prueba.

Contexto

Salvatore Sanfilippo nació el 7 de marzo de 1977 en Campobello di Licata, Sicilia, Italia.¹ Creció en una zona marginada del sur de Sicilia, cerca de Gela, y se mudó a Palermo a los diecisiete años para estudiar arquitectura, una carrera que nunca terminó, pues desvió su enfoque hacia la informática y aprendió a programar en gran parte por su cuenta.¹ El detalle que vale la pena retener es que es autodidacta, sin ningún título universitario de informática completado; el oficio vino de hacer el trabajo, no de una credencial. Es una forma recurrente en esta serie: el profesional profundo cuya autoridad descansa en lo que construyó, no en lo que le enseñaron.

Su primera marca en el campo fue en seguridad, no en bases de datos. Escribió hping, un generador y analizador de paquetes de código abierto para el protocolo TCP/IP usado en pruebas de seguridad.¹ De forma más trascendente, en 1998 publicó el idle scan, una técnica sigilosa de escaneo de puertos, llamada originalmente “dumb scan”, que determina qué servicios están abiertos en un objetivo “sin dejar rastros que apunten de vuelta a uno mismo”.⁶ Funciona explotando un canal lateral: un host “zombie” inactivo de un tercero, con contadores de IP ID predecibles, que el atacante usa como proxy ciego para inferir las respuestas del objetivo.⁶ La técnica fue lo bastante ingeniosa como para incorporarse a nmap y a hping, donde permanece.⁶ Es el mismo instinto que después definiría a Redis: encontrar el mecanismo elegante que se esconde debajo de un problema aparentemente difícil.

El propio Redis surgió de un problema práctico de escalado. A finales de la década de 2000, Sanfilippo dirigía LLOOGG, una startup italiana que construía un analizador de registros web en tiempo real, y las bases de datos existentes no podían seguir el ritmo de escritura que necesitaba.¹ Así que en 2009 construyó su propio almacén en memoria, y publicó Redis el 26 de febrero de 2009.¹² Se difundió rápido, y los patrocinios siguieron su ascenso: VMware lo contrató en marzo de 2010, Pivotal Software (una escisión de VMware) asumió el patrocinio en mayo de 2013, y Redis Ltd. lo tomó en junio de 2015.¹ Fue el único mantenedor del proyecto y su BDFL durante once años, y luego se retiró el 30 de junio de 2020, sucedido por Yossi Gottlieb y Oran Agra.¹ En diciembre de 2024 regresó a Redis como evangelista y colaborador activo: el raro creador que se fue en la cima y volvió.¹

El trabajo

Redis y sus estructuras de datos: primitivas poderosas, no un almacén clave-valor en blanco

Empecemos por lo que hace diferente a Redis, porque es el principio convertido en producto. La mayoría de los almacenes clave-valor te dan exactamente eso: una clave, un valor que es un blob opaco, y la carga de construir todo lo demás por tu cuenta. Redis, en cambio, trae estructuras de datos ricas como primitivas: cadenas, hashes, listas, conjuntos, conjuntos ordenados y —desde Redis 5.0— streams.¹ Cada una es un tipo nativo del lado del servidor con sus propios comandos, de modo que la estructura de datos que habrías programado a mano en el código de la aplicación ya vive en la base de datos, operada de forma atómica por ese único hilo.¹⁷ La recompensa es que funciones complejas de la aplicación se reducen a un puñado de comandos, porque la primitiva adecuada ya está ahí.

El ejemplo más nítido es el conjunto ordenado (ZSET). Es una colección de miembros únicos, cada uno con una puntuación de punto flotante, y Redis mantiene los miembros “tomados en orden”: el ordenamiento es una propiedad de la estructura de datos misma, no algo que se calcula a pedido.³ Por debajo es una estructura de doble acceso, una skip list emparejada con una tabla hash, lo que da inserciones en O(log(N)) y cero trabajo extra para leer los resultados de vuelta en orden.³ Agregas o actualizas la puntuación de un miembro con ZADD, y lees el rango de un miembro con ZRANK (de menor a mayor) o ZREVRANK (de mayor a menor).³ El caso de uso canónico es el que todo juego necesita y toda base de datos tradicional teme: la tabla de clasificación. Como dice la documentación de Redis, “puedes usar conjuntos ordenados para mantener con facilidad listas ordenadas de las puntuaciones más altas en un juego en línea masivo”.³

Por qué importa como ingeniería: una tabla de clasificación en una base de datos relacional es un verdadero dolor de cabeza. Cada cambio de puntuación significa un UPDATE, y cada consulta de “qué rango tiene este jugador” significa un ORDER BY sobre toda la tabla o un índice mantenido, trabajo que crece con el número de jugadores y que se congestiona bajo carga. En Redis el ordenamiento es intrínseco a la estructura. ZADD cuesta O(log(N)) y ZREVRANK cuesta O(log(N)), y el conjunto ya está ordenado, así que leer los diez primeros es trivial.³ La función no se volvió más fácil porque Redis sea más rápido en el mismo trabajo; se volvió más fácil porque Sanfilippo eligió entregar una primitiva cuya forma es la solución. Eso es “hacer menos” desde el lado del usuario: la base de datos hizo la parte difícil una vez, para que mil aplicaciones nunca tengan que hacerla.

De un solo hilo y en memoria: la simplicidad como centro del diseño

Redis toma dos decisiones que parecen limitaciones y son, de hecho, la fuente de su fortaleza. Está en memoria —el conjunto de datos de trabajo vive en la RAM, con durabilidad superpuesta mediante snapshots y un archivo de solo anexado— y es de un solo hilo para la ejecución de comandos, procesando las solicitudes una a la vez en un solo núcleo.¹⁷ Ambas elecciones son “hacer menos” disfrazado.

La decisión del hilo único es la más contraintuitiva, y vale la pena seguir el razonamiento. Un almacén multihilo tiene que coordinar el acceso concurrente a datos compartidos —bloqueos, atómicos, estructuras sin bloqueo, barreras de memoria—, y esa maquinaria es donde vive una proporción aterradora de los errores de bases de datos y de la latencia impredecible. Al ejecutar un comando a la vez, Redis hace que cada comando sea atómico por construcción: no hay entrelazado que razonar, ni bloqueo que olvidar, ni carrera que depurar.⁷ La FAQ oficial es contundente sobre por qué esto cuesta tan poco: “No es muy frecuente que la CPU se convierta en tu cuello de botella con Redis, ya que normalmente Redis está limitado por la memoria o por la red”, y el hilo único “evita las condiciones de carrera y el cambio de contexto intensivo en CPU asociado a los hilos”.⁷ El rendimiento al que el diseño renuncia es rendimiento que la mayoría de las cargas de trabajo nunca iban a usar; la simplicidad que compra se paga de vuelta en cada línea de código y en cada sesión de depuración a las 3 de la madrugada.

Este es el mismo temperamento que su negativa a agregar complejidad en los ensayos. Plantea el modo de falla con precisión: “Estamos destruyendo el software al dejar de tener en cuenta la complejidad cuando agregamos funciones u optimizamos alguna dimensión”.⁵ El multihilo es exactamente el tipo de optimización —de una sola dimensión, el rendimiento bruto de la CPU— que habría multiplicado la complejidad del sistema a cambio de un beneficio que la mayoría de los usuarios nunca necesitó. Decirle que no mantuvo a Redis como un sistema que una persona podía sostener en su cabeza, que es la propiedad que permitió que una sola persona lo mantuviera durante once años.¹

El oficio: C escrito para las personas, y el alegato a favor de los comentarios

El tercer cuerpo de trabajo no es una función, sino una postura sobre cómo debe escribirse el código. Sanfilippo escribe Redis en C —un lenguaje sin barreras de protección, donde el programador es responsable de cada byte— y trata la legibilidad de ese C como una preocupación de primer orden, no como algo secundario. Su ensayo “Writing system software: code comments” es un argumento inusualmente directo de que el código fuente existe ante todo como comunicación. El código, escribe, “debería leerse, además de ejecutarse, ya que está escrito por humanos para otros humanos”.⁴ El comportamiento ejecutable es solo la mitad del trabajo; la otra mitad es la próxima persona —a menudo un tú futuro— que tiene que entenderlo.

A partir de esa premisa deriva una teoría operativa de los comentarios y la claridad. El objetivo de un código legible, sostiene, es “reducir la cantidad de esfuerzo y el número de detalles que el lector debe cargar en su cabeza mientras lee algo de código”.⁴ Un comentario se gana su lugar cuando elimina un detalle que el lector tendría que reconstruir de otro modo: el porqué detrás de una elección no evidente, la invariante que una función asume, la razón por la que existe un camino rápido. Esto es oficio en el sentido más profundo: no ingenio, sino cuidado por la persona que viene después. Encaja exactamente con el principio de “hacer menos”, porque cuanto más pequeño y simple es el sistema, menos detalles hay que cargar, y más honesto puede ser el código sobre los que quedan.

La misma convicción impulsa su crítica más amplia de hacia dónde se dirige el software. Advierte contra “una cadena absurda de dependencias, que vuelve todo pesado y frágil”, y contra los sistemas “que ya no escalan hacia abajo: las cosas simples deberían ser simples de lograr, en cualquier sistema”.⁵ Redis es su contraargumento hecho ejecutable: un sistema con pocas dependencias, un núcleo pequeño y comprensible, y un diseño donde lo simple permanece simple. El oficio no es un adorno encima de la ingeniería; es la ingeniería.

El método

Lee a través de Redis, el idle scan, los ensayos sobre comentarios y complejidad, y el hilo único, y reaparecen los mismos compromisos. El método de Sanfilippo es menos un eslogan que un conjunto de hábitos permanentes.

Hacer menos: el código más peligroso es el que no necesitabas escribir. El hábito definitorio es la sustracción: antes de agregar una función, una dependencia o una optimización, pregúntate si el sistema puede sobrevivir sin ella. Nombra el modo de falla directamente: complejidad agregada “sin tenerla en cuenta”.⁵ La lección trasciende mucho más allá de las bases de datos: cada línea que no escribes es una línea que no puede romperse, no puede confundir al próximo lector y no tiene que mantenerse durante una década. Es el producto mínimo digno a nivel del núcleo de un sistema: entrega la cosa más pequeña que de verdad valga la pena usar, y defiende su pequeñez contra la presión constante por crecer.

Entrega primitivas poderosas, no política preconstruida. Redis te entrega conjuntos ordenados, streams y hashes —estructuras generales a partir de las cuales construyes tablas de clasificación, colas y limitadores de tasa— en lugar de una función a medida para cada caso.³ El hábito permanente es encontrar el mecanismo subyacente que resuelve toda una clase de problemas y entregar eso, para que la base de datos haga la parte difícil una vez. Es la misma apuesta que Roberto Ierusalimschy hizo con las tablas y metatablas de Lua —dale a la gente palancas afiladas y generales y deja que construyan el resto—, y el parentesco no es accidental, ya que Redis incrusta Lua para hacer exactamente eso.

Elige la simplicidad incluso cuando cuesta rendimiento. El diseño de un solo hilo es el caso más claro: Redis declina el paralelismo multinúcleo para la ejecución de comandos porque la simplicidad —sin carreras, sin bloqueos, atómico por construcción— vale más que los núcleos, y de todos modos la CPU rara vez era el cuello de botella.⁷ La disciplina consiste en saber qué dimensión te restringe de verdad y negarte a pagar complejidad para optimizar una dimensión que no lo hace. Esto es la puerta de la evidencia aplicada al rendimiento: no agregues concurrencia porque suena rápido; mide dónde está realmente el cuello de botella, y la mayoría de las veces no es la CPU.

Escribe código para la persona que lo lee después. El código fuente “está escrito por humanos para otros humanos”, y la tarea de un comentario es reducir los detalles que el lector debe cargar.⁴ El hábito es tratar la legibilidad y los comentarios explicativos como parte de la corrección, no como un lujo que se agrega después, porque un sistema que nadie puede entender es un sistema que nadie puede cambiar de forma segura. Es el mismo oficio centrado en lo humano que Donald Knuth llevó hasta su límite con la programación literaria: el programa es una pieza de escritura dirigida a una persona.

Sostén el sistema entero en una sola cabeza. Redis se mantuvo mantenible por una sola persona durante once años porque se conservó lo bastante pequeño como para ser comprensible por una sola persona.¹ El compromiso permanente es tratar la comprensibilidad por un individuo como una restricción dura de diseño: si el sistema crece más allá de lo que una sola mente puede sostener, has perdido aquello que lo hacía confiable. Es el instinto de oficio en solitario que comparten Linus Torvalds y la tradición Unix: una herramienta con una tarea clara y acotada, poseída y entendida en profundidad en lugar de dispersa y delegada.

Cadena de influencia

Quiénes lo formaron

La tradición de Unix y C. Sanfilippo escribe software de sistemas en C, a mano, con cuidado por cada byte: el linaje de Thompson y Ritchie, donde herramientas pequeñas hacen una sola cosa bien y el lenguaje te da control total y responsabilidad total.⁴ Su insistencia en que el código se escribe para que las personas lo lean es la ética del C legible de esa tradición llevada a la era de las bases de datos. (Influencia formativa)

La cultura hacker de seguridad y redes de finales de la década de 1990. Antes de Redis estuvieron hping y el idle scan: trabajo de paquetes de bajo nivel que exigía un modelo mental preciso de TCP/IP y un ojo de hacker para el canal lateral elegante escondido en un protocolo.¹⁶ Ese hábito de encontrar el mecanismo ingenioso debajo de un problema aparentemente difícil es el mismo que produjo las estructuras de datos de Redis. (Influencia directa)

La restricción de un producto real. Redis no se diseñó en abstracto; fue forzado a existir por la necesidad de LLOOGG de ingerir registros web más rápido de lo que las bases de datos existentes permitían.¹ La presión de un problema concreto y urgente —no el deseo de construir una base de datos por sí misma— es lo que moldeó a Redis para hacer exactamente lo que se necesitaba y poco más. (Influencia formativa)

A quiénes formó

Una generación de arquitecturas de aplicación. Redis se convirtió en la opción por defecto para el caché, el almacenamiento de sesiones, la limitación de tasa, las tablas de clasificación en tiempo real y el pub/sub, tan ubicuo que “ponle Redis delante” es un consejo de ingeniería reflejo, y sus estructuras de datos reconfiguraron la forma en que los desarrolladores piensan sobre lo que una base de datos puede ofrecer.¹³

La escuela de las “primitivas ricas” en los almacenes de datos. Al demostrar que un almacén podía entregar conjuntos ordenados y streams como tipos de primera clase en lugar de valores opacos, Redis empujó a todo el campo hacia estructuras de datos más ricas del lado del servidor y lejos del modelo clave-valor en blanco. (Influencia que definió el campo)

El alegato a favor de los sistemas pequeños, opinados y de un solo autor. Redis se erige como prueba viviente de que un sistema deliberadamente pequeño, mantenido por una sola persona con criterio, puede convertirse en infraestructura global: un argumento que resuena en cada diseño de “hacer menos”, de dependencias mínimas y de núcleo comprensible desde entonces.⁵

El hilo conductor

Sanfilippo se sienta con los minimalistas de esta serie: los constructores que creen que la forma más alta de la ingeniería es la sustracción. Rich Hickey trazó la línea en “Simple Made Easy”: simple significa sin trenzar, un solo pliegue, una sola preocupación, y la complejidad es el entrelazado que agregamos por conveniencia y pagamos para siempre. Redis es ese argumento compilado a C: un solo hilo para que haya una sola preocupación, no la trenza de la concurrencia; primitivas ricas para que la estructura de datos no esté enredada con el código de la aplicación.⁵⁷ Y Roberto Ierusalimschy construyó Lua lo bastante diminuto como para que una sola persona lo comprenda, entregando mecanismos en lugar de política: la misma apuesta que hace Redis con sus primitivas, que es por lo que Redis incrusta Lua para dejar que los usuarios programen de forma atómica contra ellas. Ambos descienden de la economía Unix de Thompson y Ritchie: una herramienta con una tarea clara, escrita en C legible, lo bastante pequeña como para entenderla entera. Donde Hickey dice mantenlo simple, no meramente fácil e Ierusalimschy dice entrega la palanca, no la regla, Sanfilippo dice: haz menos; dale a la gente primitivas poderosas, ejecútalas una a la vez para que el modelo siga cabiendo en tu cabeza, y escribe cada línea para la persona que la lee después. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo de antirez es que el código que no escribo es el código más valioso del sistema. Mi instinto, como el de la mayoría de los constructores, es resolver un problema agregando: una función, una dependencia, un hilo, una optimización ingeniosa. Redis es un argumento de once años de que la adición suele ser el error. El diseño de un solo hilo es el que más pienso: declinó lo que todos decían que tenías que hacer —explotar los núcleos— porque la complejidad que traía no valía un beneficio que su carga de trabajo nunca necesitó.⁷ Cuando construyo algo ahora, la pregunta que tomo prestada es “¿qué puedo negarme a agregar y aun así entregar algo que valga la pena usar?”. Porque cada línea que me salto es una línea que no puede romperse, no puede confundir y no puede exigir mantenimiento durante la próxima década. Hacer menos es más difícil que hacer más, y mucho más duradero.

La segunda lección es que el código es escritura, y el lector es una persona. Es fácil tratar el código fuente como instrucciones para una máquina y detenerse en el momento en que pasan las pruebas. Sanfilippo lo trata como comunicación —“escrito por humanos para otros humanos”— y lo juzga por cuán pocos detalles tiene que cargar el próximo lector en su cabeza.⁴ Eso replanteó los comentarios para mí: no ruido que minimizar, no una disculpa por un código poco claro, sino el lugar donde le entrego a la próxima persona el porqué que nunca podría reconstruir a partir del qué. La disciplina de escribir para el lector es inseparable de la disciplina de hacer menos, porque cuanto más pequeño y simple es el sistema, más honesto puede ser su código, y más probable es que una sola persona, dentro de años, aún pueda sostener la cosa entera en su cabeza. Eso es la calidad es la única variable leído como contención: la cosa pequeña correcta, escrita para las personas y defendida contra el exceso, se convierte en infraestructura sobre la que el mundo puede apoyarse.

Preguntas frecuentes

¿Qué es Redis?

Redis es un almacén de estructuras de datos en memoria y de código abierto, creado por Salvatore Sanfilippo (antirez) y publicado por primera vez el 26 de febrero de 2009.¹² En lugar de almacenar valores opacos como un simple caché clave-valor, ofrece estructuras de datos nativas ricas —cadenas, hashes, listas, conjuntos, conjuntos ordenados y streams— operadas de forma atómica por el servidor.¹ Como el conjunto de datos de trabajo vive en la RAM (con durabilidad mediante snapshots y un archivo de solo anexado), es extremadamente rápido, razón por la cual se convirtió en una de las bases de datos más usadas del mundo para el caché, el almacenamiento de sesiones, las colas, la limitación de tasa, las tablas de clasificación en tiempo real y el pub/sub.¹⁷

¿Quién es antirez?

antirez es el alias en línea de Salvatore Sanfilippo, un programador italiano (siciliano) autodidacta nacido el 7 de marzo de 1977 en Campobello di Licata, Sicilia.¹ Es más conocido como el creador de Redis (2009), que mantuvo como único desarrollador y BDFL durante once años antes de retirarse el 30 de junio de 2020 y regresar al proyecto en diciembre de 2024.¹ Antes de Redis hizo trabajo notable en seguridad: escribió la herramienta de paquetes hping y, en 1998, inventó el idle scan, una técnica sigilosa de escaneo de puertos incorporada después a nmap.¹⁶ Escribe con profundidad sobre la simplicidad, los comentarios de código y el oficio del software de sistemas en su blog en antirez.com.⁴⁵

¿Por qué Redis es de un solo hilo?

Redis ejecuta los comandos uno a la vez en un solo hilo porque la simplicidad vale más que el rendimiento multinúcleo para sus cargas de trabajo. Un solo hilo hace que cada comando sea atómico por construcción: no hay condiciones de carrera, ni bloqueos, ni lecturas corruptas que razonar.⁷ Y cuesta poco en la práctica: como explica la FAQ de Redis, “no es muy frecuente que la CPU se convierta en tu cuello de botella con Redis, ya que normalmente Redis está limitado por la memoria o por la red”, y el hilo único “evita las condiciones de carrera y el cambio de contexto intensivo en CPU asociado a los hilos”.⁷ Es el principio de “hacer menos” de Sanfilippo convertido en arquitectura: declinar la complejidad que optimiza una dimensión (la CPU) que rara vez era la restricción.⁵⁷

¿Qué es un conjunto ordenado de Redis?

Un conjunto ordenado de Redis (ZSET) es una colección de miembros únicos de tipo cadena, cada uno asociado a una puntuación de punto flotante, con los miembros mantenidos automáticamente en orden de puntuación.³ Asignas o actualizas la puntuación de un miembro con el comando ZADD y lees su posición con ZRANK (de menor puntuación a mayor) o ZREVRANK (de mayor a menor); la estructura permanece ordenada en todo momento, así que leer resultados clasificados no requiere ningún trabajo extra de ordenamiento.³ Internamente usa una skip list emparejada con una tabla hash, lo que da inserciones en O(log(N)) y búsquedas de rango en O(log(N)).³ El uso clásico es una tabla de clasificación en tiempo real: una función que es dolorosa en una base de datos relacional pero que se reduce a un par de comandos en Redis porque la primitiva adecuada ya existe.³

Fuentes