The Adyen way of engineering: Our tech stack is open source or built in-house
Tags: opensource, postgres, fintech
Published: 2021-01-13 13:43:16

***By Burak Yildirim, Team Lead, Adyen***

Being the most money-involved domain of FinTech, payment processing systems like Adyen are often targeted by individuals or sophisticated organizations. Fraudsters try to generate many synthetic identities like hundreds of different email addresses or hundreds of spoofed IP addresses hoping to slip-in our payment systems, but with the help of our in-house Adyen Graph Database, we can always track them in real-time and block their fraud attempts even though they keep trying new tricks.

## Adyen Graph Database

Adyen Graph Database is one of our in-house products that helps us to catch **fraud** attempts as well as **identifying** individuals and businesses trying to open an account in Adyen. You don’t want to conduct business with shady companies or sole proprietors!

### How can a graph data structure be helpful with payment data?

Use cases like catching fraud attempts or identifying a business or a person during their onboarding to Adyen and continuously checking if they comply with Adyen and payment regulations, pattern matching is a must. To see and explain how payments are connected to each other, relational data structures are not the best choice on their own. There can be changing patterns, many hops between fake identities, recursive and exhaustive search helps us to see all the patterns and connections in real-time, enabling us to track criminals such as fraudsters or shady business owners attempting to open an account and start to process payments with Adyen.

### Why do we have our own graph database solution?

With the payments data, you should be able to look at that from two different but combined angles: as a **transactional** time-series data and as a **connected graph** to closely track potential criminals.

Having a pure traditional **relational database system** cannot help as they are not good at handling connections and patterns. **Graph databases**, on the other hand, are not good for processing high volume transactional data.

At Adyen, we need a completely different solution that **combines** both properties of graph databases and relational-transactional databases in a way that they also serve our specific requirements such as:

* **Transactional**: because of the properties of payments data. combines

* **Multi-tenant**: we process thousands of different companies’ payments with different business needs. Also, for compliance reasons, it does make sense to process each company’s data differently.

* **Data privacy**: as a global financial institution, we encrypt any PII(personally identifiable information) data before processing and persisting.

* **Multi-regional**: since we process payments for global companies, we need to provide our services also with the different needs of different regions. Therefore, multiple data and service regions is key.

* **High-availability**: we should be ahead of the game before criminals. Real-time assessments rely on our high-available services to keep track of fraudsters.

* **Visibility and explainability**: We should be able to answer questions like how and why things are happening when deciding both for regulatory purposes and for providing top-quality service to our merchants.

All these unique high-end requirements affect how we make decisions at Adyen. This resulted in the Adyen Graph Database being built on top of community accepted, open-source, relational database **PostgreSQL** and open-source persistence framework **MyBatis** which supports custom SQL, stored procedures advanced mappings, and programming-language-like control statements that is managed by our internal **graph-engine** written in **Java**.

![](https://cdn-images-1.medium.com/max/3600/0*gEOGDi0l963Gz4lP.png)

The different parts of the Adyen Graph Database work as below 

The **Java application**:
- Extracts useful information from payment requests and structures them as key-value pairs
- For each key, reads the link strength configuration from our configuration database and decides if we should create a new entity in our graph or not
- Calls the queries defined in the **MyBatis xml files** to execute the actual read or write operations
- Retries the operation in case of a failure during write operations to the graph
- Monitors business anomalies and service level metrics

**MyBatis**:
- Uses the **plpgsql stored procedures** to define read and write of graph queries
- Handles key-value pair input and output **mappings** for java requests to help readability on the application side
- Abstracts out exhaustive search-like operations from the application with the help of simple control and loop statements

**PostgreSQL/plpgsql**:
- Runs functions like encrypting PII identifiers, the summation of total link strength, deciding if it should create a new entity or merge into an existing one, and so forth
- Responsible for the consistency of each operation by acquiring a lock, and if stability check fails allows java application to fire a retry event so eventually and as soon as possible the graph is consistent


At Adyen engineering, we believe in the simplicity of our code and our systems. Combining all the powerful features of PostgreSQL such as handling high amounts of transactional data with features of MyBatis, such as being simple, explicit, and close to Java POJO objects allowed us to write our tailor-made SQL queries and stored procedures that are very high-performant.

![](https://cdn-images-1.medium.com/max/3600/0*yA23Dhf9bkjsJYwy.png)

The most powerful aspect of our graph database is that unlike a traditional graph database, **it doesn’t traverse the whole graph each time during a payment — which in our use cases is an unnecessary and yet very expensive operation**. But instead, for the sake of performance, each time a payment is happening we asynchronously generate an overview of statistics and analytics information that is compact and contains all the information we need to detect criminal activities such as fraud.

![](https://cdn-images-1.medium.com/max/3600/0*CpQ1JeKrL7VYT_aO.png)

Storing the relevant information in very simple, normalized key-value pairs we have a huge performance gain even on very big graphs.

## Conclusion

With the exponential growth in our processed payments volume, we constantly look for improving our bespoke graph database solution to always scale better, be more extensible without scarifying the ability to be always ahead of the game before criminals as they constantly try new ways to penetrate into payments domain.

## Technical careers at Adyen

We are on the lookout for talented engineers and technical people to help us build the infrastructure of global commerce!

[Check out developer vacancies](https://www.adyen.com/careers/vacancies/development)

## Developer newsletter

Get updated on new blog posts and other developer news.

[Subscribe now](https://www.adyen.com/newsletter/developers)

*Originally published at [https://www.adyen.com](https://www.adyen.com/blog/the-adyen-way-of-engineering-oss-or-built-in-house) on January 13, 2021.*