How Zalando moved event processing from Postgres to Flink

Zalando, the European fashion e-commerce giant, published a post about migrating its event processing pipeline from PostgreSQL’s LISTEN/NOTIFY mechanism to Apache Flink. The move was driven by scalability needs as the volume of real-time events grew.

Postgres LISTEN/NOTIFY is a lightweight, built-in pub/sub mechanism that works well for small-scale, low-throughput scenarios. But at Zalando’s scale — thousands of events per second across dozens of services — the bottleneck became clear. PostgreSQL’s internal queue for listeners starts to struggle under load, and the architecture doesn’t scale horizontally in a clean way.

Flink, on the other hand, is a stream processing engine designed for exactly this kind of high-throughput, low-latency event pipeline. It handles backpressure, state management, and distributed processing out of the box. The migration likely involved rethinking how events flow between services — from a simple publisher-subscriber model to a more structured stream topology.

This is a classic engineering story: what works at 100 events/sec breaks at 100,000 events/sec. The fix isn’t always a new database. Sometimes it’s moving the logic to the right tool. For smaller teams and startups, the lesson is practical: don’t let a tool you’re comfortable with become a ceiling. Know when to scale up or out.

Why this matters for us: Every time a company like Zalando hits a wall with Postgres and moves to a more scalable system, it’s a reminder that the tools we use to build our side hustles and small businesses have real limits — and knowing when to upgrade is part of the hustle.