https://www.dhaval-shah.com/tags/distributed-systems/Recent content in distributed-systems on Dhaval ShahHugo -- gohugo.ioMon, 29 Jun 2026 01:00:50 +0000https://www.dhaval-shah.com/billion-user-pagination-db-design/Mon, 29 Jun 2026 01:00:50 +0000https://www.dhaval-shah.com/billion-user-pagination-db-design/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 quietly started taking the database down - not because of a bad query, but because of how that fast query was being paginated.https://www.dhaval-shah.com/gc-comparison-ai-review/Sun, 21 Jun 2026 02:00:50 +0000https://www.dhaval-shah.com/gc-comparison-ai-review/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. The conclusion from that data was straightforward: JDK based implementation requires more GC activity and a heavier memory footprint, but this does not have any significant impact on application performance.https://www.dhaval-shah.com/billion-user-trap-db-design/Tue, 16 Jun 2026 02:00:50 +0000https://www.dhaval-shah.com/billion-user-trap-db-design/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.https://www.dhaval-shah.com/fintech-post-mortem-ai-review/Thu, 11 Jun 2026 02:00:50 +0000https://www.dhaval-shah.com/fintech-post-mortem-ai-review/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.