Saint HighLoad++ 2024: Moving a Banking Product to Real-Time

On 24 June 2024, Vladimir Avramov and I presented “Moving a Banking Product to Real-Time” at Saint HighLoad++ in St. Petersburg.

The talk covered the early real-time product that began in October 2023. It was not the new Decision Engine / SAS RTDM project I joined in late September 2024.

We needed to use one talk to explain the move from batch processing to reacting to customer events. Rather than trying to retell the entire project, we focused on three questions: why the business needed real-time, how the data flow worked, and which constraints appeared when we tested the architecture.

An architecture people can follow

The solution used Kafka, Apache Flink, Tarantool, and PostgreSQL. A customer event entered Kafka, was processed by Flink, enriched with operational data, and passed on with the result of the business rules.

For a public talk, we removed internal detail and kept the decisions that could help another team. That is a useful design test in itself: if a diagram cannot be explained without twenty exceptions, the component boundaries may need another look.

What we said about Tarantool

Moving between environments exposed configuration differences; functional testing also found a complex-query defect in Tarantool’s CRUD module. The organiser’s account of the talk distinguishes these issues. We revised the integration and moved some logic into external services while keeping Tarantool in the architecture.

Two lessons mattered more than the defect itself:

1. environment compatibility and query correctness need explicit checks; load testing complements them rather than replacing them;
2. a critical technology should not depend on one person’s knowledge.

That account is more useful than presenting the stack as an error-free choice. It shows how the team reached the final design, not just what the diagram looked like at the end.

Why we presented together

A joint talk gave the audience two levels of the same story. I covered the product context, delivery, and the link between requirements and technical choices. Vladimir covered the engineering detail.

Presenting as a pair takes more coordination. You need shared terminology, clear handovers, and an agreement on who answers each kind of question. The benefit is a less one-sided account of the project.

What I learned from the preparation

A technical talk should not turn an internal project into an advertisement. It should give the audience enough context to understand the decision, its constraints, and the lessons they can test in their own systems.

There is also a useful boundary around precision. You can explain an architecture principle without publishing internal traffic, business metrics, or the design of a protected environment.

---

Official Saint HighLoad++ 2024 programme entry.

Yours, DPUPP