Severe performance issues affecting 15,000+ users of bank’s Internet services
The Challenge: Internet Banking Under Strain
Severe performance issues were affecting 15,000+ users of the bank’s internet services. For a channel that customers increasingly treat as their primary way of banking, checking balances, moving money, paying bills, repeated slowdowns and downtime incidents translate directly into support tickets, lost trust, and, at scale, reputational risk.
The platform ran on Finacle E-Banking, an Oracle Database (10G) on Solaris, and IBM WebSphere — a stack capable of serving this scale reliably, but only if every layer of it was actually tuned for the load it was carrying.
Why This Matters
Internet banking downtime doesn’t fail gracefully. Unlike a branch counter, where a teller can manually work around a slow system, a customer facing a frozen login page or a failed transfer simply can’t complete their task — and often can’t tell whether it’s safe to retry. At 15,000+ active users, even a modest incident rate compounds into a steady stream of support calls and eroded confidence in the channel.
Diagnosing the Bottleneck: A Six-Point Audit
Avekshaa conducted a P-A-S-S™ performance analysis as part of the optimization process. Historical logs were analyzed to identify recurring failure patterns first — rather than guessing at a root cause, the team let the incident history point to where to look. A comprehensive architecture review of the entire tech stack followed, and it revealed that the database was the key point of failure.
Performance Metrics
Analyzed system metrics and performance characteristics across all layers of the stack to establish a baseline of where time was actually being spent.
Monitoring
Reviewed the overall system monitoring mechanism, spanning commercial and open-source/custom tools, to assess whether issues were being caught early enough to act on.
Integration
Examined how unavailability and throttling were handled across integrations, and looked for optimization opportunities in how connections between systems were managed.
Single Points of Failure
Identified single points of failure across the architecture and recommended solutions to address each potential failure before it caused an incident.
Caching
Analyzed caching opportunities at the front end and in the application layer to reduce how often the platform needed to hit the database directly.
Database
Investigated failure analysis at the database layer, focused on reducing dependency on the database and limiting the impact of server failures when they did occur.
The Solution: Reduce Database Dependency, Remove Single Points of Failure
With the database confirmed as the key point of failure, Avekshaa’s recommendations focused on reducing how much load reached it in the first place, while also hardening the architecture around it.
Database
- Failure analysis to identify what was actually triggering incidents
- Reducing dependency on the database from upstream layers
- Reducing the impact of server failures when they occurred
Caching
- Front-end caching to serve repeat requests without a database round-trip
- Application-layer caching to cut redundant queries
Resilience & Architecture
- Recommendations for tuning and re-architecture of key components
- Mechanisms to address single points of failure directly
Expert Insight
Caching is often treated as a performance optimization, but in this kind of audit it functions as an availability fix too — every request served from cache is a request the database never has to handle, which means one less opportunity for a slow query to cascade into a downtime incident. Reducing database dependency and removing single points of failure aren’t separate workstreams; they reinforce each other.
| Industry | Banking |
| Scale | 15,000+ active internet banking users |
| Technology Stack | Finacle E-Banking, Oracle Database (10G) on Solaris, IBM WebSphere |
| Core Problem | Database was the key point of failure driving recurring downtime incidents |
| Methodology | Avekshaa P-A-S-S™ performance analysis with historical log review and architecture audit |
Results: Downtime and Incidents Both Down, Sharply
Avekshaa’s P-A-S-S™ optimization resulted in significant performance improvements that boosted the bank’s service levels, measured separately at the database and application layers, since each set of fixes targeted a different part of the problem.
|
DATABASE-LAYER SOLUTIONS
20%+
reduction in downtime
26%
reduction in downtime incidents
|
APPLICATION-LAYER SOLUTIONS
30%+
reduction in downtime
50%
reduction in downtime incidents
|
- Database downtime cut by more than 20%, with a 26% drop in downtime incidents at that layer specifically.
- Application downtime cut by more than 30%, with a 50% reduction in downtime incidents — the largest single gain in the engagement.
- Better service levels overall: the combined effect meaningfully improved reliability for all 15,000+ users of the platform.
- Targeted, measurable fixes: because database and application layers were tracked separately, the bank could see exactly which interventions were driving results.
Key Takeaways for Digital Banking Leaders
- Let incident history point to the root cause. Analyzing historical logs before architecture review focused the audit on patterns that were actually recurring, not just theoretical weak points.
- Caching is an availability tool, not just a speed tool. Reducing database dependency through caching cut both downtime and the frequency of incidents.
- Application-layer fixes can outperform database-layer fixes. The 50% incident reduction from application-layer work exceeded the database layer’s 26% — worth remembering when prioritizing engineering effort.
- Measure downtime and incident count separately. A shorter average outage and fewer outages are two different wins, and tracking both shows where fixes are actually working.
Share:
Frequently Asked Questions
What caused performance issues for 15,000+ internet banking users?
A combination of database-layer inefficiencies and application-layer weaknesses, including single points of failure, under-used caching opportunities, and insufficient monitoring across the internet banking stack, was driving recurring downtime incidents.
How do you reduce downtime incidents in an internet banking platform?
By running a full architecture review to identify single points of failure, analyzing caching opportunities at the front end and application layer to reduce database dependency, and tuning the database itself to reduce its role as a recurring point of failure.
Why is caching important for internet banking performance?
Caching at the front end and application layer reduces how often the platform has to query the database for the same data, cutting database dependency and load. This directly reduces both response times and the frequency of downtime incidents tied to database contention.
What is a single point of failure in a banking application architecture?
A single point of failure is any component in the transaction path — a firewall, load balancer, individual server, or database instance — that, if it fails, brings down the service with no redundancy to absorb the failure. Identifying and addressing these is a standard first step in an availability audit.
How much did downtime improve in this case study?
Database-layer solutions reduced downtime by more than 20% and downtime incidents by 26%. Application-layer solutions reduced downtime by more than 30% along with a 50% reduction in downtime incidents.