Quick Aggregated Account Balance Delivery Using CQRS & Event-Driven Architecture
Case Studies

Quick Aggregated Account Balance Delivery Using CQRS & Event-Driven Architecture

March 25, 2026No Comments

Company profile

One of the largest banking institutions in the Middle East, renowned for its scale, innovation, and diversified financial services portfolio. Headquartered in the UAE, the group operates across multiple international markets, managing assets in excess of hundreds of billions of dollars and serving a vast global customer base.

Challenges

In the competitive landscape of retail banking, account balance is the most frequently viewed and business-critical data point. The speed and accuracy of account balance displays are critical to user trust and satisfaction. The bank’s existing infrastructure struggled with performance and reliability, leading to a degraded customer experience. Key challenges included:

  • High Latency: Aggregated balances were computed on-the-fly by the frontend, which had to wait for responses from multiple APIs (Account and Deposit Summaries). This resulted in a combined latency of approximately 1 second.
  • System Fragility: The use of an API Composition pattern required multiple fine-grained reads from “silver copy” databases, making the system prone to failure if any single orchestration failed.
  • Unreliable Real-Time Updates: Server-Sent Events (SSE) used for balance refreshes suffered from socket errors and network issues. When these events were missed, customers were presented with stale, inaccurate balance data.
  • Resource Overhead: The frontend was burdened with heavy compute and memory overhead to execute the balance aggregation logic.

The organization needed a resilient, high-performance solution capable of delivering balances in sub-100 milliseconds – without sacrificing consistency or fault tolerance.

Solution Provided

D4 Insight created a solution rearchitecting the way the balances are calculated and displayed to customers.

CQRS and Dual-Path Architecture

To address these hurdles, a dedicated microservice, the Retail-Balance-Aggregator, was implemented to serve pre-computed balances using a CQRS and Materialized View approach with a dual-path update strategy for resilience.

  1. Architectural Patterns

The solution transitioned from on-demand calculation to a CQRS (Command Query Responsibility Segregation) model:

  • Materialized View: Aggregated balances are stored as a denormalized dataset in MongoDB, allowing for high-speed indexed reads eliminating on-demand computation.
  • Primary Synchronous Path: When a balance change occurs, the Account container immediately calls the Balance Aggregator’s POST API to update the materialized view in real time.
  • Event-Driven Failover (Kafka): If the primary API call fails, the system falls back to a Kafka-driven path. Domain events are published to a ‘retail-aggregatedBalances’ topic, ensuring the view is eventually updated even during transient API failures.

  1. Robust Event Processing

A suite of “Nano Services” was deployed across domains (Accounts, Cards, Loans, and Payments) to handle event consumption and deduplication using the Inbox Pattern and Dead Letter Queues (DLQ) to ensure idempotent processing.

  1. Comprehensive Edge-Case Handling

The system was designed to trigger balance recalculations during specific lifecycle events, such as login sync completions, new account openings, account status changes, and currency revaluations.

  1. Resiliency & Fault Tolerance

The system was designed for graceful degradation under multiple failure scenarios like domain containers down, Balance Aggregator POST API unavailable, Both API & Kafka unavailable Delayed enterprise events. This architecture eliminated single points of failure while preserving strong consistency guarantees on the primary path.

Business Outcomes Achieved

The implementation successfully transformed the customer experience by providing a resilient, high-speed data delivery layer.

  1. Performance Breakthroughs

  • 90% Reduction in Latency: Response times were slashed from ~1 second to sub-100 milliseconds.
  • Eliminated Frontend Tax: Moving the aggregation logic to a pre-computed backend view removed the compute burden from user devices.

  1. Enhanced Reliability and Scalability

  • Guaranteed Consistency: The “Dual-Path” architecture (API primary + Kafka failover) ensures that balance updates reach the materialized view even if individual services are temporarily down.
  • High Availability: The materialized view continues to serve the last known state even if domain containers (like Loans or Cards) are unreachable.
  • Seamless Scaling: The event-driven nature allows for horizontal scaling of event processors to handle increased transaction volumes.

  1. Security and Maintainability

  • Hardened Security: The system employs JWT validation, RBAC, and mTLS, with MongoDB restricted to internal IP ranges.
  • Clean Architecture: By avoiding “chatty” communication and establishing clear domain boundaries, the bank achieved a more maintainable and less coupled system.