Performance and down-time issues crippling bank’s productivity across 3000 branches and 10,000 ATMs

3-4/day → 0
Web server outages eliminated
50%
Faster database response times
3,000+
Branches affected
10,000
ATMs affected

When a core banking platform serves 3,000 branches and 10,000 ATMs, there’s no such thing as a small outage. This bank’s web servers were going offline 3-4 times every single day and the knock-on effect touched retail operations nationwide. Avekshaa’s audit found the problem wasn’t one broken component, but four layers of the stack quietly working against each other.

The Challenge: A Retail Network Running on Borrowed Time

Performance and availability issues were crippling the bank’s retail operations across 3,000 branches and 10,000 ATMs. This wasn’t an occasional blip, the web server layer was going offline 3-4 times a day, meaning branch staff and ATM transactions were routinely interrupted during business hours, including the highest-stakes periods: month-end and quarter-end processing.

At this scale, every minute of downtime multiplies across thousands of endpoints simultaneously. A branch teller who can’t complete a transaction, an ATM that times out mid-withdrawal, and a call center queue that backs up are all downstream symptoms of the same underlying instability.

Why This Matters

Availability problems at this scale rarely have a single root cause. They tend to emerge from several borderline-adequate components stacked on top of each other, a network link sized for yesterday’s volume, a heap configuration set once and never revisited, a database query that got slower as tables grew. Individually, each is tolerable. Together, under peak load, they fail.

Diagnosing the Bottleneck: A Full-Stack Audit

Avekshaa was brought in to run a P-A-S-S™ optimization across the core banking system that supported 3,000 branches and 10,000 ATMs via multiple channels. Avekshaa’s unique P-A-S-S™ optimization methodology was applied layer by layer to identify performance issues across the entire technology stack, not just the component that happened to be visibly failing.

The Transaction Path Under Review

Branch
Branch
Branch
Branch
Load Balancer
Web Server
Web Server
Web Server
App Server
App Server
App Server
Database

The massive Oracle database was reviewed at the architecture, instance, and I/O and query levels for areas of improvement. Hardware infrastructure – CPU, storage, and network, was reviewed to locate bottlenecks. Web and application server configurations and performance metrics were examined to identify optimizations in thread, memory, and connection resource management. Front-end and optimization were also conducted to identify simple changes that produced quick improvements in response time.

The Solution: Three Layers, Fixed Together

Rather than patch the symptom that was most visible, the web server outages, Avekshaa’s recommendations addressed load balancing, front-end configuration, and database performance as three interdependent problems that needed to be solved in the same pass.

Expert Insight

When outages happen multiple times a day across a large branch network, it’s tempting to focus entirely on server stability. But in engagements like this, load balancing and database tuning usually do more for perceived reliability than server-level fixes alone, because uneven load distribution is often what pushes an already-stressed server past its breaking point in the first place.

IndustryBanking
Scale3,000+ branches, 10,000 ATMs, multiple channels
Technology StackFinacle Core Banking, Oracle Database on Solaris (massive DB), IBM WebSphere Application Server, Resin
Core ProblemWeb server downtime 3-4 times per day; slow response times
Methodology

Avekshaa P-A-S-S™ optimization across the full technology stack

 

Results: Downtime Eliminated, Response Times Cut in Half

Avekshaa’s P-A-S-S™ optimization resulted in significant performance improvements across the entire system. Web server downtime, previously occurring 3-4 times per day, was eliminated. Database performance tuning delivered significantly faster response times, an improvement of roughly 50%, resulting in a better user experience and increased productivity across the branch network.

50%

improvement in response time following database performance tuning, alongside complete elimination of the web server downtime that was previously occurring 3-4 times a day.

  • Downtime eliminated: Web server outages went from 3-4 occurrences a day to zero.
  • Response times cut ~50%: Database health check-up and long-running query tuning drove the bulk of the improvement.
  • Better user experience, higher productivity: Branch staff and ATM transactions no longer routinely interrupted by instability.
  • Future-proofed: Avekshaa provided a comprehensive capacity plan so the bank could handle future growth without repeating the same failure pattern.

 

Key Takeaways for Banking IT Leaders

  1. Recurring outages are rarely one problem. A system failing 3-4 times a day is more likely to have several contributing weaknesses than a single root cause.
  2. Audit the whole path, not just the component that fails visibly. The web server was where outages showed up — but bandwidth, heap sizing, load balancing, and database queries all needed attention.
  3. Database tuning has an outsized impact at scale. A 50% response-time improvement came largely from query tuning and a database health check-up, not new infrastructure.
  4. Fix for the growth you expect, not just the load you have today. A capacity plan protects the gains from being eroded as transaction volume increases.
Share:

Frequently Asked Questions

What causes a core banking system to go offline repeatedly?

Repeated outages across a large branch and ATM network are usually a stack-wide problem, not a single point of failure — bandwidth saturation between branches and the data center, memory (heap) exhaustion on application servers under load, and inefficient database queries can each independently trigger downtime, and they often compound during peak transaction periods.

How was downtime eliminated for a bank running 3,000 branches and 10,000 ATMs?

Avekshaa audited the full transaction path — network bandwidth, application heap sizing, web and app server load balancing, front-end configuration, and database query performance — and implemented targeted fixes at each layer. Web server downtime, which previously occurred 3-4 times a day, was eliminated entirely.

What is heap analysis and why does it matter for banking systems?

Heap analysis examines how much memory an application server needs to handle expected transaction volume, and whether its current heap configuration is sized correctly. An undersized or misconfigured heap leads to excessive garbage collection, slow response times, and — at scale — server crashes under peak load.

How much did database performance improve in this case study?

Database performance tuning, including an overall database health check-up and identifying and tuning long-running queries, resulted in approximately 50% faster response times.

What technology stack was involved?

The stack included Finacle core banking software, an Oracle database running on Solaris, IBM WebSphere Application Server, and Resin web server.

Download Case Study

Book a Meeting