<?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>Distributed-Systems on Bits, Trades &amp; Systems</title>
    <link>https://blog.turboawesome.win/tags/distributed-systems/</link>
    <description>Recent content in Distributed-Systems on Bits, Trades &amp; Systems</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 16 Apr 2025 13:12:00 +0000</lastBuildDate>
    <atom:link href="https://blog.turboawesome.win/tags/distributed-systems/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Distributed Consistency Models: What Your Service Actually Guarantees</title>
      <link>https://blog.turboawesome.win/2025/04/distributed-consistency-models-what-your-service-actually-guarantees/</link>
      <pubDate>Wed, 16 Apr 2025 13:12:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2025/04/distributed-consistency-models-what-your-service-actually-guarantees/</guid>
      <description>Linearisability, serializability, eventual consistency, causal consistency — these terms are used loosely and understood imprecisely. Knowing what your data store actually guarantees determines whether your distributed system is correct.</description>
    </item>
    <item>
      <title>Observability at Scale: What &#39;Good&#39; Looks Like When You Have Too Much Data</title>
      <link>https://blog.turboawesome.win/2024/05/observability-at-scale-what-good-looks-like-when-you-have-too-much-data/</link>
      <pubDate>Wed, 29 May 2024 09:47:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2024/05/observability-at-scale-what-good-looks-like-when-you-have-too-much-data/</guid>
      <description>Observability problems at large scale are different from small-scale ones. Too little signal is replaced by too much signal, and the engineering challenge inverts.</description>
    </item>
    <item>
      <title>Cache Design as a Reliability Practice, Not an Optimisation</title>
      <link>https://blog.turboawesome.win/2024/03/cache-design-as-a-reliability-practice-not-an-optimisation/</link>
      <pubDate>Wed, 27 Mar 2024 11:47:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2024/03/cache-design-as-a-reliability-practice-not-an-optimisation/</guid>
      <description>Most engineers add caches to make things faster. At scale, the more important reason to design caches carefully is reliability — a cache failure should not cascade into a system failure. The patterns that prevent that are different from the patterns that optimise for speed.</description>
    </item>
    <item>
      <title>Engineering at Enterprise Scale: What Changes When the System Is Actually Big</title>
      <link>https://blog.turboawesome.win/2024/02/engineering-at-enterprise-scale-what-changes-when-the-system-is-actually-big/</link>
      <pubDate>Wed, 14 Feb 2024 10:22:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2024/02/engineering-at-enterprise-scale-what-changes-when-the-system-is-actually-big/</guid>
      <description>After a decade in financial technology — trading firms, institutions, a startup, a European fintech — joining a large US technology company. The technical and organisational delta.</description>
    </item>
    <item>
      <title>OpenTelemetry in Go: Distributed Tracing That Doesn&#39;t Get in the Way</title>
      <link>https://blog.turboawesome.win/2022/05/opentelemetry-in-go-distributed-tracing-that-doesnt-get-in-the-way/</link>
      <pubDate>Tue, 31 May 2022 10:14:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2022/05/opentelemetry-in-go-distributed-tracing-that-doesnt-get-in-the-way/</guid>
      <description>OpenTelemetry standardised distributed tracing across languages and vendors. Here&amp;#39;s what idiomatic OTel integration looks like in Go — and the parts that aren&amp;#39;t obvious from the documentation.</description>
    </item>
    <item>
      <title>gRPC in Production: Lessons After Two Years</title>
      <link>https://blog.turboawesome.win/2021/01/grpc-in-production-lessons-after-two-years/</link>
      <pubDate>Wed, 13 Jan 2021 14:55:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2021/01/grpc-in-production-lessons-after-two-years/</guid>
      <description>gRPC is a better default than REST for internal service communication. It&amp;#39;s also a set of new problems you didn&amp;#39;t have before. Two years of production experience.</description>
    </item>
    <item>
      <title>Context Propagation in Go: Deadlines, Cancellation, and Tracing</title>
      <link>https://blog.turboawesome.win/2020/02/context-propagation-in-go-deadlines-cancellation-and-tracing/</link>
      <pubDate>Wed, 19 Feb 2020 11:14:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2020/02/context-propagation-in-go-deadlines-cancellation-and-tracing/</guid>
      <description>Go&amp;#39;s context package is one of the most important idioms in the language. Used well it enables clean cancellation and distributed tracing. Used poorly it becomes a magic bag of values that creates invisible dependencies.</description>
    </item>
    <item>
      <title>Schema Evolution in Avro: The Hard Lessons from Production</title>
      <link>https://blog.turboawesome.win/2018/10/schema-evolution-in-avro-the-hard-lessons-from-production/</link>
      <pubDate>Thu, 04 Oct 2018 11:29:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2018/10/schema-evolution-in-avro-the-hard-lessons-from-production/</guid>
      <description>Avro&amp;#39;s schema evolution rules sound simple. In production with multiple services and a regulated data retention requirement, the edges are sharp. Here are the cases that burned us and the practices that prevented future ones.</description>
    </item>
    <item>
      <title>Event Sourcing in Financial Systems: Real Benefits, Real Costs</title>
      <link>https://blog.turboawesome.win/2018/07/event-sourcing-in-financial-systems-real-benefits-real-costs/</link>
      <pubDate>Wed, 11 Jul 2018 11:03:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2018/07/event-sourcing-in-financial-systems-real-benefits-real-costs/</guid>
      <description>Event sourcing is a natural fit for financial systems that require audit trails and point-in-time reconstruction. The costs are real too — projections, eventual consistency, and the event schema evolution problem.</description>
    </item>
    <item>
      <title>Backpressure in Practice: Keeping Fast Producers from Killing Slow Consumers</title>
      <link>https://blog.turboawesome.win/2018/06/backpressure-in-practice-keeping-fast-producers-from-killing-slow-consumers/</link>
      <pubDate>Thu, 14 Jun 2018 10:33:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2018/06/backpressure-in-practice-keeping-fast-producers-from-killing-slow-consumers/</guid>
      <description>Every system has components that produce faster than consumers can handle under some conditions. Backpressure is the mechanism by which fast producers are slowed rather than dropping data or consuming unbounded memory. Here&amp;#39;s what the options look like in practice.</description>
    </item>
    <item>
      <title>Distributed Transactions Are a Lie (And What to Do Instead)</title>
      <link>https://blog.turboawesome.win/2018/01/distributed-transactions-are-a-lie-and-what-to-do-instead/</link>
      <pubDate>Wed, 17 Jan 2018 10:55:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2018/01/distributed-transactions-are-a-lie-and-what-to-do-instead/</guid>
      <description>Two-phase commit promises ACID semantics across distributed systems. In practice it&amp;#39;s slow, fragile, and blocks under failure. The patterns that actually work — sagas, idempotency, and compensating transactions — are more complex but more reliable.</description>
    </item>
    <item>
      <title>Building MiFID II Trade Reporting Infrastructure: An Engineer&#39;s View</title>
      <link>https://blog.turboawesome.win/2017/10/building-mifid-ii-trade-reporting-infrastructure-an-engineers-view/</link>
      <pubDate>Tue, 03 Oct 2017 11:45:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2017/10/building-mifid-ii-trade-reporting-infrastructure-an-engineers-view/</guid>
      <description>MiFID II required every trade to be reported within 15 minutes of execution. Building the infrastructure to meet that requirement across a large, heterogeneous estate taught us about the gap between regulatory requirements and production reality.</description>
    </item>
    <item>
      <title>Kafka in Finance: What &#39;Exactly Once&#39; Actually Costs You</title>
      <link>https://blog.turboawesome.win/2017/01/kafka-in-finance-what-exactly-once-actually-costs-you/</link>
      <pubDate>Tue, 10 Jan 2017 11:22:00 +0000</pubDate>
      <guid>https://blog.turboawesome.win/2017/01/kafka-in-finance-what-exactly-once-actually-costs-you/</guid>
      <description>Kafka&amp;#39;s exactly-once semantics arrived in 0.11 with significant caveats. Using it in a regulated financial context forced a clear-eyed view of what the guarantee actually covers and what it doesn&amp;#39;t.</description>
    </item>
  </channel>
</rss>
