Aug 30, 2024
Written by Jaroslav Judin, Senior Software Engineer at Bolt.
Understanding user relationships is crucial in fraud analysis and social networks. However, the options for choosing a suitable storage model are vast, ranging from traditional SQL databases to graph databases and even Redis-based storage.
In this post, I’ll take you through our journey of exploring these solutions in high-traffic production environments and share what we found to be the best fit.
The main goal of anti-fraud is to prevent monetary losses caused by fraudulent activities. For example, one fraudulent order can negate 20 good ones.
One of the most typical reasons for this is stolen credit, which would have to be refunded later, or a chargeback can happen.
Another type of fraud on a platform is promo code abuse, which gives a discounted order. This mechanism is used to attract more customers to the platform. However, if ‘customers’ (fraudsters) find a way to abuse this mechanism, it won’t bring any value. To put it differently, it’ll only bring losses to the platform.
The trick here is to keep the UX — the more anti-fraud measures we take (such as additional verification or user blocking), the more friction it creates for users. For this reason, it’s almost impossible to completely prevent fraud on a platform.
To predict such potential fraudulent activity, a lot of data on user action (such as order placing) has to be available. Based on this, we can detect fraudulent patterns.
The anti-fraud product is a platform for fraud analysts where the needed data is loaded for the given action point. This data is then supplied for fraud rules (that describe fraud patterns) and results in fraud prediction.
One of the most widely used data points for fraudulent pattern detection is user relations.
Image 1: This graph represents user relations via common cards and devices. Entities marked as fraudulent are shown in red.
Is it wise to build a complex system from the beginning? Not necessarily.
Even with plenty of resources, building the MVP with a frugal mindset is crucial. Moreover, delivering the system quickly to test in a real-world production environment allows for essential improvements in subsequent iterations. For startups operating on tight budgets, simplicity is even more critical.
A frugal approach generally drives simplicity here and implies the minimum investment in the architecture at first (quicker to build). It gives the time to validate the idea at a low cost. Our initial version used MySQL tables with recursive joins — a straightforward, cost-effective solution.
As the company grows, so does the data volume, making the initial simple implementation inadequate. This phase typically pushes engineers towards adopting a space-based architecture, which involves duplicating stored data and caching it for faster access without impacting the original data sources.
Approximately 2–3 years after the initial solution, we transitioned to Neo4J. With a focus on frugality, the free Community edition of Neo4J, a graph database, was chosen despite its lack of default partitioning and replication support.
Image 2: User relations graph view in Neo4J.
With further data and company growth, the need for data partitioning became evident. By this stage, we had a clearer understanding of customer (fraud analysts) needs, allowing for more balanced trade-offs. Additionally, there was a solid desire to offload database maintenance to the SRE team, favouring technologies already used within the company.
Approximately five years after adopting Neo4J, we moved to Redis Cluster with a custom graph search algorithm. Redis is used extensively in Bolt for various caching patterns, so we’ve developed considerable expertise in this tool.
We’ve considered other alternatives as well. For example, Memgraph is good but didn’t solve our primary problem — horizontal scalability.
There’s also graph DB from Redis itself called RedisGraph. Unfortunately, it was announced as end-of-life by 31 January 2025. With plain Redis implementation to keep high maintainability, we omitted graph rebalancing algorithms (based on key hashtags), resulting in graph vertices being stored on arbitrary database nodes, with graph searches performed on the service side (see Image 3 to get an idea of how custom algo could work).
Image 3: User relations graph represented as levels distanced from the start of the search (user_1).
The most critical factor influencing these decisions is the point in time where the team and company are situated. The relative importance of these factors shifts over time, and the ability to capture the right momentum and anticipate future directions results in more efficient architecture.
In conclusion, Bolt acknowledges that technology is the foundation of effective business operations. To achieve optimal results, technology must be iterated rapidly and be data-driven to ensure the best decisions are made.
If you want to learn more about this topic, watch the presentation recording from one of Bolt’s Engineering Meetups.
Bolt is a place where you can grow professionally at lightning speed and create a real impact on a global scale.
If you want to join us on our journey, take a look at our careers page. There are hundreds of open roles, each an exciting opportunity to contribute to making cities for people, not cars.
If you’re ready to work in an exciting, dynamic, fast-paced industry and are not afraid of a challenge, we’re waiting for you!
.png)
