<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: segment</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/segment.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2021-12-06T01:41:54+00:00</updated><author><name>Simon Willison</name></author><entry><title>Centrifuge: a reliable system for delivering billions of events per day</title><link href="https://simonwillison.net/2021/Dec/6/centrifue/#atom-tag" rel="alternate"/><published>2021-12-06T01:41:54+00:00</published><updated>2021-12-06T01:41:54+00:00</updated><id>https://simonwillison.net/2021/Dec/6/centrifue/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://segment.com/blog/introducing-centrifuge/"&gt;Centrifuge: a reliable system for delivering billions of events per day&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
From 2018, a write-up from Segment explaining how they solved the problem of delivering webhooks from thousands of different producers to hundreds of potentially unreliable endpoints. They started with Kafka and ended up on a custom system written in Go against RDS MySQL that was specifically tuned to their write-heavy requirements.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://twitter.com/jkakar/status/1467653837917863936"&gt;@jkakar&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/scaling"&gt;scaling&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/webhooks"&gt;webhooks&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/segment"&gt;segment&lt;/a&gt;&lt;/p&gt;



</summary><category term="scaling"/><category term="webhooks"/><category term="segment"/></entry><entry><title>Serving 100µs reads with 100% availability</title><link href="https://simonwillison.net/2020/Jan/10/serving-100s-reads-with-100-availability/#atom-tag" rel="alternate"/><published>2020-01-10T05:15:49+00:00</published><updated>2020-01-10T05:15:49+00:00</updated><id>https://simonwillison.net/2020/Jan/10/serving-100s-reads-with-100-availability/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://segment.com/blog/separating-our-data-and-control-planes-with-ctlstore/"&gt;Serving 100µs reads with 100% availability&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Fascinating use-case for SQLite from Segment: they needed a massively replicated configuration database across all of their instances that process streaming data. They chose to make the configuration available as a ~50GB SQLite database file mirrored to every instance, meaning lookups against that data could complete in microseconds. Changes to the central MySQL configuration store are pulled every 2-3 seconds, resulting in a trade-off of consistency for availability which fits their use-case just fine.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://medium.com/@rbranson/sharing-sqlite-databases-across-containers-is-surprisingly-brilliant-bacb8d753054"&gt;Sharing an SQLite database across containers is surprisingly brilliant&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/scaling"&gt;scaling&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/sqlite"&gt;sqlite&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/segment"&gt;segment&lt;/a&gt;&lt;/p&gt;



</summary><category term="scaling"/><category term="sqlite"/><category term="segment"/></entry></feed>