Filosofia de engenharia: Salvatore Sanfilippo (antirez)

Principais conclusões

• Seu princípio definidor é fazer menos – um sistema pequeno e simples que você consegue manter na cabeça vence um sistema grande e completo de recursos. Salvatore Sanfilippo, conhecido na internet como antirez, construiu o Redis como um armazenamento deliberadamente pequeno: single-threaded, em memória, escrito em C limpo e implacavelmente resistente a recursos que o tornariam mais difícil de entender. Seus ensaios voltam sempre ao mesmo alvo – a complexidade que adicionamos sem medir seu custo.¹⁵
• Ele criou o Redis em 2009, e ele se tornou um dos bancos de dados mais usados do mundo. O Redis – o armazenamento de estruturas de dados em memória – foi lançado pela primeira vez em 26 de fevereiro de 2009, fruto de sua tentativa de escalar sua startup italiana LLOOGG, um analisador de logs web em tempo real. Ele atuou como único mantenedor e “Ditador Benevolente Vitalício” do projeto por onze anos.¹²
• O Redis é single-threaded por design, e isso é um recurso. Em vez de perseguir throughput multicore, o Redis executa os comandos um de cada vez em uma única thread – o que elimina condições de corrida e o overhead de locks, mantém o modelo simples e é rápido o bastante porque, como diz o FAQ do Redis, “não é muito frequente a CPU se tornar seu gargalo com o Redis, já que normalmente o Redis é limitado por memória ou por rede.”⁷
• Ele trata o código como algo escrito por humanos para outros humanos. Em seus ensaios “Writing system software” ele argumenta que o código-fonte “deveria ser lido, e não apenas executado, pois é escrito por humanos para outros humanos”, e que o objetivo de um código legível é “reduzir o esforço e o número de detalhes que o leitor precisa carregar na cabeça.”⁴

O princípio

“Estamos destruindo o software ao não levar mais a complexidade em conta quando adicionamos recursos ou otimizamos alguma dimensão… Estamos destruindo o software com uma absurda cadeia de dependências, deixando tudo inchado e frágil… Estamos destruindo o software ao criar sistemas que não escalam mais para baixo: coisas simples deveriam ser simples de realizar, em qualquer sistema.” – Salvatore Sanfilippo, “We are destroying software”⁵

A maior parte da engenharia é adição. Pedem um recurso, então você o adiciona. Uma dependência economizaria uma semana, então você a inclui. Uma otimização ajudaria um usuário, então você a embute no núcleo. Cada passo parece localmente razoável – e a soma é um sistema que nenhuma pessoa sozinha consegue mais manter na cabeça. O instinto de Sanfilippo aponta para a direção oposta. A linha de código mais perigosa, em sua filosofia, é aquela que você escreve sem antes se perguntar se poderia evitar escrevê-la por completo. Faça menos. A pergunta nunca é “o que mais isto pode fazer”, mas sim “o que isto pode deixar de fazer e ainda valer a pena usar.”⁵

A expressão mais clara do princípio é o próprio Redis. Ele é single-threaded na execução de comandos – uma escolha que, em 2009, parecia quase perversa quando a indústria corria para explorar múltiplos núcleos.¹⁷ Mas o raciocínio é o princípio transformado em arquitetura. Uma única thread executando um comando de cada vez não tem condições de corrida, não tem locks, não tem leituras corrompidas, não tem bugs de duas threads alterando a mesma chave. O modelo mental encolhe para algo sobre o qual uma pessoa consegue realmente raciocinar: os comandos acontecem um após o outro, em ordem, atomicamente. E isso quase nada custa na prática, porque o Redis é “limitado por memória ou por rede” muito antes de a CPU se tornar o limite.⁷ A complexidade da concorrência era um custo que antirez se recusou a pagar por um benefício de que a maioria das cargas de trabalho nunca precisou.

Essa recusa anda acompanhada de dois companheiros que a tornam viável. O primeiro são as primitivas ricas: em vez de forçar todo problema através de um único modelo chave-valor, o Redis traz strings, hashes, listas, sets, sorted sets e streams como estruturas de dados nativas, de modo que a ferramenta certa geralmente já está na caixa.¹ O segundo é o código escrito para humanos: ele insiste que o código-fonte é “escrito por humanos para outros humanos” e que um bom código reduz “o número de detalhes que o leitor precisa carregar na cabeça.”⁴ Dê às pessoas algumas primitivas poderosas, faça menos do que elas pedem e escreva o todo de forma que uma única pessoa ainda consiga entendê-lo. Esse é o princípio, e o Redis é a prova.

Contexto

Salvatore Sanfilippo nasceu em 7 de março de 1977, em Campobello di Licata, Sicília, Itália.¹ Cresceu numa área marginalizada do sul da Sicília, perto de Gela, e mudou-se para Palermo aos dezessete anos para estudar arquitetura – um curso que nunca concluiu, voltando seu foco para a ciência da computação e aprendendo a programar em grande parte por conta própria.¹ O detalhe que vale guardar é que ele é autodidata, sem nenhum diploma universitário concluído em computação; o ofício veio de fazer o trabalho, não de uma credencial. É um formato recorrente nesta série – o praticante profundo cuja autoridade repousa sobre o que construiu, não sobre o que lhe foi ensinado.

Sua primeira marca na área foi em segurança, não em bancos de dados. Ele escreveu o hping, um gerador e analisador de pacotes de código aberto para o protocolo TCP/IP usado em testes de segurança.¹ Mais consequente ainda, em 1998 ele publicou o idle scan – uma técnica furtiva de varredura de portas, originalmente chamada de “dumb scan”, que determina quais serviços estão abertos em um alvo “sem deixar rastros que apontem de volta para si mesmo.”⁶ Ela funciona explorando um canal lateral: um host “zumbi” ocioso de terceiros, com contadores de IP ID previsíveis, que o atacante usa como um proxy cego para inferir as respostas do alvo.⁶ A técnica era engenhosa o suficiente para ser incorporada ao nmap e ao hping, onde permanece.⁶ É o mesmo instinto que mais tarde definiria o Redis – encontrar o mecanismo elegante escondido sob um problema aparentemente difícil.

O próprio Redis surgiu de um problema prático de escala. No fim dos anos 2000, Sanfilippo tocava a LLOOGG, uma startup italiana que construía um analisador de logs web em tempo real, e os bancos de dados existentes não davam conta das taxas de escrita de que ele precisava.¹ Então, em 2009, ele construiu seu próprio armazenamento em memória e lançou o Redis em 26 de fevereiro de 2009.¹² Ele se espalhou rápido, e os patrocínios acompanharam sua ascensão: a VMware o contratou em março de 2010, a Pivotal Software (uma spin-off da VMware) assumiu o patrocínio em maio de 2013, e a Redis Ltd. o assumiu em junho de 2015.¹ Ele atuou como único mantenedor e BDFL do projeto por onze anos e então deixou o posto em 30 de junho de 2020, sucedido por Yossi Gottlieb e Oran Agra.¹ Em dezembro de 2024 ele retornou ao Redis como evangelista e contribuidor ativo – o raro criador que saiu no auge e voltou.¹

O trabalho

O Redis e suas estruturas de dados: primitivas poderosas, não um armazenamento chave-valor em branco

Comece pelo que torna o Redis diferente, porque é o princípio transformado em produto. A maioria dos armazenamentos chave-valor lhe dá exatamente isso – uma chave, um blob opaco de valor e o fardo de construir todo o resto você mesmo. O Redis, em vez disso, traz estruturas de dados ricas como primitivas: strings, hashes, listas, sets, sorted sets e – desde o Redis 5.0 – streams.¹ Cada uma é um tipo nativo, do lado do servidor, com seus próprios comandos, de modo que a estrutura de dados que você teria escrito à mão no código da aplicação já vive no banco de dados, operada atomicamente por aquela única thread.¹⁷ O retorno é que recursos difíceis da aplicação se reduzem a um punhado de comandos, porque a primitiva certa já está ali.

O exemplo mais nítido é o sorted set (ZSET). É uma coleção de membros únicos, cada um carregando uma pontuação de ponto flutuante, e o Redis mantém os membros “tomados em ordem” – a ordenação é uma propriedade da própria estrutura de dados, não algo calculado a cada requisição.³ Por baixo dos panos é uma estrutura de porta dupla, uma skip list combinada com uma hash table, o que dá inserções em O(log(N)) e zero trabalho extra para ler os resultados de volta já ordenados.³ Você adiciona ou atualiza a pontuação de um membro com ZADD e lê a posição de um membro com ZRANK (do menor primeiro) ou ZREVRANK (do maior primeiro).³ O caso de uso canônico é aquele de que todo jogo precisa e que todo banco de dados tradicional teme: o ranking de pontuações. Como diz a documentação do Redis, “você pode usar sorted sets para manter facilmente listas ordenadas das pontuações mais altas em um jogo online de grande porte.”³

Por que isso importa como engenharia: um ranking num banco de dados relacional é um sofrimento genuíno. Cada mudança de pontuação significa um UPDATE, e cada consulta de “qual a posição deste jogador” significa um ORDER BY sobre a tabela inteira ou um índice mantido – trabalho que cresce com o número de jogadores e gera contenção sob carga. No Redis a classificação é intrínseca à estrutura. O ZADD custa O(log(N)) e o ZREVRANK custa O(log(N)), e o set já está ordenado, então ler os dez primeiros é trivial.³ O recurso não ficou mais fácil porque o Redis é mais rápido no mesmo trabalho – ficou mais fácil porque Sanfilippo escolheu entregar uma primitiva cujo formato é a solução. Isso é “fazer menos” do ponto de vista do usuário: o banco de dados fez a parte difícil uma vez, para que mil aplicações nunca tenham de fazê-la.

Single-threaded e em memória: a simplicidade como centro do design

O Redis faz duas escolhas que parecem limitações e são, na verdade, a fonte de sua força. Ele é em memória – o conjunto de dados em uso vive na RAM, com durabilidade acrescentada por meio de snapshots e de um append-only file – e é single-threaded na execução de comandos, processando as requisições uma de cada vez em um único núcleo.¹⁷ Ambas as escolhas são “fazer menos” disfarçado.

A decisão de uma única thread é a mais contraintuitiva, e vale a pena seguir o raciocínio. Um armazenamento multithread precisa coordenar o acesso concorrente a dados compartilhados – locks, atômicos, estruturas lock-free, barreiras de memória – e é nessa maquinaria que mora uma fatia assustadora dos bugs de banco de dados e da latência imprevisível. Ao executar um comando de cada vez, o Redis torna todo comando atômico por construção: não há intercalação a considerar, não há lock para esquecer, não há corrida para depurar.⁷ O FAQ oficial é direto sobre por que isso custa tão pouco: “não é muito frequente a CPU se tornar seu gargalo com o Redis, já que normalmente o Redis é limitado por memória ou por rede”, e ser single-threaded “evita condições de corrida e a troca de contexto pesada de CPU associada às threads.”⁷ O throughput de que o design abre mão é throughput que a maioria das cargas de trabalho nunca iria usar; a simplicidade que ele compra é recompensada em cada linha de código e em cada sessão de depuração às 3 da manhã.

Esse é o mesmo temperamento de sua recusa, nos ensaios, a adicionar complexidade. Ele descreve o modo de falha com precisão: “Estamos destruindo o software ao não levar mais a complexidade em conta quando adicionamos recursos ou otimizamos alguma dimensão.”⁵ O multithreading é exatamente o tipo de otimização – de uma dimensão, o throughput bruto de CPU – que teria multiplicado a complexidade do sistema por um benefício de que a maioria dos usuários nunca precisou. Dizer não a isso manteve o Redis um sistema que uma pessoa conseguia manter na cabeça, que é a propriedade que permitiu a uma pessoa mantê-lo por onze anos.¹

O ofício: C escrito para humanos, e a defesa dos comentários

O terceiro corpo de trabalho não é um recurso, mas uma postura sobre como o código deve ser escrito. Sanfilippo escreve o Redis em C – uma linguagem sem grades de proteção, em que o programador é responsável por cada byte – e trata a legibilidade desse C como uma preocupação de primeira ordem, não como um detalhe posterior. Seu ensaio “Writing system software: code comments” é um argumento extraordinariamente direto de que o código-fonte existe primordialmente como comunicação. O código, escreve ele, “deveria ser lido, e não apenas executado, pois é escrito por humanos para outros humanos.”⁴ O comportamento executável é apenas metade do trabalho; a outra metade é a próxima pessoa – muitas vezes um você do futuro – que precisa entendê-lo.

A partir dessa premissa ele deriva uma teoria prática de comentários e clareza. O objetivo de um código legível, argumenta ele, é “reduzir o esforço e o número de detalhes que o leitor precisa carregar na cabeça ao ler algum código.”⁴ Um comentário conquista seu lugar quando remove um detalhe que o leitor teria, de outro modo, de reconstruir – o porquê por trás de uma escolha não óbvia, a invariante que uma função assume, a razão pela qual existe um caminho rápido. Isso é ofício no sentido mais profundo: não esperteza, mas cuidado com o humano que vem depois. Combina exatamente com o princípio do “fazer menos”, porque quanto menor e mais simples o sistema, menos detalhes há para carregar, e mais honesto o código pode ser quanto aos que restam.

A mesma convicção move sua crítica mais ampla sobre o rumo do software. Ele alerta contra “uma absurda cadeia de dependências, deixando tudo inchado e frágil”, e contra sistemas “que não escalam mais para baixo: coisas simples deveriam ser simples de realizar, em qualquer sistema.”⁵ O Redis é seu contra-argumento tornado executável – um sistema com poucas dependências, um núcleo pequeno e compreensível, e um design em que a coisa simples permanece simples. O ofício não é decoração por cima da engenharia; ele é a engenharia.

O método

Leia transversalmente o Redis, o idle scan, os ensaios sobre comentários e complexidade, e a única thread, e os mesmos compromissos se repetem. O método de Sanfilippo é menos um slogan e mais um conjunto de hábitos permanentes.

Faça menos – o código mais perigoso é o código que você não precisava escrever. O hábito definidor é a subtração: antes de adicionar um recurso, uma dependência ou uma otimização, pergunte se o sistema consegue sobreviver sem isso. Ele nomeia o modo de falha diretamente – complexidade adicionada “sem levá-la em conta.”⁵ A lição se transfere para muito além de bancos de dados: cada linha que você não escreve é uma linha que não pode quebrar, não pode confundir o próximo leitor e não terá de ser mantida por uma década. É o produto minimamente digno no nível do núcleo de um sistema – entregue a menor coisa que genuinamente valha a pena usar, e defenda sua pequenez contra a pressão constante de crescer.

Entregue primitivas poderosas, não política pré-construída. O Redis lhe dá sorted sets, streams e hashes – estruturas gerais a partir das quais você constrói rankings, filas e limitadores de taxa – em vez de um recurso sob medida para cada caso.³ O hábito permanente é encontrar o mecanismo subjacente que resolve uma classe inteira de problemas e entregar isso, para que o banco de dados faça a parte difícil uma vez. É a mesma aposta que Roberto Ierusalimschy fez com as tables e metatables de Lua – dê às pessoas alavancas afiadas e gerais e deixe-as construir o resto – e o parentesco não é acidental, já que o Redis embute Lua para fazer exatamente isso.

Escolha a simplicidade mesmo quando ela custa throughput. O design single-threaded é o caso mais claro: o Redis recusa o paralelismo multicore na execução de comandos porque a simplicidade – sem corridas, sem locks, atômico por construção – vale mais do que os núcleos, e a CPU raramente era o gargalo de qualquer forma.⁷ A disciplina é saber qual dimensão de fato te restringe e recusar pagar com complexidade para otimizar uma dimensão que não restringe. É a barreira de evidências aplicada ao desempenho: não adicione concorrência porque ela soa rápida; meça onde o gargalo realmente está, e na maioria das vezes não é a CPU.

Escreva o código para o humano que o lê em seguida. O código-fonte “é escrito por humanos para outros humanos”, e o trabalho de um comentário é reduzir os detalhes que o leitor precisa carregar.⁴ O hábito é tratar a legibilidade e os comentários explicativos como parte da correção, não como um agrado a acrescentar depois – porque um sistema que ninguém consegue entender é um sistema que ninguém consegue mudar com segurança. É o mesmo ofício centrado no humano que Donald Knuth levou ao limite com a programação literária: o programa é uma peça de escrita dirigida a uma pessoa.

Mantenha o sistema inteiro em uma só cabeça. O Redis permaneceu mantível por uma única pessoa por onze anos porque foi mantido pequeno o suficiente para ser compreensível por uma única pessoa.¹ O compromisso permanente é tratar a compreensibilidade-por-um-indivíduo como uma restrição de design rígida – se o sistema cresce além do que uma só mente consegue abarcar, você perdeu aquilo que o tornava confiável. É o instinto de ofício solo que Linus Torvalds e a tradição Unix compartilham: uma ferramenta com um trabalho claro e delimitado, possuída e entendida em profundidade em vez de espraiada e delegada.

Cadeia de influência

Quem o moldou

A tradição Unix e C. Sanfilippo escreve software de sistema em C, à mão, com cuidado por cada byte – a linhagem de Thompson e Ritchie, em que ferramentas pequenas fazem uma coisa bem e a linguagem lhe dá controle total e responsabilidade total.⁴ Sua insistência de que o código é escrito para humanos lerem é a ética do C legível dessa tradição carregada para a era dos bancos de dados. (Influência formativa)

A cultura hacker de segurança e redes do fim dos anos 1990. Antes do Redis houve o hping e o idle scan – trabalho de baixo nível com pacotes que exigia um modelo mental preciso de TCP/IP e um olhar de hacker para o canal lateral elegante escondido em um protocolo.¹⁶ Esse hábito de encontrar o mecanismo engenhoso sob um problema aparentemente difícil é o mesmo que produziu as estruturas de dados do Redis. (Influência direta)

A restrição de um produto real. O Redis não foi projetado no abstrato; foi forçado a existir pela necessidade da LLOOGG de ingerir logs web mais rápido do que os bancos de dados existentes permitiam.¹ A pressão de um problema concreto e urgente – não o desejo de construir um banco de dados por si só – é o que moldou o Redis para fazer exatamente o necessário e pouco mais. (Influência formativa)

Quem ele moldou

Uma geração de arquiteturas de aplicação. O Redis se tornou o padrão para cache, armazenamento de sessão, limitação de taxa, rankings em tempo real e pub/sub – tão onipresente que “ponha o Redis na frente” é conselho reflexo de engenharia, e suas estruturas de dados remodelaram a forma como os desenvolvedores pensam o que um banco de dados pode oferecer.¹³

A escola de armazenamentos de “primitivas ricas”. Ao provar que um armazenamento podia entregar sorted sets e streams como tipos de primeira classe em vez de valores opacos, o Redis empurrou o campo inteiro em direção a estruturas de dados mais ricas do lado do servidor e para longe do modelo chave-valor em branco. (Influência que definiu o campo)

A defesa de sistemas pequenos, opinativos e de autor único. O Redis se mantém como prova viva de que um sistema deliberadamente pequeno, mantido por uma pessoa com bom gosto, pode se tornar infraestrutura global – um argumento que ecoa em todo design de “fazer menos”, de dependências mínimas e de núcleo compreensível desde então.⁵

O fio condutor

Sanfilippo se senta com os minimalistas desta série – os construtores que acreditam que a forma mais alta de engenharia é a subtração. Rich Hickey traçou a linha em “Simple Made Easy”: simples significa destrançado, uma só dobra, uma só preocupação, e complexidade é a intercalação que adicionamos por conveniência e pagamos para sempre. O Redis é esse argumento compilado para C – uma única thread para que haja uma só preocupação, não a trança da concorrência; primitivas ricas para que a estrutura de dados não fique enredada com o código da aplicação.⁵⁷ E Roberto Ierusalimschy construiu Lua pequena o bastante para uma só pessoa compreender, entregando mecanismos em vez de política – a mesma aposta que o Redis faz com suas primitivas, razão pela qual o Redis embute Lua para deixar os usuários fazerem scripts atomicamente contra elas. Ambos descendem da economia Unix de Thompson e Ritchie: uma ferramenta com um trabalho claro, escrita em C legível, pequena o suficiente para ser entendida por inteiro. Onde Hickey diz mantenha simples, não meramente fácil e Ierusalimschy diz entregue a alavanca, não a regra, Sanfilippo diz: faça menos – dê às pessoas primitivas poderosas, execute-as uma de cada vez para que o modelo continue na sua cabeça, e escreva cada linha para o humano que a lê em seguida. (Ponte da série)

O que eu levo disto

A lição que guardo de antirez é que o código que eu não escrevo é o código mais valioso do sistema. Meu instinto, como o da maioria dos construtores, é resolver um problema adicionando – um recurso, uma dependência, uma thread, uma otimização engenhosa. O Redis é um argumento de onze anos de que a adição costuma ser o erro. O design single-threaded é aquele em que mais penso: ele recusou aquilo que todos diziam que você tinha de fazer – explorar os núcleos – porque a complexidade que isso trazia não valia um benefício de que sua carga de trabalho nunca precisou.⁷ Quando construo algo hoje, a pergunta que tomo emprestada é “o que eu posso me recusar a adicionar e ainda assim entregar algo que valha a pena usar?” Porque cada linha que eu pulo é uma linha que não pode quebrar, não pode confundir e não pode exigir manutenção pela próxima década. Fazer menos é mais difícil do que fazer mais, e muito mais durável.

A segunda lição é que código é escrita, e o leitor é uma pessoa. É fácil tratar o código-fonte como instruções para uma máquina e parar no instante em que os testes passam. Sanfilippo o trata como comunicação – “escrito por humanos para outros humanos” – e o julga por quão poucos detalhes o próximo leitor tem de carregar na cabeça.⁴ Isso reenquadrou os comentários para mim: não ruído a ser minimizado, não uma desculpa por um código pouco claro, mas o lugar onde entrego à próxima pessoa o porquê que ela nunca conseguiria reconstruir a partir do quê. A disciplina de escrever para o leitor é inseparável da disciplina de fazer menos, porque quanto menor e mais simples o sistema, mais honesto seu código pode ser – e mais provável que uma pessoa, daqui a anos, ainda consiga manter o todo na cabeça. Isso é qualidade é a única variável lido como contenção: a coisa certa e pequena, escrita para humanos e defendida contra o inchaço, torna-se infraestrutura sobre a qual o mundo pode se apoiar.

Perguntas frequentes

O que é o Redis?

O Redis é um armazenamento de estruturas de dados em memória, de código aberto, criado por Salvatore Sanfilippo (antirez) e lançado pela primeira vez em 26 de fevereiro de 2009.¹² Em vez de armazenar valores opacos como um cache chave-valor comum, ele oferece estruturas de dados nativas e ricas – strings, hashes, listas, sets, sorted sets e streams – operadas atomicamente pelo servidor.¹ Como o conjunto de dados em uso vive na RAM (com durabilidade via snapshots e um append-only file), ele é extremamente rápido, razão pela qual se tornou um dos bancos de dados mais usados do mundo para cache, armazenamento de sessão, filas, limitação de taxa, rankings em tempo real e pub/sub.¹⁷

Quem é antirez?

antirez é o apelido online de Salvatore Sanfilippo, um programador autodidata italiano (siciliano) nascido em 7 de março de 1977 em Campobello di Licata, na Sicília.¹ Ele é mais conhecido como o criador do Redis (2009), que manteve como desenvolvedor único e BDFL por onze anos antes de deixar o posto em 30 de junho de 2020 e retornar ao projeto em dezembro de 2024.¹ Antes do Redis, fez um trabalho notável em segurança – escrevendo a ferramenta de pacotes hping e, em 1998, inventando o idle scan, uma técnica furtiva de varredura de portas mais tarde incorporada ao nmap.¹⁶ Ele escreve com profundidade sobre simplicidade, comentários de código e o ofício do software de sistema em seu blog em antirez.com.⁴⁵

Por que o Redis é single-threaded?

O Redis executa os comandos um de cada vez em uma única thread porque a simplicidade vale mais do que o throughput multicore para suas cargas de trabalho. Uma única thread torna todo comando atômico por construção – não há condições de corrida, não há locks e não há leituras corrompidas a considerar.⁷ E isso custa pouco na prática: como explica o FAQ do Redis, “não é muito frequente a CPU se tornar seu gargalo com o Redis, já que normalmente o Redis é limitado por memória ou por rede”, e ser single-threaded “evita condições de corrida e a troca de contexto pesada de CPU associada às threads.”⁷ É o princípio do “fazer menos” de Sanfilippo como arquitetura – recusar a complexidade que otimiza uma dimensão (CPU) que raramente era a restrição.⁵⁷

O que é um sorted set do Redis?

Um sorted set do Redis (ZSET) é uma coleção de membros string únicos, cada um associado a uma pontuação de ponto flutuante, com os membros mantidos automaticamente em ordem de pontuação.³ Você define ou atualiza a pontuação de um membro com o comando ZADD e lê sua posição com ZRANK (do menor primeiro) ou ZREVRANK (do maior primeiro); a estrutura permanece ordenada o tempo todo, então ler resultados classificados não exige nenhum trabalho extra de ordenação.³ Internamente, ele usa uma skip list combinada com uma hash table, dando inserções em O(log(N)) e buscas de posição em O(log(N)).³ O uso clássico é um ranking em tempo real – um recurso que é doloroso em um banco de dados relacional, mas se reduz a um par de comandos no Redis porque a primitiva certa já existe.³

Fontes