Architecture Improvements for the Aggregator that connects banks with Fin-Tech Startups

A founder of the aggregator platform approached us to help with data migration. This platform allows banks to find fintech solutions for their problems. By using this platform, banks can search for a specific solution and find fintech startups that do that peculiar thing, try out their APIs, and if it matches their needs, contact the developer for further integration of the technology into their workflow.

descriptive text

What the task was

The client wanted to migrate the platform data from MongoDB to Postgres, from NoSQL to SQL. But while conducting the audit of their product, we’ve found a much bigger problem.

Their backend took 1.5 seconds to respond to the inquiry, which led to their frontend taking 12 seconds (sometimes more) to upload a page and about 6 seconds for each next page load. So instead of just migrating the data, we had to re-think their architecture to solve this issue.

Our final tasks looked like this: Re-do the platform’s architecture to shorten the time of backend response, hence the page-load;

Migrate the data to Postgres.

task

How we solved it

After thoroughly studying the platform’s architecture, we’ve seen that it uses hundreds of Lambda functions that do the same thing, despite that one Lamda contained all of the application logic triggered for all events, which made it unsuitable for Microservices architecture.

So we’ve helped them migrate to Monolith, which allowed reducing the response time to 70 milliseconds when they’ve expected 500 or more and has also shortened the frontend page-load time to less than 2 seconds.

How it benefited our client

doings

Significantly cut down AWS costs

doings

Developed a faster backend (response time down from 1.5 seconds to 70 milliseconds) that is easier to test

doings

Reduced page-load time from 12 seconds to 2 seconds

Our works

chart

Aim Gods

APIs, website, and security enhancement

chart

ELT Platform

Redevelopment