Cómo Zalando migró su procesamiento de eventos de Postgres a Flink

Zalando, el gigante europeo del e-commerce de moda, publicó un post sobre migrar su pipeline de procesamiento de eventos desde el mecanismo LISTEN/NOTIFY de PostgreSQL hacia Apache Flink. El movimiento fue impulsado por necesidades de escalabilidad a medida que el volumen de eventos en tiempo real creció.

Postgres LISTEN/NOTIFY es un mecanismo pub/sub ligero e integrado que funciona bien para escenarios de pequeña escala y bajo throughput. Pero a la escala de Zalando —miles de eventos por segundo a través de docenas de servicios—, el cuello de botella se hizo evidente. La cola interna de PostgreSQL para listeners empieza a tener problemas bajo carga, y la arquitectura no escala horizontalmente de forma limpia.

Flink, por otro lado, es un motor de procesamiento de streams diseñado exactamente para este tipo de pipeline de eventos de alto throughput y baja latencia. Maneja backpressure, gestión de estado y procesamiento distribuido out of the box. La migración probablemente implicó repensar cómo fluyen los eventos entre servicios —de un modelo simple de publisher-subscriber a una topología de stream más estructurada.

Esta es una historia clásica de ingeniería: lo que funciona a 100 eventos/seg se rompe a 100,000 eventos/seg. La solución no siempre es una nueva base de datos. A veces es mover la lógica a la herramienta correcta. Para equipos pequeños y startups, la lección es práctica: no dejes que una herramienta con la que te sientas cómodo se convierta en un techo. Sabe cuándo escalar hacia arriba o hacia afuera.

### Por qué nos importa:

Cada vez que una empresa como Zalando choca con un muro con Postgres y se mueve a un sistema más escalable, es un recordatorio de que las herramientas que usamos para construir nuestros side hustles y pequeños negocios tienen límites reales —y saber cuándo hacer upgrade es parte del hustle.