<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Sidecar - Tag - Lorenzo's Blog</title><link>https://www.k8s.it/tags/sidecar/</link><description>Sidecar - Tag - Lorenzo's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sat, 11 Feb 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://www.k8s.it/tags/sidecar/" rel="self" type="application/rss+xml"/><item><title>Application Rate Limit</title><link>https://www.k8s.it/posts/application-rate-limiting/</link><pubDate>Sat, 11 Feb 2023 00:00:00 +0000</pubDate><author>Lorenzo Girardi</author><guid>https://www.k8s.it/posts/application-rate-limiting/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/application-rate-limiting/Screenshot-2023-02-11-at-13.18.48.png" referrerpolicy="no-referrer">
            </div><p>I needed to implement rate limiting within an application for reasons I&rsquo;ll get into in a follow-up post. When you start thinking about this, you basically have two paths:</p>
<ol>
<li>Logic embedded directly in the application code</li>
<li>A sidecar container that handles the rate limiting role</li>
</ol>
<p>Both work. Both have trade-offs. Let me go through each one.</p>
<h2 id="the-code-way">The Code Way</h2>
<p>This is the simpler approach on the surface, but it comes with some annoying limitations. It can only be reused for applications in the same programming language. And adding rate limiting logic inside the application creates a secondary role — meaning the request interceptor will consume CPU and may produce <em>false</em> metrics if you&rsquo;re not tracking it carefully.</p>]]></description></item></channel></rss>