Cuando hablamos de Event Sourcing y CQRS, la pregunta sobre dónde almacenar los eventos es clave. Kafka es una opción que sale a menudo, y es fácil pensar que calza perfecto por sus características de log. Pero ojo, hay diferencias importantes entre usar Kafka como un simple log de eventos y como un Event Store dedicado.
Yo he visto cómo esta idea genera confusión. De partida, Kafka es un sistema de mensajería distribuido, tolerante a fallas y que escala brutal. Uno de sus autores originales, de hecho, confirma que funciona muy bien como log para Event Sourcing, y lo usan así en LinkedIn para sistemas como Apache Samza. La capacidad no es el problema.
El punto que a mí me hace más ruido y donde la cosa se complica es la retención. Kafka está diseñado para retener mensajes por un periodo configurable. Por defecto, esos mensajes se eliminan después de un tiempo para liberar espacio. Para un Event Store, necesitas que los eventos se queden, idealmente, para siempre. Eso significa modificar la configuración por defecto.
Puedes establecer la retención indefinida con una configuración como esta:
log.retention.hours: -1Sin embargo, esto va contra la expectativa natural de Kafka de que los mensajes se procesen y eventualmente se descarten. Si bien la performance de Kafka es constante con el tamaño de los datos, almacenar cantidades masivas de datos para siempre requiere una planificación de infraestructura distinta.
Otro desafío que me he topado es la estrategia de los tópicos. En Event Sourcing, la idea es tener un stream (tópico) de eventos por entidad (usuario, producto, etc.) para reconstruir su estado. Si sigues eso al pie de la letra, puedes terminar con una cantidad gigantesca de tópicos en Kafka. Cada tópico es una carpeta en el filesystem y genera presión en ZooKeeper, algo que no siempre se considera al principio.
En mi experiencia, forzar a Kafka a ser un Event Store puro, aunque posible, a veces se siente como sobreingeniería. Terminamos peleando contra sus defaults y su propósito principal. Si bien igual sirve, hay que tener claro que estás adaptando una herramienta excelente para un fin específico que no es su vocación principal. Para eso, existen herramientas diseñadas para ser Event Stores, como EventStoreDB, que resuelven estas particularidades desde el diseño.
Esto de entender bien la intención de diseño de una herramienta es algo que a mí me costó aprender. Al principio, yo intentaba hacer que todo lo que tenía en mente calzara con lo que ya conocía o con lo más popular. Ojalá hubiera sabido antes que, aunque una tecnología pueda hacer algo, eso no significa que sea la mejor o más simple solución para ese problema particular.