Using Asynchronous Events to enrich Fraud Detection | Designing Event-Driven Microservices

In this video, you will see an example of how Tributary bank uses asynchronous events to enrich its domain and protect its fraud detection system from failures.

Relying purely on synchronous request/response creates artificial limitations in a system. It requires commands to complete in milliseconds or users end up waiting unreasonable amounts of time. It also requires that all parts of the system remain operational. Should a failure occur, it can cascade back through complex chains of request/response operations. In a banking system, where transactions need to be completed instantly, this can be a significant problem. Fraud detection is a complicated process involving the application of machine learning algorithms, complex rules, and even human analysts. Assuming it can be completed instantly leads to a mismatch in expectations. Instead, designing a system that uses asynchronous events as the backbone of communication allows the system to take the time it needs to complete these complex processes, without leaving a user waiting on the other end.

RELATED RESOURCES

CHAPTERS
00:00 - Intro
00:36 - Example: Purchasing Concert Tickets
00:57 - How to handle failure with Request/Response
02:04 - Producing events to be consumed by a microservice
02:37 - Moving the responsibilities into Apache Kafka
03:48 - Consuming events in the microservice
04:48 - Two-way communication between services
05:54 - Enriching the event model
07:26 - Closing

--

ABOUT CONFLUENT

#microservices #apachekafka #kafka #confluent

[Zmey]

Thank you, very interesting explanation about using asynchronous events

[chalequin]

Great video, enjoying this series

When it comes to transaction approval, there is the transactional part ( no pun intended ) where the system has to decide within ~100 milliseconds if it goes through or not . Here we must pack a a rule-based solution inside the monolith . Then for higher-latency ML models, the micro service takes over . I haven't seen or implemented the async approach myself but it feels like the right system design to me

[puneetbhatia]

So basically, the system would allow at least one fraudulent transaction to go through per account before it can mark the account as compromised. That can be an expensive proposition for the bank if these fraudulent transactions are high $$ value. Thoughts?

[BlindVirtuoso]

The problem with event-driven architecture is that business almost always wants things to be strongly consistent. In the example, transaction processing is not strongly consistent with fraud detection. I mean a transaction can be processed, but detected as fraud after several milliseconds. So a compensation mechanism needs to come into play and business people usually do not like this :)

[anny]

good explanation though in terms of a bank transaction as a customer i'd prefer if the transaction was detected as a fraud rather than pushing through but hey, everything comes down to preference which is why we have a lot of software accomplishing the same thing in a different way :-)