<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Engineering on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/engineering/</link><description>Recent content in Engineering on VisorCraft News</description><image><title>VisorCraft News</title><url>https://www.visorcraft.com/logo.png</url><link>https://www.visorcraft.com/logo.png</link></image><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 07 Jul 2026 21:35:24 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Building Resilient Systems: Lessons from the Field</title><link>https://www.visorcraft.com/news/2024/06/building-resilient-systems-lessons-from-the-field/</link><pubDate>Fri, 28 Jun 2024 14:30:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2024/06/building-resilient-systems-lessons-from-the-field/</guid><description>&lt;p>After running production systems at scale for the past year, we&amp;rsquo;ve learned a lot about building systems that don&amp;rsquo;t just work—they recover gracefully when things go wrong.&lt;/p>
&lt;h2 id="the-philosophy">The Philosophy&lt;/h2>
&lt;p>Resilience isn&amp;rsquo;t about preventing failures. It&amp;rsquo;s about designing systems that &lt;strong>expect&lt;/strong> failures and keep running anyway.&lt;/p>
&lt;h2 id="key-principles">Key Principles&lt;/h2>
&lt;h3 id="1-fail-fast-fail-open">1. Fail Fast, Fail Open&lt;/h3>
&lt;p>When something goes wrong, surface it immediately. Don&amp;rsquo;t hide errors behind silent failures.&lt;/p>
&lt;h3 id="2-assume-network-partitions">2. Assume Network Partitions&lt;/h3>
&lt;p>Networks are unreliable. Design your services to handle timeouts and retries gracefully.&lt;/p></description><content:encoded><![CDATA[<p>After running production systems at scale for the past year, we&rsquo;ve learned a lot about building systems that don&rsquo;t just work—they recover gracefully when things go wrong.</p>
<h2 id="the-philosophy">The Philosophy</h2>
<p>Resilience isn&rsquo;t about preventing failures. It&rsquo;s about designing systems that <strong>expect</strong> failures and keep running anyway.</p>
<h2 id="key-principles">Key Principles</h2>
<h3 id="1-fail-fast-fail-open">1. Fail Fast, Fail Open</h3>
<p>When something goes wrong, surface it immediately. Don&rsquo;t hide errors behind silent failures.</p>
<h3 id="2-assume-network-partitions">2. Assume Network Partitions</h3>
<p>Networks are unreliable. Design your services to handle timeouts and retries gracefully.</p>
<h3 id="3-graceful-degradation">3. Graceful Degradation</h3>
<p>If a non-critical service goes down, the rest of your system should continue functioning. Feature flags and circuit breakers are your friends.</p>
<h3 id="4-observability-first">4. Observability First</h3>
<p>You can&rsquo;t fix what you can&rsquo;t see. Structured logging, metrics, and tracing are table stakes.</p>
<h2 id="whats-next">What&rsquo;s Next</h2>
<p>We&rsquo;ll be sharing more deep dives into our architecture and tools in the coming weeks. Stay tuned!</p>
]]></content:encoded></item></channel></rss>