Kotak Mahindra Bank Modernizes Microledgers Using Amazon DynamoDB for Predictable Low Latency at Scale

Overview

Scaling of the Core Banking Systems (CBS) of the Indian Banks has been a point of concern due to the significant rise of the digital payments in India. This is primarily driven by Unified Payments Interface (UPI). UPI is a system that powers multiple bank accounts into a single mobile application (of any participating bank), merging several banking features, seamless fund routing & merchant payments into one hood. It also caters to the “Peer to Peer” collect request which can be scheduled and paid as per requirement and convenience. The scale at which UPI operates is demonstrated by the fact that in March 2025, UPI processed over 18 billion transactions worth nearly $300 billion. This marked a 50% year-over-year increase in volume and a 33% rise in value.

There is a predictability to the overall year-on-year growth in the digital payments due to high rate of financial inclusion. However, due to events like festivities, sporting events and e-commerce sales day, seasonal spikes are observed throughout the year. Traditional core systems, built for branch-based banking, are not designed for such load. As a coping mechanism, on-premises databases are provisioned for peak traffic, leading to inefficiencies during quieter periods. The surge in UPI transactions has also resulted in a flood of read-only requests like balance checks and transaction history inquiries. These simple queries account for a significant portion of traffic and often peak during high-load periods or outages, straining the CBS.

In this blog, you will learn how Kotak Mahindra Bank addressed these challenges, by building two systems – Real-time Transaction Service (RTS), a distributed ledger to track all value movement and Read-Only Object Store (ROS) that offloads non-transactional requests from CBS, using Amazon DynamoDB, enabling predictable low latency at scale to meet the demands of modern digital banking. The solutions improved reliability of the system and ensured uninterrupted access to transaction posting, balance inquiry, statement generation and reporting —even when CBS is impaired. The system uses Amazon Elastic Kubernetes Service (Amazon EKS) for orchestration of microservices. Amazon Managed Streaming for Kafka (Amazon MSK) is used for near-realtime data streaming and synchronization and Amazon ElastiCache for REDIS for in-memory caching.

Business metrics before RTS and ROS

Before the implementation of RTS in March 2024, Kotak Mahindra bank processed approximately 237 million credit transactions monthly, with a total of 800 million transactions overall. Performance bottlenecks were evident, with p95 latency for credits at 600 milliseconds(ms), and a transaction failure rate of approximately 1.5%. During peak loads-reaching up to 1500 transactions per second (tps)-other workloads were adversely affected, leading to brownouts and degraded customer experience.

Before the introduction of the Read-Only Store (ROS), all balance and transaction inquiries were served directly from the Core Database (CDB). This setup led to performance limitations, especially under high load.

• Balance Inquiry
  • Latency was measuring p90 at 150 ms and p95 at 175 ms
  • Throughput was measuring up to 500 and 300 tps respectively from the UPI app and Mobile Banking channels respectively
• Transaction Inquiry
  • Latency was measuring p90 at 500 ms and p95 at 650 ms
  • TPS was measuring 50 tps on average and peaking at 100 tps through the Mobile banking channel
• Overall Challenges
  • Inquiry operations placed heavy read pressure on the Core Database
  • Latency spikes during peak hours affected user experience
  • Scalability was limited, making it difficult to support growing digital demand

Solution Overview

To manage the increasing pressure on core banking system, Kotak Mahindra Bank has successfully implemented a Core Augmentation strategy by building the Realtime Transaction Service powered by Amazon DynamoDB. This decision was driven by the fact that DynamoDB provides serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale. DynamoDB offers zero infrastructure management, zero downtime maintenance, instant scaling to any application demand, and pay-per-request billing. There are no cold starts, no version upgrades, and no maintenance windows. DynamoDB is fully managed, removing the heavy lifting of undifferentiated database management tasks such as backups, security, compliance, monitoring, and more. For globally distributed applications and cross-region disaster recovery, DynamoDB global tables is a multi-Region, multi-active database with up to 99.999% availability and offers the highest database resilience. Kotak Mahindra Bank had a running Landing Zone architecture based on AWS Control Tower providing an orchestration framework for their foundational AWS environment. It provides a baseline to for their multi-account architecture, identity and access management, governance, data security, network design, and logging. This provided the RTS application a robust, secure and tested foundational architecture to inherit. RTS serves as a unified interface for backend ledgers, designed to enhance resilience, minimize operational overhead, and streamline integration through standardized APIs. By decoupling transaction processing from the core, RTS ensures predictable low latency, elastic scalability, and consistent performance under high load, meeting the demands of modern digital banking.

Figure 1: The Solution Architecture of RTS

The architecture integrates components across the bank’s data center and AWS Cloud, with Amazon DynamoDB at its core.

1. Synchronous Transaction Flow

• The UPI switch invokes RTS microservices hosted on Amazon EKS.
• RTS validates the transaction using replicated account metadata stored in Amazon DynamoDB.
• The transaction is recorded in DynamoDB and queued to Amazon MSK for downstream processing.
• A success response is returned to the UPI switch immediately, ensuring low-latency user experience.

2. Asynchronous Posting to Core Banking System

• Kafka consumers asynchronously post transactions to the Core Banking System (Finacle) in a rate-limited manner.
• Throttle tokens are stored in Amazon ElastiCache Redis where Token bucket algorithm is used to rate limit the writes to the Core Banking system. A fall back from Redis is also built to ensure per host throttling using local throttle config rules. The algorithm work as follows:
  • The transaction in a Kafka Topic must be synchronized with the Core banking System (Finacle) through an API hosted on-premises.
  • A Kafka consumer running on EKS will consume the transaction and has a token bucket associated with it, stored in Amazon ElastiCache (Redis).
  • The Redis-backed token bucket is used as a rate limiter with per-second atomic counters to globally throttle Kafka consumers across distributed hosts, and gracefully fall back to local per-host throttling when Redis is unavailable—ensuring consistent throughput and protecting the Core Banking System from overload.
  • When a Kafka consumer wants to process a message, it will first check the token bucket in Redis to see if it has enough tokens available.
  • If there are enough tokens, the consumer will consume the message and update the token bucket in Redis accordingly.
• If a transaction fails to sync within a few seconds, a reconciliation job runs every minute to retry posting.
• Real-time lag monitoring ensures that if posting delays exceed thresholds, RTS switches to synchronous posting mode for consistency – and reverts to asynchronous mode when conditions stabilize.

3. Metadata Replication and Reconciliation

• Account metadata is replicated from Finacle to DynamoDB using Oracle GoldenGate, Amazon MSK, and Kafka consumers.
• Source data is stored in an Amazon Simple Storage Service (S3) bucket, and a real-time reconciliation job ensures metadata freshness in DynamoDB.

4. Data Export and Reporting

• Transaction data is periodically snapshotted and exported to an Amazon S3 bucket for audit and reporting.
• Amazon Athena enables ad hoc querying on this data to support operational diagnostics and analytics.

ROS- Solution overview

To reduce the load on Core Banking Systems, Kotak Mahindra Bank has developed a dedicated service called Account Inquiry Service (AIS). AIS is designed to handle balance and transaction inquiries by using a separate, read-only view of account data maintained outside CBS. Over time, AIS will become the central service for handling such requests across all systems in the bank. It decides whether to serve data from this external view or directly from CBS, based on how current the view is. If the data lag is within acceptable limits defined by service-level objectives (SLOs), AIS responds from the view; otherwise, it fetches data from CBS. Each response includes a timestamp indicating when the balance was last updated, ensuring auditability and reliability of the system.

Figure 2: The Solution Architecture of ROS

The ROS data flow begins with transactional updates from the Core Banking System (CBS), which are emitted as events and propagated through the data pipeline for real-time processing and storage in Amazon DynamoDB.

• The Core Banking System continues to handle transactional processing and updates. These updates are emitted as real-time events—such as “Balance Updated” or “Transaction Posted”—via Oracle GoldenGate. The event data is then replicated to Amazon Managed Streaming for Apache Kafka (MSK) and stored in an S3 bucket as Parquet files for downstream consumption by reconciliation systems.
• ROS Kafka consumers process these events in real time, updating Amazon DynamoDB with the latest balance and transaction data.
• Balance and transaction history inquiry APIs are served from Amazon DynamoDB when data latency remains within acceptable thresholds defined by service-level objectives (SLOs). If the lag exceeds these limits, requests gracefully fall back to the Core Banking System (CBS). On average, only 1.4% of daily requests require fallback.
• Reconciler continuously polls data from Amazon S3 and performs real-time reconciliation against records in Amazon DynamoDB. This ensures data accuracy and completeness, maintaining consistency between CBS and DynamoDB without mismatches.

Key business outcomes – RTS

After implementing the Realtime Transaction Service (RTS), Kotak Mahindra Bank increased its monthly credit transaction volume to 350 million, up from 237 million. The system now handles 1.3 billion transactions with improved performance. The p95 latency for credits dropped from 600ms to ~30ms, and the transaction failure rate fell from 1.5% to less than 0.01%. Amazon DynamoDB enables this performance, with average write latency of 3.2ms and read latency of 2ms. RTS has consistently handled traffic spikes without downtime. Remaining failures are mostly due to network or external systems and are actively being addressed.

Key business outcomes – ROS

After implementing a Read-Only Store (ROS) architecture backed by Amazon DynamoDB, Kotak Mahindra Bank enhanced the scalability and responsiveness of the digital banking services. This architectural shift helped them efficiently handle high-volume balance and transaction inquiries with consistent low latency, supporting up to 30 million requests per day. By using Amazon DynamoDB’s predictable low latency at scale, they recorded latency metrics of p90: 2.05 ms, p95: 2.49 ms, and p99: 4.55 ms, providing a smooth experience for end users. The implementation also helped them achieved 99.99% availability, delivering highly resilient and consistent performance across digital banking channels. It also reduced the load on the Core Banking System by offloading read operations to a scalable, cloud-native data store powered by Amazon DynamoDB.

Beyond performance gains, this launch has also improved the availability and reliability of digital channels, directly benefiting the Bank’s customers by providing faster and more consistent access to their financial data.

Both RTS and ROS are designed to be self-healing systems that dynamically switch between optimal and synchronous modes to balance customer experience and system performance. RTS acts as a buffer, absorbing transaction spikes and writing to CBS asynchronously under normal conditions, but switching to synchronous writes when needed. ROS, on the other hand, functions as a cache, serving read requests from its local store and falling back to CBS for synchronous reads when its data is stale or unavailable. If either or both “transaction” and “metadata sync” lag breaches the defined threshold, the system automatically flips to passthrough mode, serving requests from CBS synchronously. Once the lag returns to acceptable levels, it auto-heals and flips back to buffering mode, resuming optimized traffic shaping and asynchronous replication. This transition is governed by control logic that acts as a circuit breaker—isolating jittery components and restoring them once healthy—ensuring fault tolerance without manual intervention.

Conclusion

By building RTS and ROS on AWS, Kotak Mahindra Bank has been able to address both the spiky and seasonal transactional load and the ~50% annual growth attributable to the growth of the UPI transactions in India. This has also ensured the availability of the Core Banking System for performing activities like Branch Operations and Regulatory reporting without being impacted by the spiky and seasonal transactional load. The latency metrics and error rates have improved by more that 95% due to the use of Amazon DynamoDB as intermediate Microledgers and Amazon EKS based microservices architecture. The multi-region architecture facilitated by DynamoDB Global Tables has helped the bank to performed planned disaster recovery drills providing a predictable reliability to the applications.

Further reading

How Zepto scales to millions of orders per day using Amazon DynamoDB

Building a 10-billion wallet crypto-intelligence platform: Elliptic’s journey with Amazon DynamoDB

Implement event-driven architectures with Amazon DynamoDB –Part 1, Part 2, Part 3