Adding Client Performance API for consolidated real-time metrics (FINERACT-2460)

[Nidhi Bhawari <ni...@gmail.com>]

Hello Fineract Community,

I would like to start a discussion regarding the value and architectural
alignment of FINERACT-2460, which proposes a new endpoint to retrieve
consolidated client performance metrics.

The Problem: Currently, to build a comprehensive "Client Dashboard,"
front-end applications must make multiple separate API calls to fetch loan
summaries, savings balances, and standing data. This results in "API
chattiness," which increases network latency and complexity for developers.

The Proposed Solution: The clients/{clientId}/performance API provides a
single, read-only view of a client’s financial performance.

Why this aligns with Fineract:

Reducing "API Chattiness" (Mobile-First Approach): Modern applications in
low-bandwidth regions cannot afford 5–6 separate requests for a single
overview screen. This endpoint acts as a Data Aggregator, following the
Backend-for-Frontend (BFF) pattern to provide a pre-computed summary.

Transition to "System of Engagement": Fineract is evolving from a "System
of Record" (saving data) to a System of Engagement (providing insights). By
offering metrics like total arrears and performance scores in one call, we
move Fineract toward an Intelligence Layer, providing the instant feedback
expected by modern fintech users.

Cloud-Native Resource Efficiency: In cloud environments, database
connections and CPU cycles are costly. Executing one optimized
"Performance" query is significantly cheaper and more scalable than five
independent queries for loans, savings, and identity data.

I have already submitted a PR for this (#5410) and am refining it based on
initial technical feedback. I believe this is a critical step toward making
Fineract’s data delivery more intelligent and performance-oriented.

I would love to hear the community's thoughts on this approach.

Best regards,
Nidhi Bhawari

Re: Adding Client Performance API for consolidated real-time metrics (FINERACT-2460)

[Nidhi Bhawari <ni...@gmail.com>]

Hi Aman,

Thank you for the detailed explanation and architectural clarity! This
perfectly answers my questions.

I completely agree that decoupling the analytical/read-heavy workloads from
the core banking engine is the right approach to preserve transaction
integrity. Leveraging Fineract’s native event-broadcasting capabilities
rather than heavily modifying the core application makes a lot of sense for
scalability.

For my GSoC 2026 preparation, I am going to simulate this exact
production-grade architecture locally. I am currently using Docker Compose
to orchestrate Fineract alongside an Apache Kafka broker (enabling
FINERACT_EXTERNAL_EVENTS_KAFKA_ENABLED=true).

Thank you again for pointing me in the right direction!

Best regards,
Nidhi

On Fri, Feb 20, 2026 at 10:35 PM Aman Mittal <am...@gmail.com>
wrote:

> Hi Nidhi,
>
> Apologies for the late reply. This is more of an architectural discussion,
> and I am not qualified to answer on behalf of FINERACT. That said, I want
> to clarify something important: *Apache Fineract can integrate with Kafka*
> — it just isn’t enabled by default. According to the official docs, Kafka
> support must be explicitly configured via properties or environment
> variables (for example enabling FINERACT_EXTERNAL_EVENTS_KAFKA_ENABLED to
> true and setting Kafka bootstrap servers) for Fineract to publish external
> events to Kafka topics.
>
> In many production systems — including ones I’ve worked on — rather than
> modifying the core application, we leverage this eventing capability and
> build a separate consumer service. For example, if I were adding an ETL
> service:
>
>    1.
>
>    *FINERACT publishes events to Kafka* (configured via environment
>    variables like FINERACT_EXTERNAL_EVENTS_KAFKA_ENABLED=true, Kafka
>    bootstrap servers, topic name, partitions, etc.).
>    2.
>
>    I’d create a *separate service that subscribes to the Kafka topic(s)*.
>    3.
>
>    That service would then write to a *read‑optimized database* for
>    analytics or reporting.
>
> This keeps your read‑heavy or analytical workloads *decoupled* from the
> core banking services, which must prioritize *transaction integrity*.
>
> A clear architectural flow looks like this:
>
> *FINERACT → Kafka → New Service to process transactions → Read‑optimized
> DB*
> *(e.g., Elasticsearch, MongoDB, or any Apache Lucene‑based search engine)*
>
> By doing this, you preserve the core FINERACT system, gain scalability for
> event consumers, and ensure that analytics/ETL doesn’t interfere with
> transactional performance.
>
> Best regards,
>
> Aman Mittal
>
> On Wed, Feb 11, 2026 at 11:07 PM Nidhi Bhawari <ni...@gmail.com>
> wrote:
>
>> Hi Aman,
>>
>> Thank you so much for your feedback and for raising those points. I
>> really appreciate the focus on scalability, it’s a perspective I'm still
>> learning to navigate in a system as large as Fineract.
>>
>> I completely agree that for heavy analytical data or long-term auditing,
>> an ETL or background-process approach is much more robust. My initial
>> thought process for a real-time API was primarily centered on the
>> "operational" side specifically for mobile dashboards where a user might
>> expect to see their standing update immediately after a transaction.
>>
>> I just wanted to share this point of view as a potential use case for the
>> community to consider. I am not at all fixed on this specific
>> implementation; I’m mostly curious about how we, as a community, prefer to
>> handle the balance between real-time data needs and system performance.
>>
>> If the community feels that moving toward an ETL-based or pre-computed
>> pattern is the better path for Fineract’s long-term health, I would be more
>> than happy to pivot and explore how to implement this using the project's
>> preferred architectural patterns.
>>
>> I’m looking forward to hearing more of your thoughts and learning from
>> the community's experience on this!
>>
>> Best regards,
>> Nidhi Bhawari
>>
>>>

Re: Adding Client Performance API for consolidated real-time metrics (FINERACT-2460)

[Aman Mittal <am...@gmail.com>]

Hi Nidhi,

Apologies for the late reply. This is more of an architectural discussion,
and I am not qualified to answer on behalf of FINERACT. That said, I want
to clarify something important: *Apache Fineract can integrate with Kafka*
— it just isn’t enabled by default. According to the official docs, Kafka
support must be explicitly configured via properties or environment
variables (for example enabling FINERACT_EXTERNAL_EVENTS_KAFKA_ENABLED to
true and setting Kafka bootstrap servers) for Fineract to publish external
events to Kafka topics.

In many production systems — including ones I’ve worked on — rather than
modifying the core application, we leverage this eventing capability and
build a separate consumer service. For example, if I were adding an ETL
service:

   1.

   *FINERACT publishes events to Kafka* (configured via environment
   variables like FINERACT_EXTERNAL_EVENTS_KAFKA_ENABLED=true, Kafka
   bootstrap servers, topic name, partitions, etc.).
   2.

   I’d create a *separate service that subscribes to the Kafka topic(s)*.
   3.

   That service would then write to a *read‑optimized database* for
   analytics or reporting.

This keeps your read‑heavy or analytical workloads *decoupled* from the
core banking services, which must prioritize *transaction integrity*.

A clear architectural flow looks like this:

*FINERACT → Kafka → New Service to process transactions → Read‑optimized DB*
*(e.g., Elasticsearch, MongoDB, or any Apache Lucene‑based search engine)*

By doing this, you preserve the core FINERACT system, gain scalability for
event consumers, and ensure that analytics/ETL doesn’t interfere with
transactional performance.

Best regards,

Aman Mittal

On Wed, Feb 11, 2026 at 11:07 PM Nidhi Bhawari <ni...@gmail.com>
wrote:

> Hi Aman,
>
> Thank you so much for your feedback and for raising those points. I really
> appreciate the focus on scalability, it’s a perspective I'm still learning
> to navigate in a system as large as Fineract.
>
> I completely agree that for heavy analytical data or long-term auditing,
> an ETL or background-process approach is much more robust. My initial
> thought process for a real-time API was primarily centered on the
> "operational" side specifically for mobile dashboards where a user might
> expect to see their standing update immediately after a transaction.
>
> I just wanted to share this point of view as a potential use case for the
> community to consider. I am not at all fixed on this specific
> implementation; I’m mostly curious about how we, as a community, prefer to
> handle the balance between real-time data needs and system performance.
>
> If the community feels that moving toward an ETL-based or pre-computed
> pattern is the better path for Fineract’s long-term health, I would be more
> than happy to pivot and explore how to implement this using the project's
> preferred architectural patterns.
>
> I’m looking forward to hearing more of your thoughts and learning from the
> community's experience on this!
>
> Best regards,
> Nidhi Bhawari
>
>>

Re: Adding Client Performance API for consolidated real-time metrics (FINERACT-2460)

[Nidhi Bhawari <ni...@gmail.com>]

Hi Aman,

Thank you so much for your feedback and for raising those points. I really
appreciate the focus on scalability, it’s a perspective I'm still learning
to navigate in a system as large as Fineract.

I completely agree that for heavy analytical data or long-term auditing, an
ETL or background-process approach is much more robust. My initial thought
process for a real-time API was primarily centered on the "operational"
side specifically for mobile dashboards where a user might expect to see
their standing update immediately after a transaction.

I just wanted to share this point of view as a potential use case for the
community to consider. I am not at all fixed on this specific
implementation; I’m mostly curious about how we, as a community, prefer to
handle the balance between real-time data needs and system performance.

If the community feels that moving toward an ETL-based or pre-computed
pattern is the better path for Fineract’s long-term health, I would be more
than happy to pivot and explore how to implement this using the project's
preferred architectural patterns.

I’m looking forward to hearing more of your thoughts and learning from the
community's experience on this!

Best regards,
Nidhi Bhawari

>

Re: Adding Client Performance API for consolidated real-time metrics (FINERACT-2460)

[Aman Mittal <am...@gmail.com>]

Hi Nidhi,

That's a good initiative from your side. While based on pr I reviewed
earlier I forgot to consider your overall goal for api implementation.
Which I apologise for that.

I think for reporting and dashboard purpose we must consider tradeoff and
scalability of implementation.

Based on use case I have to first ask how much data need to be processed
and how frequently it need to be read.

If this data is need to be fetched more frequently by user. I recommend
implementing ETL pipelines which returns precomputed data and can be scaled
independently.

If we are dealing with less frequent data but very old data. Less assume
last few years of data for auditing purposes.

Using API with aggregation. In my opinion is not a good practice. It should
be processed in the background and then should be send via email method.

Regards
Aman Mittal




On Wed, Feb 11, 2026, 8:33 PM Nidhi Bhawari <ni...@gmail.com>
wrote:

> Hello Fineract Community,
>
> I would like to start a discussion regarding the value and architectural
> alignment of FINERACT-2460, which proposes a new endpoint to retrieve
> consolidated client performance metrics.
>
> The Problem: Currently, to build a comprehensive "Client Dashboard,"
> front-end applications must make multiple separate API calls to fetch loan
> summaries, savings balances, and standing data. This results in "API
> chattiness," which increases network latency and complexity for developers.
>
> The Proposed Solution: The clients/{clientId}/performance API provides a
> single, read-only view of a client’s financial performance.
>
> Why this aligns with Fineract:
>
> Reducing "API Chattiness" (Mobile-First Approach): Modern applications in
> low-bandwidth regions cannot afford 5–6 separate requests for a single
> overview screen. This endpoint acts as a Data Aggregator, following the
> Backend-for-Frontend (BFF) pattern to provide a pre-computed summary.
>
> Transition to "System of Engagement": Fineract is evolving from a "System
> of Record" (saving data) to a System of Engagement (providing insights). By
> offering metrics like total arrears and performance scores in one call, we
> move Fineract toward an Intelligence Layer, providing the instant feedback
> expected by modern fintech users.
>
> Cloud-Native Resource Efficiency: In cloud environments, database
> connections and CPU cycles are costly. Executing one optimized
> "Performance" query is significantly cheaper and more scalable than five
> independent queries for loans, savings, and identity data.
>
> I have already submitted a PR for this (#5410) and am refining it based on
> initial technical feedback. I believe this is a critical step toward making
> Fineract’s data delivery more intelligent and performance-oriented.
>
> I would love to hear the community's thoughts on this approach.
>
> Best regards,
> Nidhi Bhawari
>