CASE STUDY

Real-Time CRM Search at Scale for a Leading Private Bank

Ashnik Team

  • Industry :
    Banking
  • Technology :
    Elastic Stack, Hadoop
  • Engagement :
    Architecture Design, Managed Services
THE CUSTOMER

One of the leading private banks in the country running an in-house CRM built on Core Banking data.

THE SOLUTION

Three dedicated Elasticsearch clusters — Search, Transaction Search, and Log — running alongside the existing Hadoop lake.

THE CHALLENGE

Hadoop handled batch analytics well. It could not support real-time CRM search or log visibility.

THE RESULT

20,000 search events/sec, 750 GB/day of logs indexed in real time, unified dashboards across business and IT.

20,000/sec

Search Cluster throughput

12,000/sec

Transaction search throughput

750 GB

Log data ingested daily

6,000/sec

Log ingestion rate

Customer Overview

The bank’s CRM application is the system of record relationship managers use every day. It pulls customer data from Core Banking into a Hadoop data lake, where it’s processed for Customer360, analytics, and MIS.

Hadoop was doing what it was built for: high-volume batch processing. It was never going to serve sub-second, interactive search. As RMs came to depend on the CRM for real-time offers and customer journey tracking, that gap turned into a daily operational problem.

The Challenge

Search latency over Hadoop

Customer360 lookups running directly against Hadoop were too slow for RM-facing use.

No real-time log visibility

Application logs weren’t monitored in a way that surfaced issues as they happened.

No unified dashboards

Business data and application data sat in separate silos, with no shared view for either team.

No DR plan

Customer-facing systems had no disaster recovery strategy in place.

Thin operational bandwidth

Day-to-day tuning and troubleshooting needs were outpacing what the team could keep up with.

Unclear path for new workloads

Every new use case risked becoming a fresh architecture exercise.

The Approach

01
Three purpose-built clusters, not one shared environment
Ashnik architected Search, Transaction Search, and Log as three separate Elasticsearch clusters rather than a single combined deployment.
02
Search Cluster
1M + 2MD + 4D nodes, feeding the CRM application directly.
03
TX Search Cluster
3MD + 4D nodes, dedicated to transaction-level search.
04
Log Cluster
3MDI + 1DI nodes, handling microservice log aggregation.
05
Kibana as the shared front end
IT teams get log analysis and uptime views. Business teams get lead and CRM funnel dashboards. Both draw from the same platform.
06
Ongoing tuning, not a handover
Ashnik stayed on for architecture consultation as new workloads came in, plus continuous performance tuning and managed services.

Architecture

MI and TI scaled

Scale

METRIC VALUE
Search Cluster ingestion 100 GB/day
Log Cluster ingestion 750 GB/day
Search Cluster throughput 20,000 events/sec
Transaction Search throughput 12,000 events/sec
Log Cluster throughput 6,000 events/sec
Production clusters 3

Outcome

RMs search in real time

Customer profiles and transaction summaries load instantly instead of waiting on Hadoop batch cycles.

Logs are searchable as they land

750 GB/day ingested and indexed, giving IT visibility into service health without a delay.

One dashboard layer for two audiences

Business and technical teams both work off Kibana, pulling different views from the same data.

Room to grow

Workload-isolated clusters mean new use cases don’t force a redesign.

Conclusion

Hadoop stayed exactly where it was strong: batch analytics and MIS. Elastic took on the part Hadoop was never meant to do, real-time search and log visibility, without either system getting in the other’s way.

For banks running similar Hadoop-first architectures, the takeaway is architectural, not technological: real-time and batch don’t compete for the same cluster. They run in parallel, each doing what it does best.