Reactive programming and fintech challenges with Tamir Dresher

Get ready to level up your development game with our latest episode featuring reactive programming guru Tamir Dresher, Head of Architecture at Payoneer. 

Tamir shares his insights on reactive programming and how to build reactive applications and reactive systems. He also explores how this paradigm allows Payoneer to build with a zero-downtime mindset, while handling millions of users in hundreds of countries — each with differing regulations and technical requirements.

Join us as we discuss:

• Identifying choke points within your infrastructure
• Benefits of building a reactive system
• Complications of scaling a FinTech application

Identifying choke points within your infrastructure

“When we're talking about reactive systems, we want the system itself to be responsive. We want it to be resilient. We want it to be elastic,” says Dresher.

The key to achieving this is in striving for asynchronous processing.

Consider a highway: There are multiple lanes; if one is blocked, it may cause vehicles to slow down but drivers can still switch lanes and continue on their way while the block is being attended to. The same principle applies to your code in asynchronous processing: You can tend to the area where the problem occurs without blocking the entire digital highway. 

The observable and the observer

Dresher explains that reactive systems remove much of the manual labor in updating code. He describes a variable, like an integer inside the code, that can change, resulting in a different calculated output, according to a formula being used in the code.

Ordinarily, should the integer change, there’s no rule set inside the code that recognizes the change. If you’re building a reactive system, however, you will also create something that recognizes the change in integer and initiates a recalculation function. That “something” is called the observer, and the variable it "observes” is known as your observable.

Dresher goes on to say that an entire framework can be built on this principle, since some elements can be both observers and observables (otherwise known as subjects). The system can be scaled to achieve that asynchronous ability to navigate changing variables and update information accordingly.

This extra little bit of work when writing your code could save you and your team crucial hours down the line.

Benefits of building a reactive system

“Now we have another layer that knows how to really look at the changes as first-class citizens. It allows us as developers to really, in a declarative way, define what we want to happen without messing around with all the concurrency and synchronicity.” — Tamir Dresher

In considering the many available coding languages, Dresher notes that not all of them have inbuilt methods for dealing with concurrency — and that’s really where reactive programming shines. 

“It makes it easy for developers to choose the right tool for the right job,” he says, “because it’s possible to move from one way to another in the same piece of code.”

Even the best tools come with limitations

Of course, everything comes with limitations. In reactive programming, extensions are not going to make decisions about where something is going to run. You still need to make that choice as a developer.

As Dresher says, “What we have inside the reactive extension is abstraction, which allows us to really perform things like scheduling over specific execution or timers that allow us to run scheduling in the future.”

Another limitation highlighted by Dresher is that the reactive extension performs less effectively when facing “back pressure” — a high volume of changes. This doesn’t necessarily limit the use of the reactive extension at scale, but it does create a requirement around the distribution of the functions between different machines. It’s all about asynchronicity.

Complications of scaling a Fintech application

There’s no denying the complexity of a Fintech operation:

• Partners
• Senders
• Receivers
• Region-specific requirements (including regulations)
• User queries and support
• Version control
• Integration
• Compliance and risk management

Sharing several examples, Dresher touches on scenarios such as needing to deposit money into bank accounts that have been closed, or dealing with transaction reversal requests. All of these things are coming in at scale for an organization like Payoneer, and this is what Dresher believes the reactive system is designed to deal with at its core.

It comes right down to the power of asynchronous processing and being message-driven. It reduces bottlenecks and choke points and allows work to continue, where possible, while genuine issues are being patched.

With Payoneer serving millions of users around the world, Dresher is well-versed in what works and what doesn’t work when scaling a Fintech.

Reactivity in the face of scale

The term ‘reactive’ sometimes comes with negative connotations, but it really means to be responsive and adapt to what’s changing within a specific context. It’s a good thing.

“You don't really know in advance what’s the correct way to do things. We're learning all the time. One thing that really helps is solid monitoring, and an SLA, and people who know how to provide a sort of protective bubble from all kinds of things.” — Tamir Dresher

When asked about examples of reactive systems performing well at scale, Dresher touched on partners working with Payoneer’s API: If a function crashes on the partner’s side, Payoneer needs to know that it shouldn’t execute a payment twice, and introduces observers here, to set the function up appropriately.

Key advice from this episode: You need everyone to be on board for reactive programming to succeed, and you need a team of high-quality professionals.

‍