<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Gabardo Engineering]]></title><description><![CDATA[Gabardo Engineering is a technical publication showcasing applied software engineering work. Topics include system design, algorithm implementation and optimisation, and the practical trade-offs encountered in real-world systems.]]></description><link>https://writing.gabardo.engineering</link><image><url>https://substackcdn.com/image/fetch/$s_!kbes!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F457be54d-f4c6-40bf-bd5a-b96250eb2e4c_675x675.png</url><title>Gabardo Engineering</title><link>https://writing.gabardo.engineering</link></image><generator>Substack</generator><lastBuildDate>Mon, 05 Oct 2026 08:41:06 GMT</lastBuildDate><atom:link href="https://writing.gabardo.engineering/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Adrian Gabardo]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[gabardoengineering@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[gabardoengineering@substack.com]]></itunes:email><itunes:name><![CDATA[Adrian Gabardo]]></itunes:name></itunes:owner><itunes:author><![CDATA[Adrian Gabardo]]></itunes:author><googleplay:owner><![CDATA[gabardoengineering@substack.com]]></googleplay:owner><googleplay:email><![CDATA[gabardoengineering@substack.com]]></googleplay:email><googleplay:author><![CDATA[Adrian Gabardo]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[Reducing 1.1 years of compute time — every single day]]></title><description><![CDATA[Cutting Lambda costs by $1M/year without changing infrastructure or traffic]]></description><link>https://writing.gabardo.engineering/p/reducing-11-years-of-compute-time</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/reducing-11-years-of-compute-time</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Fri, 22 May 2026 11:03:42 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!uRLt!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F88a27ace-c9e4-4e3c-85b6-077648eba6db_1644x1501.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>At first, leveraging a Lambda fan-out pattern for the sake of parallelisation does not seem inherently bad. But what happens when this pattern is blown out of proportion? What happens when a single Lambda call can spin up to 800 child Lambdas and those nested calls can do the same? </p><p>Imagine the architecture below - very quickly it becomes a time and mone&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/reducing-11-years-of-compute-time">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[From 8 Hours to 20 Minutes: Deploying an MVP to Production]]></title><description><![CDATA[This is an engineering case study from a project I was part of around 2021&#8211;2022.]]></description><link>https://writing.gabardo.engineering/p/from-8-hours-to-20-minutes-deploying</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/from-8-hours-to-20-minutes-deploying</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 28 Apr 2026 07:01:28 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!iT_8!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa6fcbd7f-976e-4524-b763-27e6625e3fd0_1777x738.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>This is an engineering case study from a project I was part of around 2021&#8211;2022. At the time, I was working at a software consultancy and was placed with a large Australian tertiary education solutions provider to help take an existing system from a working MVP to something that could operate reliably in production. The system itself was already functio&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/from-8-hours-to-20-minutes-deploying">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[How a simple S3 design decision turned into a $7M cost]]></title><description><![CDATA[The hidden tax of 1.5 trillion objects and why your lifecycle policies might be a financial time bomb.]]></description><link>https://writing.gabardo.engineering/p/how-a-simple-s3-design-decision-turned</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/how-a-simple-s3-design-decision-turned</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Mon, 20 Apr 2026 07:02:01 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!kbes!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F457be54d-f4c6-40bf-bd5a-b96250eb2e4c_675x675.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>AWS S3 is widely viewed as inexpensive, effectively unbounded object storage. In this case study, that is exactly how it behaved - with the caveat that the data storage decisions our team took cost us close to <strong>40x more</strong> than they should have, and a lifecycle policy decision nearly exploded into a <strong>$7.2 million</strong> bill whilst trying to stop the cost bleed.</p><h2>The&#8230;</h2>
      <p>
          <a href="https://writing.gabardo.engineering/p/how-a-simple-s3-design-decision-turned">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Extending the Flight Search Engine: Time, Cost, and Feasibility constraints]]></title><description><![CDATA[Graph series - part 4]]></description><link>https://writing.gabardo.engineering/p/extending-the-flight-search-engine</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/extending-the-flight-search-engine</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 14 Apr 2026 23:01:53 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!Gqbe!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff20f176d-238b-4677-b129-bb8ba59d0224_1860x1482.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>In the previous article, we built a structural flight search engine capable of traversing an aviation graph and enumerating valid routes between airports. The system was correct &#8212; but incomplete. Pure connectivity ignores the realities that make flight search non-trivial: time, physical distance, cost, and feasibility constraints.</p><p>In this article, we ext&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/extending-the-flight-search-engine">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[The S3 at Scale Runbook]]></title><description><![CDATA[Detecting and fixing cardinality explosions in production buckets]]></description><link>https://writing.gabardo.engineering/p/the-s3-at-scale-runbook</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/the-s3-at-scale-runbook</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 31 Mar 2026 22:01:05 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!1SAq!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Faa7c16ea-9a5d-4472-b65a-e3438df00fa6_4096x2304.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>In the previous article - <a href="https://writing.gabardo.engineering/p/how-a-simple-s3-design-decision-turned">How a simple S3 design decision turned into a $7M cost</a> - we analysed a production system that accumulated <strong>1.56 trillion objects in a single S3 bucket</strong>. The architecture scaled perfectly from a functional perspective &#8212; but nearly triggered a <strong>$7.2M lifecycle transition event</strong>.</p><p>The root cause was not storage volume. It was <strong>object car&#8230;</strong></p>
      <p>
          <a href="https://writing.gabardo.engineering/p/the-s3-at-scale-runbook">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Oncall Nihilism]]></title><description><![CDATA[Why Your Pager is a Design Failure]]></description><link>https://writing.gabardo.engineering/p/oncall-nihilism</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/oncall-nihilism</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 24 Mar 2026 22:01:01 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!RDFq!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc1f5c250-c83e-48d5-8c56-12ea02e3f7f6_3168x1344.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>2:17am. The pager goes off.</p><p>An alarm fires: <em>SQS message delay &gt; 5 minutes</em><strong>.</strong></p><p>A batch job somewhere in the system just spiked the queue from 100k messages per minute to 1 million. Your workers are auto scaling, but it takes 10&#8211;15 minutes to catch up.</p><p>Nothing is broken. The processing rate is exactly what it was five minutes ago&#8212;stable, efficient, and maxed ou&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/oncall-nihilism">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Implementing a flight search engine]]></title><description><![CDATA[Graph traversal with an IDFFS algorithm]]></description><link>https://writing.gabardo.engineering/p/implementing-a-flight-search-engine</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/implementing-a-flight-search-engine</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 17 Mar 2026 22:00:34 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!n6_z!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7c111211-366c-4e16-bb07-6df733bf646b_2144x2189.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The full code for Skymesh is publicly available at <a href="https://github.com/adriangabardo/skymesh">https://github.com/adriangabardo/skymesh</a></p><p>This article&#8217;s code specifically is available at <a href="https://github.com/adriangabardo/skymesh/releases/tag/v3.0.1">https://github.com/adriangabardo/skymesh/releases/tag/v3.0.1</a></p><h2>Overview</h2><p>In previous articles in the series, we described the abstract idea of what we were trying to achieve, then laid the foundations for ingesting aviat&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/implementing-a-flight-search-engine">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Engineering an Aviation Graph: Data Structures and Design Decisions]]></title><description><![CDATA[The Graph Series, part 2]]></description><link>https://writing.gabardo.engineering/p/getting-started-and-ingesting-data</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/getting-started-and-ingesting-data</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 03 Mar 2026 22:01:10 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!WPwl!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F83b3977e-b2e7-40a7-8888-8cd07061c237_1578x547.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The full code for Skymesh is publicly available at <a href="https://github.com/adriangabardo/skymesh">https://github.com/adriangabardo/skymesh</a></p><p>This article&#8217;s code specifically is available at <a href="https://github.com/adriangabardo/skymesh/releases/tag/v2.0.0">https://github.com/adriangabardo/skymesh/releases/tag/v2.0.0</a></p><h2>Overview</h2><p>The first article in The Graph Series framed the aviation industry as a graph problem: airports as nodes, flights as edges, and routing as constrai&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/getting-started-and-ingesting-data">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[The Aviation Industry as a Graph problem]]></title><description><![CDATA[The Graph Series, part 1]]></description><link>https://writing.gabardo.engineering/p/the-aviation-industry-as-a-graph</link><guid isPermaLink="false">https://writing.gabardo.engineering/p/the-aviation-industry-as-a-graph</guid><dc:creator><![CDATA[Adrian Gabardo]]></dc:creator><pubDate>Tue, 17 Feb 2026 10:24:04 GMT</pubDate><enclosure url="https://images.unsplash.com/photo-1545488286-6fe608f23485?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wzMDAzMzh8MHwxfHNlYXJjaHw5fHxhaXJidXN8ZW58MHx8fHwxNzcwNzE5NDk3fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080" length="0" type="image/jpeg"/><content:encoded><![CDATA[<h2>Overview</h2><p>In this article, we introduce a project that models the global aviation industry as a graph-theory problem. Airports are represented as nodes and direct flight routes as edges, forming a large, sparse, and highly non-uniform network.</p><p>The objective of this project is to explore how common aviation questions - such as route reachability, optimal pa&#8230;</p>
      <p>
          <a href="https://writing.gabardo.engineering/p/the-aviation-industry-as-a-graph">
              Read more
          </a>
      </p>
   ]]></content:encoded></item></channel></rss>