top of page
Search

The Anatomy of a High-Scale Outage & The Cold Cache Trap

martinladecky
Aug 17
3 min read

At 8:45 AM on a Monday, an incident alert replaced our daily stand-up. Over 200 engineers, operations leads, and executives joined the emergency bridge. Production was halted: database CPU hit 90%, response times degraded from 40ms to over 20 minutes, and customers could not log in. Because banking platforms operate as critical national infrastructure, every minute of total unavailability triggers mandatory self-reporting to financial regulators like BaFin.  



The Incident: False Positives and Cascading Timeouts

Monitoring tools initially indicated normal service health. Every backend database call returned successful HTTP 200 responses with zero recorded query failures. Despite this, users remained locked out.

The failure originated from a mismatch between backend latency and frontend configuration.



Standard Performance: Query response times typically averaged 40ms, with a 90th percentile of 60ms.  

Degraded Performance: Peak latency escalated to 20 minutes due to heavy data retrieval.  

Application Layer Failure: The application enforced a hardcoded 30-second timeout. Queries taking longer than 30 seconds were aborted at the client layer, resulting in immediate user lockouts.  


First Aid: Tactical Timeout Extension

Analyzing the query latency distribution showed that 95% of requests finished within 1 to 3 minutes; only extreme data outliers required 20 minutes.  

Without modifying the underlying database logic, we increased the hardcoded frontend timeout threshold. The patch was deployed to production within 15 minutes. Users experienced longer initial load times, but authentication succeeded, reducing load pressure and stabilizing the active user pool.


Root Cause: The Unprimed Flash Cache

Investigation revealed that application code and SQL execution plans had not changed. The issue originated from an unprimed cache following a weekend Disaster Recovery (DR) test.


Oracle Exadata accelerates query processing through specialized hardware layers:

  1. Smart Scan Offloading: Storage cell processors pre-filter row and column data prior to returning candidate sets to the database compute nodes.  

  2. Flash Cache Acceleration: Columnar flash caching prevents expensive disk lookups for hot partitions.

The failover transferred active traffic to an environment where the Smart Flash Cache was entirely unpopulated. Queries scanning 70-column tables across billions of rows fell back to reading raw blocks directly from physical disks. In AWR and diagnostic metrics, this appeared as extreme physical I/O waits rather than an explicit cache alert.


Resolution: Calculated Inaction

Switching back to the primary database was not viable because its local cache had been cleared upon shutdown. Executing ad-hoc batch scripts to manually populate tables during peak traffic (~1,000 req/sec) would have caused total compute starvation.

Because subsequent requests for identical accounts resolved in 50ms once cached, we chose to maintain system uptime without restarting services or flushing memory pools.



Restarting instances or flushing shared pools would have erased all accumulated warm cache blocks, restarting the physical read cycles. By letting production queries populate the Exadata Buffer Cache organically, database latency stabilized to normal thresholds over a 12-hour period.


Architectural Takeaways

  • Automate Cache Warming in DR Runbooks: Standard failover playbooks focus on replication states and IP routing, often overlooking storage tier warm-up. Systems relying on specialized caching hardware require scheduled warm-up routines before taking live traffic.

  • Decouple Frontend and Backend Timeouts: Static application timeouts turn latency anomalies into system-wide outages. Use adaptive backoff and circuit-breaking strategies to absorb transient database performance dips.

  • High-End Hardware Masks Inefficient Query Design: Exadata's compute and offloading capabilities masked heavy full-table-scan logic for years. The moment caching was removed, the read-side deduplication bottlenecks surfaced immediately.

 
 
 

Comments


©2021 by Martin Ladecký

bottom of page