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 …

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 …

Background In the previous article, we explored resiliency and fault tolerance as critical enablers of high‑volume inter‑cloud data transfer. Yet even the most resilient system cannot succeed without deep visibility into its live operations. This final part of the series focuses on observability Observability - A …

Background Parts 1 and 2 established the what and the how fast — a stateless, chunk-driven pipeline with deterministic block IDs, reactive backpressure, and an adaptive concurrency controller functions under real cloud conditions. But speed and elegant architecture count for nothing if application crash at chunk 73 of …