¿Qué es el Event Sourcing?
Empezaremos por explicar brevemente en qué consiste el Event Sourcing.
Usar una arquitectura basada en eventos nos puede ayudar a resolver el desafío de administrar los datos distribuidos en una arquitectura de microservicios. Sin embargo, al implementar una arquitectura basada en eventos, actualizar atómicamente la base de datos y publicar un evento puede ser más complejo de lo que parece.
Vamos a tomar de ejemplo un caso de uso en el que crearemos un pedido (order). El servicio que implementa este caso de uso debe realizar dos operaciones: insertar una fila en la tabla ORDERS y publicar un evento «orderCreate». Es esencial que ambas operaciones se realicen atómicamente. Si solo se realizó una operación debido a un error, el sistema no funcionaría correctamente.
La forma estándar de hacer que las operaciones sean atómicas es usar una transacción distribuida que involucre ambas operaciones, la de base de datos y el message broker. Sin embargo, esto no es lo que buscamos.
Una gran solución a este problema es el Event Sourcing. La forma tradicional de persistir una entidad es guardar su estado actual. El Event Sourcing utiliza un enfoque de persistencia diferente, centrado en eventos. El objeto de negocio se persiste almacenando una secuencia de eventos de cambio de estado. Cada vez que cambia el estado de un objeto, se agrega un nuevo evento a la secuencia de eventos. Como se trata de una operación, es intrínsecamente atómica. El estado actual de la entidad se reconstruye reproduciendo su secuencia de eventos.
Ejemplo de Event Sourcing.
Para ver cómo funciona el Event Sourcing, tomaremos de ejemplo la entidad ORDER. Tradicionalmente, cada entidad se asigna a una fila en una tabla ORDERS junto con filas en otra tabla como la tabla ORDER_ITEM_LINE. Pero cuando se usa Event Sourcing, el Servicio de Orders almacena un Order persistiendo sus eventos de cambio de estado: Created, Approved, Shipped, Cancelled. Cada evento contendría datos suficientes para reconstruir el estado de nuestra entidad ORDER.
Los eventos se conservan en un Event Store. El Event Store no solo actúa como una base de datos de eventos, sino que también se comporta como un Message Broker. Proporciona un API que permite que los servicios se suscriban a eventos. Cada evento que se persiste en el Event Store es entregado por él a todos los suscriptores interesados. El Event Store es la columna vertebral de una arquitectura de microservicios Event-Driven.
En esta arquitectura, las request para actualizar una entidad (ya sea una request HTTP externa o un evento publicado por otro servicio) se manejan recuperando los eventos de la entidad desde el Event Store, reconstruyendo el estado actual de la entidad, actualizando la entidad y guardando los nuevos eventos.
Aquí tenemos un esquema de cómo nuestro Order Service procesa una request de actualización de un Order.
¿Qué es Kafka?
Apache Kafka es un sistema de almacenamiento Publish-Suscribe distribuido, particionado y replicado. Estas características, añadidas a su alto rendimiento, nos proporciona gran velocidad en lecturas/escrituras y lo convierten en una excelente herramienta para comunicar streams de información que se generan a gran velocidad y que deben ser gestionados por una o varias aplicaciones. Tiene las siguientes características principales:
- Funciona como un servicio de mensajería, categoriza los mensajes en topics.
- Los procesos que publican se denominan brokers y los subscriptores son los consumidores de los topics.
- Utiliza un protocolo propio basado en TCP y Apache Zookeeper para almacenar el estado de los brokers. Cada broker mantiene un conjunto de particiones (primaria y secundaria) de cada topic.
- Se pueden programar productores/consumidores en diferentes lenguajes: Java, Scala, Python…
- Escalable y tolerante a fallos.
- Desarrollado en Scala.
- Alto rendimiento, incluso con hardware muy modesto Kafka puede soportar cientos de miles de mensajes por segundo.
- Creado por LinkedIn.
Kafka como base para el Event Sourcing.
La unión de los dos elementos de los que estamos hablando, proporciona al Event Sourcing un event store con un rendimiento altísimo gracias a Kafka. Veamos un esquema de cómo quedaría a grandes rasgos nuestra arquitectura de Event Sourcing con Kafka como columna vertebral.
Hay diferentes formas de utilizar Kafka, en este caso nos estamos basando en la plataforma de Confluent en su variante Open Source. Esta plataforma nos ofrece entre otras muchas cosas componentes como el Kafka Connect, que nos sirve para persistir nuestros topics como por ejemplo a MongoDB. Una arquitectura Event Sourcing, junto con la plataforma de Confluent, que utiliza Kafka y que además nos aporta componentes muy útiles, le da al Event Sourcing una vuelta de tuerca más, haciéndolo más potente y versátil, aportándonos toda la velocidad de la lectura/escritura de Kafka.
Para el caso que nos ocupa, Kafka como base de una arquitectura Event Sourcing, nos soluciona el problema de necesitar un store que realiza el guardado de la secuencia de eventos y un message broker que notifique los eventos, ya que con Kafka somos capaces de hacer ambas operaciones nos facilita la integración de las diferentes piezas que necesitemos para nuestra arquitectura.
