Building the Inhouse Loan Management System
In our last blog ‘Journey To Inhouse Loan Management System’ (https://shivam-ag.medium.com/journey-to-inhouse-loan-management-system-80b1eb325212), we discussed the reasons why we should keep our LMS in-house. In this blog, we will discuss an open-source Apache Fineract, which we have used to build our own in-house LMS. Fineract (originally MIFOS X). It’s maintained by Apache, one of the biggest open source communities in the world.
Apache Fineract is built around a multi-tenant, service-oriented, and tiered architecture, and can be deployed in a SaaS (Software as a Service) model or on-premises.
The foundation forms a robust but flexible data model which is ready-made for extensions and customizations. An API provides access to all basic functions grouped in modules.
Because Fineract needs to be accessible to users at remote locations, a browser-based solution was essential.
Java was selected as a suitable high-level language allowing the rapid customization of code required for each circumstance yet has a large number of powerful libraries available.
Fineract Financial Service Engine
Fineract Financial Service Engine (simply “the Engine”) is a scalable and extensible framework written in Java, and licensed under the Apache License, version 2.0.
The main design principle of the Engine is CQRS ( Command Query Responsibility Segregation ), a pattern that separates commands and queries into different models and services. This approach has multiple benefits: 1) State changes (commands) are persisted, providing an audit of all changes, 2) fine-grained control and extension of state changes, and 3) scalability based on consumer behavior and real system load.
Based on a tiered architecture the Engine provides multiple layers to separate concerns and allow reusability.
The main components of this layer are:
- Every module is exposed via a URI (Unique Resource Identifier).
- Access Control
- Early exit if a consumer lacks authorization for a queried Resource.
- Data marshaling
- Any data transmitted to and from the API is de-/serialized using JSON.
The API is exposed via HTTPS to encrypt all data and secure the communication. OAuth2 is used for authorization.
Stateless by nature the API Layer can be scaled based on the actual load and even used in high availability scenarios.
The Service Layer provides module-specific business logic and rules, and role-based access control. Transaction awareness and data validity are encapsulated, and extension points are available to enhance built-in workflows.
Cross concerns like Security or Transactions are part of the core framework and provided via AOP (Aspect Oriented Programming).
The Service Layer has horizontal and vertical layers.
Services, command, and event handlers form horizontal layers; functional modules form vertical layers.
The Data Layer provides module-specific access to data stores. Data integrity is reached by using the ACID principle and well-defined data relations. Write and read operations are encapsulated in different repositories to define a clean responsibility separation.
The Data Layer uses two cache strategies to cache data efficiently; database and 2nd level caching.
- Database caching stores records on the database level and is useful for reporting, batch jobs, and low-level SQL queries.
- 2nd Level caching stores data objects on the application level and keeps database turnarounds on a very low level allowing fast in-memory access of frequent data.
The Engine’s architecture was designed with a focus on modern, scalable, and extensible technologies ready to run in the cloud. All components were selected based on their maturity, proven reliability, and cost-efficiency.
It is our goal to provide software that is deployable with effectively no cost that can grow with the customer’s needs over time using well-known best practices and support from a wide range of communities.
The basic Fineract architecture is as follows:
ResourceComponentCommentRuntimeJava >=11 Application ServerTomcat v9.xEmbedded Tomcat for development environmentsDatabaseMySQL 5.7Embedded MariaDB for development environmentsApplication FrameworkSpring Framework 5.x Persistence FrameworkOpenJPA 3.x Test FrameworkJUnit 5.x Mockito 3.xREST-assured 4.x
You can add various capabilities to it to meet your business requirements and add various additional features you require. You can also use AWS Aurora instead of Mysql if you prefer to use enterprise DB. It’s based on multi-tenant architecture so DB scales very well with the increasing workload. Kubernetes can be used for horizontal scaling. Jenkins, ELK, and Grafana can be used for CI/CD, logging, and monitoring/alerting respectively.
Find our attached LMS architecture diagram:-
We also have read replicas for analytics and reporting purposes so our transactions don’t become slow due to heavy queries run for those purposes. It’s always a good idea to have a separate read replica for analytics and reporting purposes since their queries are generally quite heavy and acquire a read lock for a large no. of rows and no matter size of the DB machine if a row is locked for reading, write transactions on it cannot be performed until that read query finishes thus slowing your transaction. It’s also integrated with Redshift for data warehouse purposes.
You can refer to the GitHub link https://github.com/apache/fineract to clone the repository and set up your MVP of Inhouse LMS and gradually add additional capabilities required.
You can also refer to the link https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm to find a list of all the Api’s present out of the box, with sample inputs and outputs. You can also add any additional requirements, we have made a lot of additional Apis for various additional functionalities and reporting.
You are welcome to explore our LMS for free built on top of Fineract and test its capabilities to decide if you need your own in-house LMS. To explore our mail please mail to one of all of email@example.com, firstname.lastname@example.org, email@example.com.
Senior Software Engineer