<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Microservices on Ikwuka Okoye</title><link>https://ikwukao.dev/tags/microservices/</link><description>Recent content in Microservices on Ikwuka Okoye</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 10 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://ikwukao.dev/tags/microservices/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing a Fault-Tolerant API Gateway in Go</title><link>https://ikwukao.dev/journal/designing-a-fault-tolerant-api-gateway-in-go/</link><pubDate>Mon, 10 Aug 2026 00:00:00 +0000</pubDate><guid>https://ikwukao.dev/journal/designing-a-fault-tolerant-api-gateway-in-go/</guid><description>&lt;h2 id="designing-a-fault-tolerant-api-gateway-in-go"&gt;Designing a Fault-Tolerant API Gateway in Go&lt;/h2&gt;
&lt;p&gt;An API gateway sits at an uncomfortable boundary.&lt;/p&gt;
&lt;p&gt;It receives traffic from clients, but the work is usually performed somewhere else. Every request that passes through the gateway eventually depends on downstream services, networks, databases, caches, or other infrastructure.&lt;/p&gt;
&lt;p&gt;That makes the gateway more than a reverse proxy.&lt;/p&gt;
&lt;p&gt;It becomes one of the places where reliability decisions have to be made.&lt;/p&gt;
&lt;p&gt;This is the problem I wanted to explore while building &lt;strong&gt;Flux-Gateway&lt;/strong&gt;, a high-performance API gateway and reverse proxy written in Go.&lt;/p&gt;</description></item><item><title>Designing Fail-Fast Boundaries for Microservices</title><link>https://ikwukao.dev/journal/fail-fast-microservices/</link><pubDate>Sun, 09 Aug 2026 00:00:00 +0000</pubDate><guid>https://ikwukao.dev/journal/fail-fast-microservices/</guid><description>&lt;h2 id="designing-fail-fast-boundaries-for-microservices"&gt;Designing Fail-Fast Boundaries for Microservices&lt;/h2&gt;
&lt;p&gt;One of the easiest mistakes to make in distributed systems is assuming that a failed request is simply a request that returned an error.&lt;/p&gt;
&lt;p&gt;A timeout is more expensive.&lt;/p&gt;
&lt;p&gt;The system may have spent seconds holding connections, goroutines, memory, and other resources before discovering that the dependency could not respond.&lt;/p&gt;
&lt;p&gt;That is why fail-fast behavior is an important reliability mechanism.&lt;/p&gt;
&lt;h2 id="slow-failure-is-still-failure"&gt;Slow Failure Is Still Failure&lt;/h2&gt;
&lt;p&gt;Consider a request travelling through several services:&lt;/p&gt;</description></item></channel></rss>