Hacer desarrollo en la cadena no tiene miedo de los cuellos de botella de rendimiento, sino de los bloqueos en la arquitectura de datos.

Muchos proyectos avanzan rápidamente en sus primeras etapas, pero después de medio año empiezan a estancarse. No parece que les falte dinero, en realidad es que la estructura de datos ya está bloqueada: una vez que se establece la lógica del negocio, cada iteración requiere cavar hasta tres pies en la tierra. Cambiar un campo puede implicar modificar toda la capa de aplicación, y esto es una verdadera descripción de cómo muchos proyectos en la cadena pasan de un avance vertiginoso a un estancamiento total.

La idea de Walrus es muy interesante. Reconoce una realidad: no es posible diseñar todo correctamente desde el principio. En lugar de aferrarse a la idea original, es mejor mantener la estructura de datos activa y flexible.

Desde el punto de vista de su diseño técnico, el núcleo es un modelo de almacenamiento a nivel de objetos. Cada objeto de datos tiene una identidad independiente; las actualizaciones no son parches, sino una evolución natural. Según el rendimiento en la red de prueba, el sistema soporta múltiples actualizaciones en el mismo objeto, un solo objeto puede llegar a soportar MBs, y además puede ser mantenido por múltiples nodos, garantizando la disponibilidad.

Esto deja espacio para que los desarrolladores reaccionen: no necesitas predecir cómo será en tres años desde el primer día. Las necesidades cambian, y los datos pueden adaptarse en consecuencia. ¿Y cuál es el costo? Esta flexibilidad inevitablemente será abusada, por lo que debe ser controlada por la capa de aplicación misma.

Pero, para ser honestos, en el mundo real del software, poder corregir las cosas en sí mismo ya es valioso. En comparación con quedar atrapado por decisiones arquitectónicas, tener margen para corregir errores ya es un gran avance.