Event-Driven Architecture: The Step After Microservices

WAU Marketing
a few seconds ago
5 min read

If you think splitting your monolith into microservices was the modernization, here's the bad news: you just built a pile of modern boxes that still wait for the core to wake them up in batches. The real leap isn't chopping up the system; it's making the system react on its own, the instant something happens.

We've argued in this blog for breaking the monolith into microservices as a necessary step out of a rigid core. We stand by it. But there's a quiet trap: you can have fifty flawless microservices and still run an architecture that thinks in batches. If those services only talk when a nightly process sweeps them, or when someone asks "anything new?", you didn't build a real-time bank. You built a monolith spread across pieces.

The next step has a name: event-driven architecture. The idea is simple to state and deep in its consequences. Instead of systems asking each other for the state of things, every relevant fact—a confirmed payment, a suspicious login, a limit about to be breached—is published as an event the moment it occurs, and everyone who needs to react does so immediately. The event is the backbone. The core stops being a file you query and becomes a system that responds.

Microservices solve how it's organized; events solve when it reacts

It's worth separating the two because they get conflated constantly. Microservices are a structural decision: how you split the system into parts that deploy and evolve separately. Event-driven architecture is a timing decision: when and how those parts find out something changed. You can have the first without the second, and that's exactly where many modernizations stall: new microservices glued together with old batch integrations.

The difference shows up when a fact matters now. A payment came in. Does the fraud engine evaluate it this second, or will it see it tomorrow when the batch runs? Does the notification system alert the customer right away, or when its processing window comes up? In an event-driven design, the payment is published once and the fraud, notification, reconciliation, and limit engines all react in parallel, with no one coordinating them by hand.

Why a batch core can't do real time

This is the heart of it. A batch core isn't "slower": it's structurally incapable of operating in real time, because its unit of work is the processing window, not the event. The cleanest example we know is Rabobank. Its original alert system lived on the mainframe and was stable, but delivering an alert could take between five minutes and five hours, depending on the alert type and the batch window, as documented by Axual, the company that redesigned the system. Rebuilt on an event-driven architecture with Apache Kafka, the full round trip—from a payment being confirmed to the alert landing on a phone—dropped to one or two seconds, with the alerting chain executing in about 120 milliseconds, per the same source.

Five hours to one second isn't an optimization; it's different physics. And it wasn't achieved by buying a faster computer, but by changing the question: instead of "when do we run the process?", the system assumes "the event already happened, react." Apache Kafka, the most widely used event-streaming engine in banking, is precisely the piece that lets you publish those facts as a continuous stream and have many services consume them at once.

Events are where the bank wins or loses money: fraud

The case where real time stops being technical elegance and becomes money is fraud prevention. Here the difference between reacting on the event or on the batch is the difference between blocking a fraudulent transaction or paying it. Event-streaming specialist Kai Waehner documents that Bank of Ayudhya (Krungsri), one of Thailand's largest banks, uses Apache Kafka to detect and block fraudulent transactions in under 60 seconds—impossible if the analysis happened in a nightly process. The same author compiles other industry cases: PayPal processes more than 400 billion events per day for behavioral tracking, merchant monitoring, and fraud detection; ING, Royal Bank of Canada, Capital One, and Nordea appear using event streaming for fraud, mainframe offload, and real-time regulatory reporting (he's an author close to the vendor ecosystem, which is why we flag it).

The neutral point behind the examples is clear: fraud happens as an event and is only stopped by reacting as an event. A core that finds out tomorrow is, by definition, too late.

And events are where LATAM is already playing: instant payments

If anywhere this discussion stopped being theoretical, it's our region. Instant payments made reacting in the moment mandatory, and the numbers shout it. In Brazil, PIX was on track to top 7.9 billion monthly transactions in December 2025 and to move about USD 6.7 trillion for the year, 34% more than the prior one; since launch it has accumulated 196.2 billion transactions and USD 16 trillion moved, with over 170 million users—93% of the adult population—per an EBANX study released via GlobeNewswire. In Mexico, SPEI processed around 7 billion operations in 2025—about 222 per second and more than 14 million a day—moving roughly 347 trillion pesos, about ten times the country's nominal GDP, according to a Bitso report cited by El Cronista.

A payment system that settles 24/7 and instantly leaves no room for a core that reconciles at end of day. Real-time reconciliation, balance updates, and limit validation have to happen while the money moves, not hours later. That cadence is, literally, a stream of events; a batch core can't keep up without piling on risk, mismatches, and customer complaints.

The new standard isn't retrofit—it's being born this way

The most telling part is how the ones starting from scratch build. Cloud core-banking platform 10x Banking decided, almost from day zero of designing its architecture, to publish all its data as events to feed an API-first microservices model, per the Confluent case study (Confluent is a vendor of the streaming technology, which we flag). It's not a patch over a mainframe: it's a core conceived as a stream of events from the start. That's the bar a modern core is already measured against.

How we see it at WAU

At WAU we don't believe modernizing means chopping up the monolith and declaring victory. We design the core so events are its backbone: every payment, every fraud attempt, every limit change is published as a fact the moment it occurs, and the services that matter—reconciliation, fraud, notifications, balances—react in real time, not in the next batch window. Microservices give you a tidy system; events give you a bank that responds. To run instant payments, stop fraud, and reconcile on the fly, that second part isn't optional.

If your institution already split the monolith but still moves at batch pace, that's exactly the next step we can help you take. 👉 Book a conversation with our team.