<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>architecture on Dhaval Shah</title><link>https://www.dhaval-shah.com/categories/architecture/</link><description>Recent content in architecture on Dhaval Shah</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Mon, 29 Jun 2026 01:00:50 +0000</lastBuildDate><atom:link href="https://www.dhaval-shah.com/categories/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Billion User Trap - The Pagination Mistake That Can Take Down Your Database</title><link>https://www.dhaval-shah.com/billion-user-pagination-db-design/</link><pubDate>Mon, 29 Jun 2026 01:00:50 +0000</pubDate><guid>https://www.dhaval-shah.com/billion-user-pagination-db-design/</guid><description>Background In Part 1, we established that access patterns &amp;amp; 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 quietly started taking the database down - not because of a bad query, but because of how that fast query was being paginated.</description></item><item><title>Billion User Trap - The Database Design That Looked Perfect on Day One</title><link>https://www.dhaval-shah.com/billion-user-trap-db-design/</link><pubDate>Tue, 16 Jun 2026 02:00:50 +0000</pubDate><guid>https://www.dhaval-shah.com/billion-user-trap-db-design/</guid><description>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 from performance engineering and scalability standpoint. Specifically - why the schema that adheres to proper normalization, proper foreign keys, and proper indexes, becomes a latency problem.</description></item><item><title>Three Fintech Architecture Post-Mortems - What AI-Augmented Review Would Have Caught</title><link>https://www.dhaval-shah.com/fintech-post-mortem-ai-review/</link><pubDate>Thu, 11 Jun 2026 02:00:50 +0000</pubDate><guid>https://www.dhaval-shah.com/fintech-post-mortem-ai-review/</guid><description>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 major design decision through an AI-augmented review process.
What follows are three post‑mortems from real payment systems - and the simple prompts that would have flagged each failure before it hit production.</description></item><item><title>The Billion-User Trap</title><link>https://www.dhaval-shah.com/billion-user-trap-2-simple-apis/</link><pubDate>Sat, 06 Jun 2026 02:00:50 +0000</pubDate><guid>https://www.dhaval-shah.com/billion-user-trap-2-simple-apis/</guid><description>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 architectural decisions.
Not theory. Not a tutorial. No &amp;quot;here's how Redis works.&amp;quot;
If you already know what a cache stampede is, what CDC does, and why OFFSET pagination is dangerous — this series is written for you.</description></item></channel></rss>