Fazer desenvolvimento na cadeia não temer o desempenho não é o maior desafio, mas sim o deadlock na arquitetura de dados.

Muitos projetos avançam rapidamente no início, mas após seis meses começam a estagnar. Parece que não há falta de dinheiro, mas na verdade a estrutura de dados já está travada — uma vez que a lógica de negócios é implementada, cada iteração exige escavar fundo. Alterar um campo pode exigir mexer em toda a camada de aplicação, o que também é uma verdadeira descrição de como muitos projetos na cadeia passam de um crescimento acelerado para uma estagnação total.

A abordagem do Walrus é bastante interessante. Ela reconhece uma realidade: você simplesmente não consegue fazer um design perfeito desde o início. Em vez de insistir na ideia original, é melhor manter a estrutura de dados flexível.

Do ponto de vista do seu design técnico, o núcleo é um modelo de armazenamento baseado em objetos. Cada objeto de dado possui uma identidade única, e as atualizações não são patches, mas uma evolução natural. Com base no desempenho na rede de testes, o sistema suporta múltiplas atualizações no mesmo objeto, que pode chegar a vários MBs, além de poder ser mantido por múltiplos nós, garantindo disponibilidade.

Isso deixa espaço para os desenvolvedores — você não precisa prever exatamente o que acontecerá daqui a três anos. As necessidades mudam, e os dados podem acompanhar essas mudanças. Claro, qual é o custo disso? Essa flexibilidade certamente pode ser mal utilizada, então é preciso que a camada de aplicação mantenha suas próprias restrições.

Mas, para ser honesto, para o software do mundo real, poder corrigir essas questões já é algo valioso. Em comparação a ficar preso por decisões de arquitetura, ter espaço para correções já é um grande avanço.