O sistema inicial pode rodar tudo. Com poucos dados, qualquer arquitetura improvisada parece funcionar sem problemas. O verdadeiro teste não é no primeiro dia, mas no momento em que os dados começam a acumular-se de forma frenética.

Vamos fazer uma conta com uma aplicação de complexidade média: gera entre 50-100KB de dados de estado e comportamento por dia. Em um ano? 18-36GB. Além disso, considerando dados derivados e imagens de backup, a escala real dobra. Parece apenas números, mas o problema não está na escrita, e sim no fato de que esses dados simplesmente não param de crescer. Eles são lidos, verificados e combinados repetidamente. Se as relações de referência ficarem confusas, a complexidade de todo o sistema explode exponencialmente.

Essa é a origem do design do Walrus. Ele não imagina que os dados vão parar de crescer, nem espera que os objetos sejam escritos apenas uma vez. A ideia do Walrus é: ao criar um objeto de dados, ele recebe uma identidade estável que nunca muda. Todas as mudanças são registradas como a evolução do estado do mesmo objeto. Em pequena escala, não há diferença aparente, mas com o passar do tempo, essa vantagem de design será ampliada progressivamente.

Observando os dados divulgados nos testes: suporta armazenamento de objetos de nível MB, garantindo disponibilidade por meio de redundância em múltiplos nós, com estabilidade de mais de 99% na rede de testes. A latência de leitura é mantida em nível de segundos, podendo ser acessada diretamente por aplicações reais, não apenas para arquivamento de dados frios.

Mais importante ainda, as mudanças na camada de aplicação. Quando as referências de objetos deixam de mudar com frequência, a aplicação pode fazer otimizações profundas em torno de estruturas de dados estáveis, algo difícil de alcançar em modelos tradicionais de armazenamento.