Event-Driven Payments at Consumer-Finance Scale

A leading peer-to-peer payments platform engaged Taller to replace legacy synchronous and batch payment processing with an event-driven architecture built for consumer-finance scale. The engagement was outcome-based, scoped to three defined building blocks within a larger architectural rebuild.

At this platform’s scale, the old way of processing payments was starting to cost too much. The system handled payments synchronously (meaning each step has to finish before the next can start, like a single-file line where everyone waits their turn). It also processed them in batches, saving them up and running large groups all at once. Both approaches were buckling under the volume. The batch jobs were dragging down the core transaction database (the system of record for every payment), infrastructure costs were climbing, and the platform was losing the ability to replay transactions (to re-run a stream of past payments, which teams rely on for recovering from failures and fixing errors).

The platform needed to be rebuilt around an event-driven model. Instead of waiting in line, each payment was treated as its own "event" that got handled the moment it happened, so the system could process enormous numbers of them at once without bottlenecking. It also needed a faster, more efficient way for its many internal services to talk to each other when traffic peaked, and it needed to combine more than thirty separate customer sign-up flows into one.

Taller delivered three defined building blocks within the larger rebuild.

The first was the system of record, the authoritative ledger that tracks whose money is whose, built on Apache Fineract, an open-source core-banking engine. Running on a stack of Docker (which packages software so it runs reliably anywhere), Java (the programming language for the logic), PostgreSQL (the database that stores the records), ActiveMQ (which passes messages between parts of the system), and TestNG (which runs automated tests), this ledger replaced the outside vendors the company had been paying to license, removing that dependency and letting the company manage its own settings directly.

The second was a high-performance service-to-service communication layer, the channel the platform’s internal services use to talk to one another. Taller built it with gRPC (a fast, modern method for services to call each other), running on Java, Spring Boot (a framework that speeds up building Java applications), and Protocol Buffers (a compact, efficient format for packaging the data being sent). Using HTTP/2 and streaming (which allows many messages to flow over one connection at the same time), it handled thousands of simultaneous requests while cutting both delay and infrastructure cost.

The third was the unified onboarding platform, which consolidated more than thirty separate customer sign-up flows into one adaptable, localizable experience (meaning it can be adjusted for different countries and languages), built on a modern Java/Spring Boot stack.