<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systems-Thinking on Lorbic</title><link>http://localhost:1313/tags/systems-thinking/</link><description>Recent content in Systems-Thinking on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 22 Jul 2026 12:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/systems-thinking/index.xml" rel="self" type="application/rss+xml"/><item><title>Cache-Driven Development: Saving Your Database From Itself</title><link>http://localhost:1313/cache-driven-development/</link><pubDate>Wed, 22 Jul 2026 12:00:00 +0530</pubDate><guid>http://localhost:1313/cache-driven-development/</guid><description>&lt;p>There is a moment in every backend engineer&amp;rsquo;s life when their database starts refusing connections.&lt;/p>
&lt;p>Picture 2 a.m. on a Tuesday. The app is operating under normal traffic, nothing unusual. But the database connection pool is saturated. Queries are timing out. The monitoring dashboard shows 50,000 database operations per second, far beyond what the system should be handling.&lt;/p>
&lt;p>When someone pulls the slow-query logs, the pattern is immediately clear. The same query appears thousands of times:&lt;/p></description></item><item><title>So, We Are Writing Efficient Software Again</title><link>http://localhost:1313/so-we-are-writing-efficient-software-again/</link><pubDate>Wed, 17 Jun 2026 20:00:00 +0530</pubDate><guid>http://localhost:1313/so-we-are-writing-efficient-software-again/</guid><description>&lt;p>I wanted to upgrade the RAM in my PC.&lt;/p>
&lt;p>Nothing fancy. I bought 32GB in 2024 and I wanted to double it. I opened a tab, checked the price, and closed the tab. Then I sat quietly for a moment.&lt;/p>
&lt;p>The same 32GB kit I bought in 2024 now costs more than double. DDR5 prices have gone up roughly 400% since mid-2025 [1]. DDR4 is not much better. A kit that cost $60–$90 in late 2025 now sells for $150–$180 [2].&lt;/p></description></item><item><title>Constructing Concurrent Inverted Indexes in Go</title><link>http://localhost:1313/constructing-concurrent-inverted-indexes-in-go/</link><pubDate>Tue, 16 Jun 2026 22:00:00 +0530</pubDate><guid>http://localhost:1313/constructing-concurrent-inverted-indexes-in-go/</guid><description>&lt;p>I spent a Saturday afternoon benchmarking a concurrent inverted index and discovered that a single &lt;code>sync.RWMutex&lt;/code> starts to break down at roughly 4 concurrent readers. The degradation is not linear. It is not graceful. It is a cliff.&lt;/p>
&lt;p>The inverted index is one of the oldest data structures in information retrieval. It maps terms to the documents that contain them, forming the backbone of every search engine from Elasticsearch to Lucene to Google&amp;rsquo;s earliest prototypes. The data structure itself is simple. Making it fast under concurrent load is not.&lt;/p></description></item><item><title>A Love Letter to the L1 Cache</title><link>http://localhost:1313/love-letter-to-the-l1-cache/</link><pubDate>Mon, 15 Jun 2026 19:00:00 +0530</pubDate><guid>http://localhost:1313/love-letter-to-the-l1-cache/</guid><description>&lt;p>I recently spent four hours staring at a benchmark that didn&amp;rsquo;t make sense.&lt;/p>
&lt;p>It started while working on &lt;a href="https://github.com/vikash-paf/derelict-facility" target="_blank" rel="noopener noreferrer">Derelict Facility&lt;/a>, my grid-based game engine in Go. I was trying to tighten the main update loop, specifically the part that iterates over every entity on the map each frame. I pulled out a small benchmark to isolate the cost, and something looked wrong.&lt;/p>
&lt;p>I had two Go structs. They held the exact same data: two booleans and a 64-bit integer. I was iterating over a slice of 10 million of these structs, doing a simple addition. They should have been identical in performance.&lt;/p></description></item><item><title>Why Explaining Technical Difficulty is Hard</title><link>http://localhost:1313/why-explaining-technical-difficulty-is-hard/</link><pubDate>Thu, 14 May 2026 01:00:00 +0530</pubDate><guid>http://localhost:1313/why-explaining-technical-difficulty-is-hard/</guid><description>&lt;p>&amp;ldquo;Can we just add a real-time visitor counter to the homepage? It&amp;rsquo;s just a query, right&amp;rdquo;?&lt;/p>
&lt;p>Every engineer has heard some variation of this. On the surface, the logic is sound. You have data, you have a UI, and you want to connect them. In the world of business requirements, this is a solved problem. You write a line of code, and the feature exists.&lt;/p>
&lt;p>But your database doesn&amp;rsquo;t care about business logic. It cares about &lt;strong>Infrastructure Constraints&lt;/strong>.&lt;/p></description></item><item><title>AI Coding in 2026: Productivity Multipliers vs. Skill Replacements</title><link>http://localhost:1313/ai-coding-productivity-vs-skill/</link><pubDate>Sat, 28 Mar 2026 23:00:00 +0530</pubDate><guid>http://localhost:1313/ai-coding-productivity-vs-skill/</guid><description>&lt;p>&amp;ldquo;Write a REST API with authentication&amp;rdquo;.&lt;/p>
&lt;p>I hit enter. Thirty seconds later, Claude spat out 400 lines of perfectly formatted Go code. JWT middleware, password hashing, error handling, even rate limiting. It looked professional. It looked production-ready.&lt;/p>
&lt;p>It took me three hours to figure out why the token refresh logic had a race condition.&lt;/p>
&lt;p>This is AI-assisted coding in 2026. It&amp;rsquo;s not magic. It&amp;rsquo;s not a replacement. It&amp;rsquo;s a very fast junior developer that never gets tired, never complains, and confidently makes mistakes you won&amp;rsquo;t catch unless you actually understand the &lt;strong>architectural nuances&lt;/strong> of what you&amp;rsquo;re building.&lt;/p></description></item><item><title>What Couchbase Taught Me About System Thinking</title><link>http://localhost:1313/what-couchbase-taught-me-about-system-thinking/</link><pubDate>Tue, 18 Nov 2025 02:20:06 +0530</pubDate><guid>http://localhost:1313/what-couchbase-taught-me-about-system-thinking/</guid><description>&lt;h2 id="couchbase-internals-indexes-queries-consistency-and-performance">Couchbase Internals: Indexes, Queries, Consistency, and Performance&lt;a class="anchorjs-link" href="#couchbase-internals-indexes-queries-consistency-and-performance" aria-label="Link to section: Couchbase Internals: Indexes, Queries, Consistency, and Performance">&lt;/a>&lt;/h2>&lt;h3 id="introduction">Introduction&lt;a class="anchorjs-link" href="#introduction" aria-label="Link to section: Introduction">&lt;/a>&lt;/h3>&lt;p>Over the last few years I&amp;rsquo;ve lived deep inside backend systems, and for the past year and a half Couchbase has been my daily companion. Working with Go services that depend on Couchbase taught me that the real lessons aren&amp;rsquo;t in the marketing slides or quick‑start guides. They&amp;rsquo;re in the internals: how indexes are built, how queries are planned, how consistency flags change the story, and how durability levels quietly decide whether your system survives a failure or not.&lt;/p></description></item><item><title>What Facebook's Memcache Taught Me About Systems Thinking</title><link>http://localhost:1313/scaling-memcache-facebook/</link><pubDate>Mon, 07 Jul 2025 14:03:00 +0000</pubDate><guid>http://localhost:1313/scaling-memcache-facebook/</guid><description>&lt;p>What Facebook&amp;rsquo;s Memcache Taught Me About Systems Thinking&lt;/p>
&lt;blockquote>
&lt;p>&amp;ldquo;The probability of reading transient stale data is a tunable parameter&amp;rdquo;. - Scaling Memcache at Facebook (NSDI, 2013)&lt;/p>&lt;/blockquote>
&lt;p>There&amp;rsquo;s a moment in every engineer&amp;rsquo;s life when a seemingly simple component like a cache, suddenly becomes the most complex piece in the stack. For me, that moment arrived reading Facebook&amp;rsquo;s paper on scaling Memcache.
I didn&amp;rsquo;t expect a key-value store to challenge my understanding of systems architecture. But this paper wasn&amp;rsquo;t about cache keys or TTLs. It was about what happens when infrastructure hits the limits of scale, physics, and human reliability.&lt;br>
What follows isn&amp;rsquo;t a summary. It&amp;rsquo;s a set of systems insights that stayed with me, principles that go deeper than code and that I now see everywhere.&lt;/p></description></item></channel></rss>