https://mikemwita.com/thoughts/Recent content in Things I've Written on Mike MwitaHugoen-ushttps://mikemwita.com/thoughts/forget-everything-you-know-about-time/Sun, 02 Aug 2026 11:00:00 +0300https://mikemwita.com/thoughts/forget-everything-you-know-about-time/<p><span class="dropcap">M</span> itch Hedberg had a bit about late-night television:</p> <blockquote> <p>&ldquo;I saw a commercial on late-night TV, it said, &lsquo;Forget everything you know about slipcovers.&rsquo; So I did, and it was a load off my mind. Then the commercial tried to sell me slipcovers, but I didn&rsquo;t know what the hell they were.&rdquo;</p> </blockquote> <p>So here is my pitch: forget everything you know about time.</p> <p>I mean it. Put the intuition down and step away from it. You learned clocks and calendars before you could read, you have used them every single day since, and that fluency is precisely the problem — it is <em>conversational</em> fluency. It survives on ambiguity, because a human listener quietly patches the gaps for you. A computer will not. It takes your assumption, applies it with total consistency, and hands you back something wrong in a way you never thought to check.</p>https://mikemwita.com/thoughts/beyond-the-backend-basics/Wed, 07 Jan 2026 13:10:00 +0300https://mikemwita.com/thoughts/beyond-the-backend-basics/<h1 id="beyond-backend-basics"> Beyond Backend Basics <a href="#beyond-backend-basics" class="heading-anchor">#</a> </h1> <p>Most backend developers can build APIs, wire up databases, and scale services. That’s good. But “good” is not enough if your ambition is to become the kind of engineer who can design <strong>distributed systems that survive chaos</strong> and influence organizations at scale.</p> <p>It’s a checklist of some of the skills you need to learn now if you want to operate at the highest levels of engineering.</p>https://mikemwita.com/thoughts/unit-test/Tue, 21 Oct 2025 07:00:00 +0300https://mikemwita.com/thoughts/unit-test/<p>A while back, I was writing tests for a project using Python’s unittest. Nothing dramatic — just the usual rhythm: write a class, test it, move to the next one. After a few classes, though, the déjà vu hit.</p>https://mikemwita.com/thoughts/generating-go-code-from-openapi/Sun, 12 Oct 2025 07:00:00 +0300https://mikemwita.com/thoughts/generating-go-code-from-openapi/<p>A quick and practical walkthrough for developers who want to generate type-safe Go code directly from OpenAPI specs.</p>https://mikemwita.com/thoughts/bdd-tests-in-go/Tue, 12 May 2020 07:00:22 +0300https://mikemwita.com/thoughts/bdd-tests-in-go/<p>Testing is often seen as a technical safeguard — a way to ensure code correctness. But what if tests could do more than that? What if they could express intent, document behavior, and communicate meaning across developers, testers, and product owners alike?</p>https://mikemwita.com/thoughts/cache-invalidation/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/cache-invalidation/<h1 id="caching-is-easy-invalidation-is-where-systems-falter"> Caching Is Easy. Invalidation Is Where Systems Falter. <a href="#caching-is-easy-invalidation-is-where-systems-falter" class="heading-anchor">#</a> </h1> <p>Adding a cache is a one-afternoon task. You pick a layer, set a TTL, watch your database load drop. It feels like engineering.</p> <p>Invalidation is the part nobody writes down. It is also the part that wakes you up at 3am. Users seeing stale data after an update. A rollback that leaves garbage in cache for 24 hours. A race condition where two services update the same key in the wrong order and nobody notices for a week.</p>https://mikemwita.com/thoughts/escape-analysis-in-go/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/escape-analysis-in-go/https://mikemwita.com/thoughts/understanding-backpressure/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/understanding-backpressure/https://mikemwita.com/thoughts/foreign-function-interface/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/foreign-function-interface/https://mikemwita.com/thoughts/hexagonal-architecture-in-go/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/hexagonal-architecture-in-go/<p><span class="dropcap">M</span> ost Go services start out reasonable. A handler calls a database. A function returns a struct. Six months later, your HTTP handler is importing your database package, your database package is calling an external API, and your tests require a live Postgres instance to run a single unit.</p> <p>This is not a Go problem. It is an architecture problem — and hexagonal architecture is the structural answer.<aside class="sidenote">Also called <strong>ports and adapters</strong>, coined by Alistair Cockburn in 2005. The hexagon shape has no special meaning — it just illustrates that an application has multiple sides to connect.</aside> </p>https://mikemwita.com/thoughts/multitenancy-lessons-from-slack/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/multitenancy-lessons-from-slack/<h1 id="multitenancy-lessons-from-slack"> Multitenancy Lessons from Slack <a href="#multitenancy-lessons-from-slack" class="heading-anchor">#</a> </h1> <p>Slack looks like a messaging app. Under the hood, it is a multi-tenant distributed system solving problems that every SaaS platform eventually runs into — just at a scale that makes the problems impossible to ignore.</p> <p>If you think about it carefully, every architectural decision Slack makes is shaped by one central tension: <strong>every workspace feels isolated, but you cannot afford isolated infrastructure per customer.</strong></p>https://mikemwita.com/thoughts/domain-driven-design/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/domain-driven-design/<p><span class="dropcap">C</span> ontrary to what most people think, DDD is not about folder naming. It is not about having directories called <code>domain</code> and <code>infrastructure</code> and calling it a day.</p> <p>Here is my lightweight approach that helps you think about what your app domain actually is. The concept is straightforward: you see a domain, you create a directory for it. The real value is not in the structure itself — it is in the thinking the structure forces you to do.</p>https://mikemwita.com/thoughts/reading-flame-graphs-in-go/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/reading-flame-graphs-in-go/<p><span class="dropcap">I</span> nvisible performance bugs are the ones that scale with you. A function that takes 800 nanoseconds at 100 rows and 130 microseconds at 10,000 rows looks fine in every test you write on day one, and quietly becomes the reason a page hangs on day three hundred. You cannot fix what you cannot see — and a guess is not seeing.</p> <p>This is a walkthrough of making one such bug visible: write a benchmark, capture a CPU profile, and read the flame graph until the cost stops being a mystery. The example is a real lookup from <a href="https://github.com/MikeMwita/PayMeter">PayMeter</a>, a small Go payments service, but the workflow is the same for anything.<aside class="sidenote">Everything here uses only the standard toolchain — <code>go test</code>, <code>go tool pprof</code>, and Graphviz. No third-party profilers.</aside> </p>https://mikemwita.com/thoughts/sql-execution-order/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/sql-execution-order/<p><span class="dropcap">E</span> very developer who has written SQL has made the same mistake at least once: used a <code>SELECT</code> alias in a <code>WHERE</code> clause, or tried to filter on an aggregate without <code>HAVING</code>, and gotten an error that felt completely arbitrary. It is not arbitrary. It is the database telling you that you wrote the query in one order and expected it to execute in that order. It does not.</p> <p>Understanding the actual execution order is one of those things that turns SQL from a language you fight into a language you reason with.</p>https://mikemwita.com/thoughts/username-availability-at-scale/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/username-availability-at-scale/<p><img src="https://mikemwita.com/images/gmail-username-check.png" alt="Gmail username availability check — &ldquo;newuser&rdquo; is taken, n12205707 is suggested"></p> <p>You type &ldquo;newuser&rdquo; into the Gmail signup screen. Already taken. The UI suggests &ldquo;n12205707&rdquo; before you have even stopped typing. No spinner. No network flicker. Just instant.</p> <p>You are not doing an Elasticsearch query on every keypress. That would be a crime.</p> <p>So how does it work? I want to walk through what I think is the right solution — the math behind it, and why most engineers reach for the wrong tool first.</p>https://mikemwita.com/thoughts/cache-stampede/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/cache-stampede/<h1 id="the-thundering-herd-problem"> The Thundering Herd Problem <a href="#the-thundering-herd-problem" class="heading-anchor">#</a> </h1> <p>Your site&rsquo;s homepage is heavily cached. The cache key expires every 60 seconds. At 12:00 PM, the cache expires. At 12:00:01 PM, 10,000 concurrent user requests come in. None of them find anything in cache. All 10,000 hit your database simultaneously to regenerate the exact same content.</p> <p>Your database crashes. The site goes down.</p> <p>This is a <strong>cache stampede</strong>, also called a thundering herd. The irony is that the cache was there to protect the database. The moment it failed to do its job, it caused something worse than if it had never existed.</p>https://mikemwita.com/thoughts/what-it-takes-to-be-a-real-go-engineer/Mon, 01 Jan 0001 00:00:00 +0000https://mikemwita.com/thoughts/what-it-takes-to-be-a-real-go-engineer/<p><span class="dropcap">M</span> ost developers can learn Go&rsquo;s syntax in a weekend. Goroutines, channels, interfaces, error handling — the surface area is deliberately small. That is one of Go&rsquo;s design strengths. It is also the trap.</p> <p>The hard parts of Go are invisible in the syntax: knowing <em>when</em> to reach for concurrency, <em>why</em> a value is escaping to the heap, <em>what</em> your goroutines are doing when the load spikes at 3am.</p> <aside class="pullquote"> Syntax is the easy part. Judgment is what production actually tests. </aside> <div class="section-divider"> <span></span><span></span><span></span> </div> <h2 id="concurrency-is-a-tool-not-a-default"> Concurrency Is a Tool, Not a Default <a href="#concurrency-is-a-tool-not-a-default" class="heading-anchor">#</a> </h2> <p>Go makes concurrency syntactically trivial. That is a feature and a footgun in the same breath. In older systems languages, spawning a thread was expensive and awkward — the friction forced you to think. In Go, you write <code>go</code> and move on. The language removes the friction. The problem does not.</p>