10 Billion Records vs. The Regulator: An Architectural Post-Mortem of an 11TB Exadata Failure

What happens when your architecture doesn't just fail a performance test, but triggers a national regulatory investigation? In this session, we go inside a critical system failure at a major bank that led to a formal report to BaFin and a complete rethink of our data strategy.
Dealing with 11TB of data on Oracle Exadata taught us that at a certain scale—specifically, the 10-billion-record mark—standard indexing strategies and read-side duplicate checks don't just slow down; they collapse. We will reverse-engineer this incident by walking through the five critical architectural milestones:

1. First Aid: Immediate application-layer mitigation steps to halt cascading timeouts.
2. The Refactoring Oversight: How a missing 10-day query window check, removed years prior, silently waited to trigger an 11TB full scan.
3. The Cache Bottleneck: The high-stakes "do nothing" war room decision to wait for the Exadata Smart Flash Cache to warm up and recover.
4. The Structural Flip: Moving 10kB of complex analytic queries from read-side deduplication to a write-side integrity layer.
5. The Exit Strategy: Designing and planning a zero-loss dual-write ingestion architecture to migrate 10 billion records to Cloud PostgreSQL without CDC.

Walk away with an unvarnished, practical blueprint for navigating the compliance-performance paradox, handling database cold starts, and executing a zero-loss cloud modernization strategy under heavy pressure.