Background In Part 0 we built the system that Meridian Bank already has as an existing banking system: a REST API over PostgreSQL that applies every dispute rule exactly, every time. Run the same request twice, get the same answer twice. That property of building deterministic systems and testing them out comes very …

Background Meera opens her banking app and sees a payment in her transaction history that she doesn't recognise: ₹180 to SQ *TPR HSPTLTY, four days ago. She had never heard of it. So she does the responsible thing - She opens the dispute form of her bank, picks "Unrecognised or fraudulent transaction", types …

The Scene A CTO of a small FinTech company had scheduled a meeting with me along with senior folks from his engineering team. CTO : (shares screen) "Look at this. Every 1st and 15th of month - 9:00 to 9:30 PM - Our p99 latency spikes from 50 ms to 800 ms. After 4 mins - back to normal. Surprisingly, no 5xx errors, …

What happens when senior leadership ships a "soft launch" to production without architectural review - and why every architect needs a battle-tested framework for saying no. Background A product company - has been building software for a industry that operates in highly regulated environment for more than …

Background This is the fifth post in a series on AI-augmented software engineering across the disciplines that matter most for production grade enterprise systems. The earlier posts covered ground that's probably more familiar with software engineering fraternity: Three Fintech Architecture Post-Mortems The GC Summary …

Background An older post on this blog covered the technical details of this incident - the GC types, the flags, the before-and-after metrics. This post covers something different: the process of how the investigation ran, where it lost time, and which decisions (with more structured approach) would have changed. The …

Background My earlier article on AI augmented Fintech post-mortem review walked through an Oracle JSON storage problem: a payment transaction table stored as JSON, a query that needed to filter on a nested field, and the chain of fixes - that the team eventually needed. Out of curiosity - a reasonable question came …

Background In Part 1, we established that access patterns & not entities should drive your design. In Part 2, we fixed the database by replacing brittle three-table JOINs with a covering index, reducing P99 on the listing query. The schema was right. The index was right. The listing API itself was fast. And then it …

Background My old article compared Virtual Thread based implementations of Spring Core Reactor and JDK 21, building on the comparative analysis before it. Both articles measured the usual things - total processing time, memory footprint, GC pauses, CPU time - and both relied on the summary report generated by GCEasy. …

Background In the first part we established the foundational principle that separates systems which survive scale from systems that collapse under it - design for access patterns, not for entities. In this second part we double click on the database design of the User Profile system and try to understand its impact …