Author: Amol Gote

Relational Databases are the bedrock of any FinTech application, especially for OLTP (Online transaction Processing). This foundational component in any application architecture usually poses challenges around scaling as the business expands rapidly. So, it is imperative that all database activities are monitored closely in the production environment and issues like long-running queries are tracked and resolved.

This article will explore the FinTech case study, which has built a Lending Platform. The company uses the MySQL database hosted in AWS as part of the AWS RDS service. It has multiple microservices using different database schemas hosted on the database instance. The MVP product offering was launched a few years back, and since then, they have been incorporating new features into the FinTech platform. We will cover commonly identified database issues and what was done to resolve these issues.

In today's digital age, cloud-hosted applications frequently use storage solutions like AWS S3 or Azure Blob Storage for images, documents, and more. Public URLs allow direct access to publicly accessible resources. 

However, sensitive images require protection and are not readily accessible via public URLs. Accessing such an image involves a JWT-protected API endpoint, which returns the needed image. We must pass the JWT token in the header to fetch the image using the GET API. The standard method for rendering these images in HTML uses JavaScript, which binds the byte content from the API to the img src attribute. Though straightforward, this approach might not always be suitable, especially when avoiding JavaScript execution.

In fintech application mobile apps or the web, deploying new features in areas like loan applications requires careful validation. Traditional testing with real user data, especially personally identifiable information (PII), presents significant challenges. Synthetic transactions offer a solution, enabling the thorough testing of new functionalities in a secure and controlled environment without compromising sensitive data.

By simulating realistic user interactions within the application, synthetic transactions enable developers and QA teams to identify potential issues in a controlled environment. Synthetic transactions help in ensuring that every aspect of a financial application functions correctly after any major updates or new features are rolled out. In this article, we delve into one of the approaches for using synthetic transactions.

Have you ever wished for a coding assistant who could help you write code faster, reduce errors, and improve your overall productivity? In this article, I'll share my journey and experiences with GitHub Copilot, a coding companion, and how it has boosted productivity. The article is specifically focused on IntelliJ IDE which we use for building Java Spring-based microservices.

Six months ago, I embarked on a journey to explore GitHub Copilot, an AI-powered coding assistant, while working on Java Spring Microservices projects in IntelliJ IDEA. At first, my experience was not so good. I found the suggestions it provided to be inappropriate, and it seemed to hinder rather than help development work. But I decided to persist with the tool, and today, reaping some of the benefits, there is a lot of scope for improvement.

In the digital landscape of today, applications heavily rely on external HTTP/REST APIs for a wide range of functionalities. These APIs often orchestrate a complex web of internal and external API calls. This creates a network of dependencies. Therefore, when a dependent API fails or undergoes downtime, the primary application-facing API needs adeptly handle these disruptions gracefully. In light of this, this article explores the implementation of retry mechanisms and fallback methods in Spring microservices. Specifically, it highlights how these strategies can significantly bolster API integration reliability and notably improve user experience.

Understanding Dependent API Failures

Mobile and web applications consuming APIs dependent on other services for successful execution face unique challenges. For instance, calls to dependent APIs can fail for a variety of reasons, including network issues, timeouts, internal server errors, or scheduled downtimes. As a result, such failures can compromise user experience, disrupt crucial functionalities, and lead to data inconsistencies. Thus, implementing strategies to gracefully handle these failures is vital for maintaining system integrity.

Building APIs and their related components is often a tedious task, especially when dealing with complex data models and architectures like microservices. Repetitive coding, setting up the configurations, and the overhead of building unit tests can quickly become time-consuming. Here's how AI tools, like ChatGPT, can be a game-changer. 

Harnessing AI Tools (Chat GPT) In API Development

To understand the capabilities of ChatGPT, let's dive into a hands-on example. We're tasked with developing a REST API to manage users' Personally Identifiable Information (PII). The process entails:

In the case of microservices, we faced a unique challenge: when a container was deployed, there was no way for us to verify if the latest container build with the expected code had been deployed. It's easy to verify in cases where a new feature is being deployed and is testable in production. However, with fintech applications, we can't necessarily validate all-new production APIs. There are also instances where a bug fix is applied to an existing API, and you can't execute that API use case in production. There were times when the DevOps team informed us that the container had been lifted and deployed from a lower UAT environment, but we didn't see the bug fixes in action when real production traffic began. To circumvent this, we wanted to ensure that there was a way to validate the latest code when the container was pushed.

In our case, we were dealing with spring-based microservices. That's when the Spring Boot Maven plugin came to the rescue. It's necessary to add the build-info Maven plugin within the project's pom.xml file.

As developers working with third-party REST APIs, it is often necessary to store the request and response details for potential future reference, especially when issues arise. This could serve as invaluable data to liaise with third-party vendors, providing a first-hand look at the raw interaction that occurred. In my role, I am constantly orchestrating API’s with multiple partner services. Therefore, I sought a generic solution to store these third-party API requests and responses seamlessly.

The Spring Framework's RestTemplate, a widely used synchronous HTTP client, proves to be a handy tool for consuming RESTful services. This framework provides an interface called ClientHttpRequestInterceptor, which allows us to take certain actions on the request and response.

There are use cases in which, as part of the integration work, you might need to download the zip file from one of your partners, extract the zip file content and then move the extracted files to cloud storage. We had a similar need to download the uploaded ID (Driver’s license) images (Front/Back) from one of the leading ID verification service providers, which persists in the organization’s cloud storage. The challenge lies in downloading a zip file, extracting its contents, and uploading them to cloud storage — all in a transient manner without creating any temporary files on the container of your microservice.

Downloading the Zipped File Content From Third-Party Service

Below is the code snippet to get the zipped file from the partner service.