Muchos ven los protocolos de almacenamiento y solo se fijan en el rendimiento y la latencia. Pero creo que la verdadera esencia, que todos han entendido al revés, no es la performance, sino si aún tienes espacio para cambiar en el futuro.

Los proyectos en sus etapas iniciales son así: lanzarlos primero y ya, mientras puedan correr, luego ir optimizando lentamente y resolver los problemas históricos después. Suena razonable, pero en cuanto tu base de usuarios, escala de activos y volumen de contenido comienzan a crecer como una bola de nieve, te verás en dificultades.

¿Y por qué? Porque simplemente no puedes moverlo. ¿Quieres cambiar la estructura de datos? No puedes, eso rompería toda la cadena de confianza. ¿Reestructurar la lógica central? Mucho menos, el riesgo es demasiado alto. ¿Quieres limpiar datos históricos redundantes? Eso sería una pesadilla, porque afectaría todo.

Aquí aparece una diferencia clave en el diseño. La forma tradicional es que los objetos se sobrescriben: el nuevo estado reemplaza al anterior. Pero algunas ideas de protocolos permiten que los objetos evolucionen: el nuevo estado se construye sobre el anterior, formando una cadena continua de versiones.

Esto puede parecer un detalle técnico, pero en realidad cambia directamente la forma en que gestionas el ciclo de vida de todo tu proyecto. Una aplicación con 5 actualizaciones de estado diarias, en un año, llega a 1800 evoluciones de versión. La mayoría de los sistemas empiezan a volverse rígidos y a deteriorarse en rendimiento tras unas 200 modificaciones. Pero si el sistema se diseña desde el principio para soportar evoluciones de alta frecuencia, los resultados son completamente diferentes.

Por eso, mi opinión ahora es que este tipo de soluciones de almacenamiento no están pensadas para proyectos nuevos, sino para aquellos que quieren seguir una ruta a largo plazo y necesitan mantener flexibilidad a medida que los usuarios y los activos crecen continuamente.