How bpost uses Event-Driven Architecture to scale its logistics operations

Belgium's biggest postal operator processes millions of parcels a day. That sounds like a logistics challenge. It's also, increasingly, a data challenge.

When a parcel enters a distribution center, leaves it, gets sorted, gets rerouted, or ends up on a delivery round, every single step generates information that other systems need, immediately. At the scale bpost operates, "eventually consistent" doesn't cut it. Neither does an architecture that was designed for a different era.

That's why bpost started a digital transformation built around event-driven architecture (EDA), with Apache Kafka at its core. And it's why they brought us at Cymo in to help make it happen.

Key takeaway #1

A central database coordinating logic across your entire network isn't a scalability problem you can patch. EDA gives each domain ownership of its own events.

Key takeaway #2

Large digital transformations need early, visible wins. bpost's first production applications were deliberately small. Provable success is what brings people along.

Key takeaway #3

The real return on an EDA backbone isn't efficiency on existing processes. It's how cheap new business ideas become to try once the infrastructure is there.

How bpost uses Event-Driven Architecture to scale its logistics operations

Belgium's biggest postal operator processes millions of parcels a day. That sounds like a logistics challenge. It's also, increasingly, a data challenge.

When a parcel enters a distribution center, leaves it, gets sorted, gets rerouted, or ends up on a delivery round, every single step generates information that other systems need, immediately. At the scale bpost operates, "eventually consistent" doesn't cut it. Neither does an architecture that was designed for a different era.

That's why bpost started a digital transformation built around event-driven architecture (EDA), with Apache Kafka at its core. And it's why they brought us at Cymo in to help make it happen.

Key takeaway #1

A central database coordinating logic across your entire network isn't a scalability problem you can patch. EDA gives each domain ownership of its own events.

Key takeaway #2

Large digital transformations need early, visible wins. bpost's first production applications were deliberately small. Provable success is what brings people along.

Key takeaway #3

The real return on an EDA backbone isn't efficiency on existing processes. It's how cheap new business ideas become to try once the infrastructure is there.

How bpost uses Event-Driven Architecture to scale its logistics operations

Belgium's biggest postal operator processes millions of parcels a day. That sounds like a logistics challenge. It's also, increasingly, a data challenge.

When a parcel enters a distribution center, leaves it, gets sorted, gets rerouted, or ends up on a delivery round, every single step generates information that other systems need, immediately. At the scale bpost operates, "eventually consistent" doesn't cut it. Neither does an architecture that was designed for a different era.

That's why bpost started a digital transformation built around event-driven architecture (EDA), with Apache Kafka at its core. And it's why they brought us at Cymo in to help make it happen.

Key takeaway #1

A central database coordinating logic across your entire network isn't a scalability problem you can patch. EDA gives each domain ownership of its own events.

Key takeaway #2

Large digital transformations need early, visible wins. bpost's first production applications were deliberately small. Provable success is what brings people along.

Key takeaway #3

The real return on an EDA backbone isn't efficiency on existing processes. It's how cheap new business ideas become to try once the infrastructure is there.

Why bpost's legacy architecture couldn't scale

bpost's existing infrastructure worked, in the sense that parcels kept moving and customers kept getting their deliveries. But underneath that, the technical reality was messy.

Systems were tightly coupled. A central database sat at the heart of operations, responsible for storing item states and coordinating logic across the entire network. When volumes grew, everything slowed down. When teams in one domain needed to change something, they had to be careful not to break something in another.

The system couldn't easily scale. It couldn't cleanly support new use cases. And it made it genuinely hard to answer a simple question: what is happening in our network, right now?

Stefaan, who led the project from the bpost side, described the ambition clearly: becoming a digital company, expert in parcel delivery. The goal wasn't just to keep existing operations running more smoothly. It was to unlock new business opportunities that the old setup simply couldn't support.

Event-driven architecture was the right foundation for digital transformation

The core idea behind EDA is that systems stop asking each other for information and start broadcasting what's happened in their domain. Instead of a central orchestrator deciding what every other system should do, each domain publishes events and lets consumers react to them independently.

For bpost, processing close to 5 billion events a year (and growing), this architectural shift matters a lot. Moving from a tightly coupled orchestration model to a decoupled, event-driven one means:

  • New use cases can plug in without requiring expensive integration work each time
  • Domains can scale independently, without one team's growth bottlenecking another's
  • The system has a built-in, auditable history of what happened and when

Lorenzo, EDA architect at Bnode, put it well: once you model the business through events, you gain visibility you didn't have before. The sequence of events is the business process, and that's something teams across the organization can actually reason about.

How Cymo and bpost built the EDA platform together

Cymo joined the project at an early stage, working alongside bpost's internal teams in a genuinely mixed setup. Our team, consisting of Solution & Platform Architects, project managers, and Platform Developers, embedded with functional and technical counterparts at bpost, working out of their offices regularly. Stefaan flagged that proximity as important, and we'd agree — the kind of alignment this project needed doesn't happen over video calls alone.

The first quarter was about laying the foundation: setting up the Kafka-based platform on Confluent Cloud and AWS, establishing naming conventions, agreeing on event design patterns, and defining bpost’s "EDA manifesto", the cookbook for how event-driven development works at bpost.

That governance work might sound unglamorous, but it's what makes everything else possible. If producers don't agree on what an event means, consumers can't trust it. If schema changes happen without a strategy, downstream systems break. Getting this right upfront saved a lot of pain later.

After that first quarter, the focus shifted to onboarding. We guided teams across the logistics domains through what it means to be a producer or consumer in an event-driven world, not just technically, but in terms of how they think about their responsibilities.

Both Stefaan and Lorenzo were generous in how they described the collaboration. Stefaan told us he was "very, very pleased" and called out our team across every role: Wout on project management, Kris and Bryan on architecture, and developers who were "really highly skilled, very versatile, and really always available." Lorenzo added that we were able to "kick-start the project and put them up to speed in no time", and that whenever he approached someone from our dev team, he could get an answer immediately.

That kind of feedback matters to us. But what matters more is the outcome: bpost's internal teams can now design, implement, and operate Kafka-based solutions without us in the room. We're still involved when new challenges come up, but in an advisory capacity. Knowledge transfer that actually worked.

Event-driven applications live in production

The first applications on the platform were deliberately scoped to prove the concept before touching anything critical. A greenfield license plate processing flow, spanning retail, distribution, and DIVdomains, showed that multi-domain event choreography works end-to-end in production. A real-time alerting system proved the platform could support operational monitoring at bpost's scale. Both ran alongside the legacy system, which is being retired as confidence grows.

That caution was deliberate, and it paid off. Large digital transformations in complex organizations don't succeed by going all-in from day one. They succeed by generating early, visible wins that bring people along: technical teams, business stakeholders, and leadership alike. Getting something real into production quickly, even if it's small, gives everyone a shared reference point. It turns an abstract architectural vision into something you can point at.

The focus now is acceleration. The foundation is proven, the teams are trained, and the consumer-driven rollout strategy, onboarding one high-value consumer at a time and retiring legacy components as each one goes live, is designed to turn that early momentum into measurable business impact

The biggest lesson from bpost's EDA journey

If there's one thing Stefaan and Lorenzo both flagged as something they'd do differently, it's this: bring the functional experts and the technical experts together sooner, more often, and more directly.

bpost had people who knew the problem domain deeply. Cymo had people who knew the technology deeply. Getting those two groups truly aligned, not just in kickoff workshops but day-to-day, took longer than it should have. The decisions that got stuck were almost always the ones where that connection was missing.

It's a lesson that applies to any EDA transformation. The technology is learnable. The harder part is making sure the people who understand the business and the people who understand the architecture are genuinely working from the same picture.

Cymo specializes in event-driven architecture design and implementation using Apache Kafka. If you're working through a similar transition, get in touch.

We value your privacy! We use cookies to enhance your browsing experience and analyse our traffic.
By clicking "Accept All", you consent to our use of cookies.
Dark blue outline of a cookie icon.