<?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 Lorbic</title><link>http://localhost:1313/tags/architecture/</link><description>Recent content in Architecture on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 13 Aug 2026 18:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>How Go Channels Actually Work</title><link>http://localhost:1313/go-channels-deep-dive/</link><pubDate>Thu, 13 Aug 2026 18:00:00 +0530</pubDate><guid>http://localhost:1313/go-channels-deep-dive/</guid><description>&lt;p>A single unbuffered channel send without an active receiver is enough to silently lock up a production worker pool, leaking memory until your service gets killed by the OS kernel.&lt;/p>
&lt;p>On the surface, Go channels look simple: they synchronize concurrent execution without manual mutex management. But under heavy load, a minor oversight in channel sizing or worker coordination blocks the scheduler, leaks memory, or crashes processes with runtime panics.&lt;/p>
&lt;p>&lt;picture class="optimized-image-container">&lt;source srcset="http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_524f15f4ab89fd6f.webp 480w, http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_50f95d885458376d.webp 646w" sizes="(max-width: 800px) 100vw, 800px" type="image/webp">&lt;img src="http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_50f95d885458376d.webp" width="646" height="797" alt="The Go scheduler coordinating 10,000 goroutines on a single-core CPU" loading="eager" decoding="async" fetchpriority="high" class="img-fluid" />
 &lt;/picture>&lt;/p></description></item><item><title>Designing a Distributed Job Scheduler in Go: Partitioning, Locking, and Backpressure</title><link>http://localhost:1313/designing-a-distributed-job-scheduler/</link><pubDate>Sun, 09 Aug 2026 14:00:00 +0530</pubDate><guid>http://localhost:1313/designing-a-distributed-job-scheduler/</guid><description>&lt;p>Linux &lt;code>crontab&lt;/code> is one of the most elegant pieces of software ever written for single-host automation. It is simple, clear, and has kept Unix systems running reliably since 1975.&lt;/p>
&lt;p>The problem starts when we take a single-host tool and deploy it across a multi-node cloud setup.&lt;/p>
&lt;p>In &lt;a href="http://localhost:1313/how-multi-tenant-saas-works/">Relay&lt;/a>, a multi-tenant AI API gateway system design, background jobs power core operations: every top of the hour, a job rolls up raw API usage tokens into tenant billing metrics; every 15 minutes, another job scans for expired API keys and purges them from cache; every 30 seconds, a health checker pings upstream LLM provider endpoints.&lt;/p></description></item><item><title>Designing a Usage-Based Billing Pipeline for SaaS</title><link>http://localhost:1313/designing-a-usage-based-billing-pipeline-for-saas/</link><pubDate>Sat, 01 Aug 2026 17:26:52 +0530</pubDate><guid>http://localhost:1313/designing-a-usage-based-billing-pipeline-for-saas/</guid><description>&lt;p>In &lt;a href="http://localhost:1313/posts/2026-07-01-how-multi-tenant-saas-works/" data-preview-title="How Multi-Tenant SaaS Actually Works" data-preview-desc="A complete system design of Relay, a multi-tenant AI API gateway. Covers multi-tenant database architecture (silo vs pool vs bridge), API key authentication, provider routing with failover, dual-layer rate limiting, token-based billing, response caching, row-level security, tenant provisioning, and observability. Full Postgres schemas, mermaid diagrams, and Go snippets included." data-preview-time="37 min read">How Multi-Tenant SaaS Actually Works&lt;/a>, I left one major promise unfulfilled at the end: &lt;em>&amp;ldquo;Billing is an entire system design on its own. The billing pipeline gets its own post.&amp;rdquo;&lt;/em>&lt;/p></description></item><item><title>API Design for Backend Systems</title><link>http://localhost:1313/api-design-for-backend-systems/</link><pubDate>Sun, 26 Jul 2026 19:00:00 +0530</pubDate><guid>http://localhost:1313/api-design-for-backend-systems/</guid><description>&lt;p>A few weeks ago I designed &lt;a href="http://localhost:1313/how-multi-tenant-saas-works/">Relay&lt;/a>, a multi-tenant AI API gateway, as a system design exercise. That post covered the database, the auth, the billing. It did not cover the thing every one of those systems is sitting behind: the API itself.&lt;/p>
&lt;p>Here is the question that post left open. When someone builds &lt;code>GET /v1/requests&lt;/code> to list a tenant&amp;rsquo;s API call history, what should that endpoint actually look like? Offset or cursor pagination? What does the response envelope contain? What happens when Relay needs to add a filter that does not fit in a query string? What does a webhook payload look like when Relay tells a tenant &amp;ldquo;your batch job finished&amp;rdquo;? None of that is specific to AI gateways. It is the same decisions every backend API makes, made badly often enough that &amp;ldquo;REST API&amp;rdquo; has become a phrase that means &amp;ldquo;JSON over HTTP, structure unspecified.&amp;rdquo;&lt;/p></description></item><item><title>Designing a Distributed Rate Limiter with Redis</title><link>http://localhost:1313/designing-a-rate-limiter/</link><pubDate>Tue, 07 Jul 2026 17:00:00 +0530</pubDate><guid>http://localhost:1313/designing-a-rate-limiter/</guid><description>&lt;p>There is a class of bugs that only happen at midnight.&lt;/p>
&lt;p>Your API has a rate limit: 1000 requests per minute. A client hits 999 at 11:59:59 PM, then fires another 999 at 12:00:00 AM. Two windows, two clean counters, all 1998 requests allowed. Your database gets a spike it was never designed to handle, and you spend the next hour wondering how your rate limiter let this through.&lt;/p>
&lt;p>It did let it through. You just did not know it.&lt;/p></description></item><item><title>How Multi-Tenant SaaS Actually Works</title><link>http://localhost:1313/how-multi-tenant-saas-works/</link><pubDate>Wed, 01 Jul 2026 00:00:00 +0530</pubDate><guid>http://localhost:1313/how-multi-tenant-saas-works/</guid><description>&lt;p>For the past month I have been reading about multi-tenant SaaS architecture. Not as an academic exercise. I kept running into the same questions on every project I looked at: where exactly does tenant data go, how do you stop one customer&amp;rsquo;s bug from becoming every customer&amp;rsquo;s problem, how does billing actually work at the database level. The blog posts I found were either too abstract or skipped the hard parts entirely.&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>Just About Go Time</title><link>http://localhost:1313/just-about-go-time/</link><pubDate>Sun, 10 May 2026 22:00:00 +0530</pubDate><guid>http://localhost:1313/just-about-go-time/</guid><description>&lt;p>Time is an illusion. Or more accurately, time is a political consensus poorly masquerading as physics.&lt;/p>
&lt;p>&lt;picture class="optimized-image-container">&lt;source srcset="http://localhost:1313/just-about-go-time/time-theory-meme_hu_c027f9156a69cf21.webp 480w, http://localhost:1313/just-about-go-time/time-theory-meme_hu_c74845a5e28401ee.webp 800w, http://localhost:1313/just-about-go-time/time-theory-meme_hu_22fbca4a5f8175a5.webp 1200w, http://localhost:1313/just-about-go-time/time-theory-meme_hu_c495ad8b67b2bacf.webp 1222w" sizes="(max-width: 800px) 100vw, 800px" type="image/webp">&lt;img src="http://localhost:1313/just-about-go-time/time-theory-meme_hu_c495ad8b67b2bacf.webp" width="1222" height="1514" alt="Time is relative, absolute, and a scam" loading="eager" decoding="async" fetchpriority="high" class="img-fluid" />
 &lt;/picture>&lt;/p>
&lt;p>If you&amp;rsquo;ve ever seen Dylan Beattie&amp;rsquo;s &amp;ldquo;Plain Text&amp;rdquo; &lt;a href="https://www.youtube.com/watch?v=gd5uJ7Nlvvo" target="_blank" rel="noopener noreferrer">talk&lt;/a>, you know that humans have spent centuries making data storage as complicated as possible. But text encoding has nothing on time zones.&lt;/p>
&lt;p>As engineers, we like to pretend that &lt;code>time.Now()&lt;/code> returns an objective truth. It doesn&amp;rsquo;t. It returns a snapshot of a highly contested, historically unstable set of political boundaries. In 2011, the island nation of Samoa decided they wanted to align their workweek with Australia rather than the United States. To do this, they didn&amp;rsquo;t just change their clocks; they completely skipped Friday, December 30th. At 11:59 PM on Thursday, the clock ticked over, and it was suddenly Saturday.&lt;/p></description></item><item><title>Why Your Goroutines Need a Speed Limit: Bounded Concurrency in Go</title><link>http://localhost:1313/bounded-concurrency-in-go/</link><pubDate>Fri, 10 Apr 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/bounded-concurrency-in-go/</guid><description>&lt;p>&lt;strong>TL;DR:&lt;/strong> Spawning &lt;code>go func()&lt;/code> without a limiter is a recipe for system collapse. This guide details how to use &lt;strong>Semaphores&lt;/strong> and &lt;strong>Worker Pools&lt;/strong> to prioritize predictable stability over absolute speed, protecting downstream dependencies from the thundering herd.&lt;/p>
&lt;hr>
&lt;p>It&amp;rsquo;s a rite of passage for every Go developer. You receive a list of 10,000 URLs to fetch or 50,000 rows to process. You wrap the workload in an unbounded &lt;code>go func()&lt;/code> loop, achieving maximum throughput in milliseconds.&lt;/p></description></item><item><title>Part 2: Decoupling the Renderer: Terminal to Raylib in One Interface</title><link>http://localhost:1313/decoupling-game-engine-renderer-raylib/</link><pubDate>Mon, 06 Apr 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/decoupling-game-engine-renderer-raylib/</guid><description>&lt;p>The biggest architectural mistake you can make when building a game engine is letting the game know how it is being drawn.&lt;/p>
&lt;p>When I started building the &lt;em>Derelict Facility&lt;/em> engine, the output target was a raw ANSI terminal. The engine calculated A* paths, resolved line-of-sight, and then spewed escape codes (&lt;code>\033[31m&lt;/code>) to &lt;code>os.Stdout&lt;/code>.&lt;/p>
&lt;p>Eventually, I hit the physical limits of terminal emulators: inconsistent character widths (especially for emojis), slow double-buffering, and a hard cap on frame rates. I needed to move to a real, hardware-accelerated graphics library like Raylib.&lt;/p></description></item><item><title>OLTP vs OLAP - Why You Need Two Databases</title><link>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</link><pubDate>Sun, 11 Jan 2026 21:00:00 +0530</pubDate><guid>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</guid><description>&lt;p>At a recent ClickHouse conference in New Delhi, I attended this Saturday. There were many interesting sessions, but one that stood out was a talk on multi-tenant analytics at scale. I was reminded of a fundamental truth in backend engineering: &amp;ldquo;The database that runs your app cannot be the database that analyzes your app&amp;rdquo;.&lt;/p>
&lt;p>Early in a startup&amp;rsquo;s life, we shove everything into one database. User profiles, session data, logs, and analytics events all live in the same Postgres, Mongo, or Couchbase instance. It works, until it throttles.&lt;/p></description></item></channel></rss>