Cloud Native Fineract with Scalability: Architecture and Implementation

Introduction

Fineract, an open-source core banking platform under the Apache Foundation, has evolved to embrace cloud-native principles to meet the demands of modern financial services. As organizations scale their operations, ensuring system scalability becomes critical. This article explores the architectural strategies and technical implementations that enable Fineract to achieve horizontal, functional, and tenant-based scalability, while addressing performance, availability, and management challenges in a cloud-native environment.

Scalability Dimensions and Core Concepts

Three-Dimensional Scalability Model

Scalability in Fineract is structured around three axes:

1. X-axis (Horizontal Scaling): Achieved through multi-instance deployment, enabling increased throughput by leveraging database replication and multi-database instance connectivity.

2. Y-axis (Functional Decomposition): Modularizing features allows independent deployment and scaling of components, such as separating batch processing from core APIs.

3. Z-axis (Tenant Isolation): Creating tenant-specific instances ensures isolation, enhancing security and resource management for multi-tenant environments.

Kubernetes Deployment Optimization

Fineract leverages Kubernetes to optimize deployment and scalability:

• Deployment Types:

  • Deployment: Used for stateless services, supporting auto-scaling and rolling updates.
  • StatefulSet: Ensures stable, unique endpoints for stateful services like batch managers.

• Batch Processing Architecture:

  • Separates Batch Manager and Batch Workers via controllers, enabling efficient workload distribution across high-account-volume scenarios.

Liquibase Configuration for Database Management

• Exclusive Upgrade Mode: Liquibase scripts execute only after database upgrades, reducing lock contention and enabling DBA teams to manage upgrades independently.
• HAM Chart Integration:
  • Pre-upgrade hooks trigger Liquibase scripts, ensuring seamless transitions.
  • Post-upgrade, services resume on new endpoints, supporting cross-availability zone deployments.

Instance Evolution and Architecture Refinement

2020 Planning and Implementation

• API Separation: Retained read-write and read-only APIs, while isolating batch management APIs into dedicated instances.
• Ingress Strategy:
  • HTTP Methods: Route GET/HEAD requests to read-only instances.
  • URI Paths: Direct specific endpoints to batch management instances.
  • Default Routing: Redirects API clients to read-write instances.
• Frontend Isolation: Frontend instances operate independently from APIs, preventing frontend traffic from impacting backend stability.

Resource Allocation and Availability Enhancements

• CPU Configuration: Pod requests define CPU cores (e.g., 100m CPUs = 1 core), ensuring optimal resource utilization.
• Garbage Collection Strategy:
  • G1 GC: For interactive requests.
  • Parallel GC: For batch processing workloads.
• Availability Improvements:
  • Pod Distribution: Enforces cross-availability zone deployment via Max Q parameters.
  • DNS Resolution: Disables caching and periodically refreshes database endpoints to minimize failover downtime (reducing interruptions to seconds).

Management Platform and Technical Challenges

Jenkins-Based Centralized Management

• Deployment Automation: Supports environment configuration and deployment workflows, ensuring service continuity after infrastructure changes.
• Client-Specific Requirements:
  • Some enterprises use proprietary AWS architectures, requiring independent management.
  • System testing validates database migration stability during failover scenarios.

Kubernetes Ingress Limitations

• HTTP Method Routing: Kubernetes Ingress lacks native support, requiring AWS Load Balancer Controller for advanced routing.
• HAM Chart Complexity:
  • Contains ~500 lines of configuration for read/write, batch, frontend, and Liquibase instances.
  • Supports AWS EKS deployments but is limited to cross-cloud server configurations.

Future Directions and Open Source Contributions

Scalability Enhancements

• Guard Rails Design:

  • Terraform and Jenkins enforce infrastructure consistency across deployment methods.
  • Separates environment types (production/non-production) from data types, enabling hybrid configurations.

• Archiving Functionality:

  • Discusses loan data handling (deletion, tenant migration, export/reimport).
  • Final decisions will align with customer needs and community feedback.

Open Source Roadmap

• Helm Chart Refinement:

  • Current AWS-specific dependencies (e.g., Helm Chart) are under review for open-source compatibility.
  • Goals include submitting improvements to the Apache Foundation to enhance non-functional attributes like availability and scalability.

• Production Validation:

  • Ongoing testing for archival features, production environment validation, and migration readiness.

Conclusion

Cloud-native Fineract achieves scalability through a combination of horizontal, functional, and tenant-based strategies, supported by Kubernetes, Liquibase, and modular architecture. Key advantages include enhanced availability, resource efficiency, and flexible deployment models. However, challenges such as Kubernetes Ingress limitations and configuration complexity require careful planning. Organizations should prioritize modular design, cross-availability zone deployment, and centralized management to maximize scalability and reliability in Fineract implementations.