Kafka a escala: cómo pasar de un mapa de metro a una arquitectura simplificada
Nuestra plataforma procesa grandes volúmenes de eventos usando Kafka como almacén centralizado, y lo que comenzó siendo una arquitectura relativamente sencilla con algunos consumidores escribiendo sobre una base de datos MySQL compartida, fue evolucionando a medida que aumentaba el volumen de eventos
Para evitar los cuellos de botella de la base de datos principal, los consumidores se fueron moviendo a bases de datos independientes a la vez que fueron apareciendo distintos servicios agregadores encargados de recopilar y consolidar la información distribuida para construir una visión global de los datos. Cada una de estas escisiones resolvía un problema de saturación o lentitud, pero con el tiempo terminamos administrando más de 20 bases de datos y múltiples procesos de agregación, con una complejidad creciente tanto a nivel operativo como de mantenimiento. Consultas que deberían resolverse en segundos podían requerir horas de procesamiento
En esta charla compartiremos cómo rediseñamos la plataforma utilizando Kafka Connect y ClickHouse como núcleo de la capa analítica sin abandonar Kafka. Explicaremos la evolución de la arquitectura, los retos encontrados durante la migración y las lecciones aprendidas. Como resultado, conseguimos soportar picos de hasta 2 millones de mensajes procesados por segundo, podemos hacer consultas prácticamente en tiempo real y hemos simplificado de forma significativa la operación del sistema
Pero esta historia no trata únicamente de tecnología. También hablaremos de cómo la creación de un equipo sólido, la adquisición progresiva de conocimiento y la construcción de una visión compartida fueron elementos fundamentales para afrontar una transformación de este calibre. Porque las arquitecturas evolucionan, pero son las personas quienes hacen posible el cambio
Esta charla presenta la evolución real de una plataforma de procesamiento de eventos que fue creciendo durante años hasta que la complejidad operativa se convirtió en uno de los principales problemas a resolver.
La arquitectura original estaba basada en Kafka y una base de datos MySQL compartida donde persistían datos los distintos consumidores. A medida que aumentó el volumen de eventos, la base de datos central empezó a convertirse en un cuello de botella, así que se optó por distribuir la carga creando bases de datos independientes para distintos consumidores. Esta solución funcionó durante bastante tiempo y permitió continuar escalando la plataforma y absorver más volumen de eventos. Sin embargo, cada nueva necesidad acababa incorporando nuevas bases de datos, nuevos procesos de agregación y nuevos puntos de integración. Lo que inicialmente era una optimización razonable terminó derivando en un ecosistema formado por más de 20 bases de datos y múltiples servicios agregadores encargados persistir los datos en la base de datos principal.
Con el paso del tiempo empezaron a aparecer problemas que probablemente resulten familiares para muchos equipos, por ejemplo los costes operativos derivados de esta infraestructura, la dificultad en la gestión o las dependencias cruzadas entre sistemas, e incluso limitaciones que impactaban gravemente en negocio. Para resolver esta situación decidimos replantear la arquitectura y construir una plataforma analítica centralizada basada en Kafka, Kafka Connect y ClickHouse
Durante la sesión hablaremos de
- cómo evolucionó la arquitectura original
- qué problemas intenta resolver cada una de las decisiones tomadas
- en qué momento la complejidad pasó a ser más costosa que los beneficios obtenidos
- cómo diseñamos y ejecutamos la migración
- los retos encontrados durante el proceso
- los resultados obtenidos tanto en performance como en gestión
- los retos que aún nos quedan pendientes
Sin embargo, una parte importante de esta historia no está en los diagramas. También hablaremos del factor humano detrás de la transformación: cómo se construye un equipo capaz de abordar cambios de gran escala, la importancia de la formación continua, la transferencia de conocimiento y la creación de una cultura de colaboración. Aprendimos que la simplificación tecnológica no sucede de un día para otro y que la cohesión del equipo es tan importante como la arquitectura cuando se trata de hacer evolucionar una plataforma crítica
Porque al final, las tecnologías cambian pero son los equipos los que permiten que sistemas complejos sigan evolucionando de forma sostenible
Esther Yébenes is a Senior DevOps Engineer specialized in infrastructure, automation, and system reliability, with more than 20 years of experience designing, managing, and evolving technology platforms across on-premises, cloud, and hybrid environments.
Throughout her career, she has contributed to large-scale technology transformation initiatives, data center migrations, high-availability architecture deployments, and the adoption of DevOps and SRE practices. She has led engineering teams, driven automation and observability initiatives, and supported organizations in improving the resilience, scalability, and efficiency of their platforms.
Today, she combines deep technical expertise with a people centered approach, believing that system reliability depends as much on the people who design and operate technology as it does on the technology itself.
In addition to her engineering work, Esther is an author and instructor of specialized courses on Linux, automation, and cloud infrastructure, reaching more than 40,000 Spanish and Portuguese speaking students. She is passionate about sharing knowledge and helping professionals build simpler, more robust, and sustainable systems.