El sistema inicial puede ejecutar todo. Con pocos datos, cualquier arquitectura improvisada no mostrará problemas. La verdadera prueba no está en el primer día, sino en el momento en que los datos comienzan a acumularse de manera frenética.

Haciendo un cálculo con una aplicación de complejidad media: genera entre 50 y 100KB de datos de estado y comportamiento por día. ¿Un año? 18-36GB. Además, con datos derivados y copias de seguridad, la escala real se duplica. Parece solo un número, pero el problema no está en la escritura, sino en que estos datos simplemente no pueden detenerse. Se leen, verifican y combinan repetidamente. Si las relaciones de referencia se confunden, la complejidad de todo el sistema explotará exponencialmente.

Este es el punto de partida del diseño de Walrus. No espera que los datos dejen de crecer, ni que los objetos solo se escriban una vez. La idea de Walrus es: los objetos de datos obtienen una identificación estable en el momento de su creación, que nunca cambia. Todos los cambios se registran como la evolución del estado del mismo objeto. A pequeña escala, no se notan diferencias, pero con el tiempo, las ventajas de este diseño se amplificarán gradualmente.

Observando los datos revelados en las pruebas: soporta almacenamiento de objetos de nivel MB, garantiza disponibilidad mediante redundancia en múltiples nodos, y en la red de prueba, la disponibilidad general se mantiene por encima del 99%. La latencia de lectura se mantiene en segundos, y las aplicaciones reales pueden acceder directamente, no solo para archivos en frío.

Lo más importante son los cambios a nivel de aplicación. Cuando las referencias de objetos dejan de cambiar con frecuencia, la aplicación puede optimizar profundamente en torno a estructuras de datos estables, algo difícil de lograr en los modelos de almacenamiento tradicionales.