
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Backend | karas.codes</title>
        <link>https://karas.codes/tags/backend/</link>
        <description>Articles tagged Backend on karas.codes</description>
        
        <language>en-us</language>
        <copyright>© Andrzej Karaś</copyright>
        <lastBuildDate>Mon, 06 Mar 2023 00:00:00 +0000</lastBuildDate>
        
        <atom:link href="https://karas.codes/tags/backend/index.xml" rel="self" type="application/rss+xml" />
        
        
        
        <item>
            <title>Designing for Graceful Failure by Separating Failure Domains</title>
            <link>https://karas.codes/posts/why-separating-services-could-let-your-app-fail-gradually/</link>
            <pubDate>Mon, 06 Mar 2023 00:00:00 +0000</pubDate>
            <guid>https://karas.codes/posts/why-separating-services-could-let-your-app-fail-gradually/</guid>
            <description>


                &lt;h2 id=&#34;context&#34;&gt;Context&lt;/h2&gt;
&lt;p&gt;Some time ago my team in a company that I work on had really serious issue. I fixed one feature that started working as expected, but it also started sending a lot more notification emails to our clients - nearly 150k / a day.&lt;/p&gt;
&lt;p&gt;As you probably guess we ran out of quota. What&amp;rsquo;s worse it happened for all applications we develop.&lt;/p&gt;
&lt;h2 id=&#34;how-could-we-prevent-it&#34;&gt;How could we prevent it?&lt;/h2&gt;
&lt;p&gt;My advice probably is not ideal and won&amp;rsquo;t save you in similar case, but it will:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;help you survive longer&lt;/li&gt;
&lt;li&gt;give more time to prepare a fix&lt;/li&gt;
&lt;li&gt;won&amp;rsquo;t crash all applications or modules that are sending emails, fail gradually in other words&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;solution&#34;&gt;Solution&lt;/h2&gt;
&lt;p&gt;Solution is very simple. When developing such thing as sending emails that are very important from business perspective. You should divide quota per every application or module that would be using it.&lt;/p&gt;
&lt;p&gt;Thanks to that:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;only one app or module would be affected or ran out of quota (the rest would be working as intended)&lt;/li&gt;
&lt;li&gt;it will give you a space to shift quota a little if needed&lt;/li&gt;
&lt;li&gt;it will give you more time to prepare a fix, because not all parts of your app would be affected&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;additional-steps&#34;&gt;Additional steps&lt;/h2&gt;
&lt;p&gt;Of course this is not only thing you could do. You could:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;implement sending emails or notifications in bulk as my very smart colleague did :)&lt;/li&gt;
&lt;li&gt;implement metrics and alerting in order to spot your problem before your app would be crashed&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;summary&#34;&gt;Summary&lt;/h2&gt;
&lt;p&gt;So as you see following very simple rule of applications and modules separation on application or infrastructure level let&amp;rsquo;s say gives you one very important thing. Your system is more resilient and your customers won&amp;rsquo;t be affected by bugs so often.&lt;/p&gt;

            </description>
        </item>
        
        
    </channel>
</rss>