Peer-to-Peer Lending Marketplace For Retail Finance

Our client is a London based startup operating in the consumer finance sector. It is a platform for merchants, lenders, and intermediaries, where customers can spread the cost of any purchase over several months while the merchant gets paid in full right away. The company isn’t providing financing themselves but instead connects to its own marketplace of lenders who compete to offer the most suitable credit. The company works with financial institutions such as Barclays, WorldPay and Klarna. The platform works on any device (phone, tablet, computer), anywhere (in-person/in-store, online, by phone) as the process is completely paperless and instant. The modular structure allows it to be adopted on a country level (language, currency, local regulations, etc) and supports all types of finance ( POS retail finance, SME loans, car finance, payday lending, etc).

The first challenge that our team encountered was due to a large stream of query inputs(webhook) in the context of processing DB-connections and in the context of transactions. We had to increase maximum bandwidth in order to quickly proceed with requests per second. Moreover, we had to organize transaction and rollback actions to avoid deadlocks and other similar issues (data corruption, etc.) that may occur during high request rates. The next challenge that occurred was the loading speed page at a large data volume. The page was loaded in about 30 seconds, which was too slow for us. We had a problem with effective multithreading. There were a large number of functions (jobs) that occurred simultaneously and intersected. So, our task was to make sure there are no conflicts between them in order to keep the data consistent and avoid having one function-blocking another. A small problem also arose with cash transactions. The calculations should be accurate and take into account all the marks after the comma.

We organized precise transaction management and set up a correctly configured connection pool. To speed up the loading time we assimilated SQL queries, extracting the necessary data for a particular page. In addition, we transferred many aggregation operations to the database level. Also, a part of the resources was located in RAM. We had to abandon a static page load in favour of a dynamic one. All these steps allowed us to reduce the page load time down to less than a second To overcome the problem with effective multithreading we applied spring scheduler and native tools like ScheduledExecutorService, as well as proper transaction management. To deliver greater accuracy for the cash transactions we used specific classes that provided more accurate calculations. Also, we applied proper error handling, therefore, in case of system problems, money will not be sent anywhere.