Background Part 1 ended with a mistake worth fixing. Meera’s complaint was: “what is SQ \TPR HSPTLTY on my statement? I don’t recognise it at all.” The system flagged it as fraud every single time, with full confidence. And honestly, based on the words alone, that seemed fair. But the real issue wasn’t the prompt - it …

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 …

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 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 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 …

Background Architecture decisions rarely break at design time. They break a year later, under double the load, when an unwritten assumption proves false. I’ve seen this play out in synchronous coupling, storage models, and service splits - while architecting and designing FinTech platforms. That’s why I now run every …

Background This multi part series walks through the real architectural decisions and real mistakes behind designing a globally distributed KYC User Profile system - a system that should be capable of serving billions of users at 10M+ RPD with sub-500 ms P99 latency. It's mainly about weighing trade-offs and making …