<?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>Crdts on Brave New Geek</title><link>https://bravenewgeek.com/tag/crdts/</link><description>Recent content in Crdts on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 04 Apr 2017 09:28:08 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/crdts/index.xml" rel="self" type="application/rss+xml"/><item><title>You Cannot Have Exactly-Once Delivery</title><link>https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/</link><pubDate>Wed, 25 Mar 2015 18:14:57 -0500</pubDate><guid>https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/</guid><description>&lt;p&gt;I’m often surprised that people continually have fundamental misconceptions about how distributed systems behave. I myself shared many of these misconceptions, so I try not to demean or dismiss but rather educate and enlighten, hopefully while sounding less preachy than that just did. I continue to learn only by following in the footsteps of others. In retrospect, it shouldn’t be surprising that folks buy into these fallacies as I once did, but it can be frustrating when trying to communicate certain design decisions and constraints.&lt;/p&gt;</description></item><item><title>From Mainframe to Microservice: An Introduction to Distributed Systems</title><link>https://bravenewgeek.com/from-mainframe-to-microservice-an-introduction-to-distributed-systems/</link><pubDate>Sat, 01 Nov 2014 18:12:38 -0600</pubDate><guid>https://bravenewgeek.com/from-mainframe-to-microservice-an-introduction-to-distributed-systems/</guid><description>&lt;p&gt;I gave a talk at &lt;a href="http://iowacodecamp.com/"&gt;Iowa Code Camp&lt;/a&gt; this weekend on distributed systems. It was primarily an introduction to them, so it explored some core concepts at a high level.  We looked at why distributed systems are difficult to build (right), the CAP theorem, consensus, scaling shared data and CRDTs.&lt;/p&gt;
&lt;p&gt;There was some interest in making the slides available online. I’m not sure how useful they are without narration, but here they are anyway for posterity.&lt;/p&gt;</description></item><item><title>Scaling Shared Data in Distributed Systems</title><link>https://bravenewgeek.com/scaling-shared-data/</link><pubDate>Tue, 21 Oct 2014 21:23:03 -0600</pubDate><guid>https://bravenewgeek.com/scaling-shared-data/</guid><description>&lt;p&gt;Sharing mutable data at large scale is an &lt;em&gt;exceedingly&lt;/em&gt; difficult problem. In their seminal paper &lt;a href="http://pagesperso-systeme.lip6.fr/Marc.Shapiro/papers/RR-6956.pdf"&gt;&lt;em&gt;CRDTs: Consistency without concurrency control&lt;/em&gt;&lt;/a&gt;, Shapiro et al. describe why the CAP theorem demands a give and take between scalability and consistency. In general, CAP requires us to choose between CP and AP. The former requires serializing every write, which doesn’t scale beyond a small cluster. The latter ensures scalability by giving up consistency.&lt;/p&gt;
&lt;h3 id="sharing-data-in-centralized-systems"&gt;Sharing Data in Centralized Systems&lt;/h3&gt;
&lt;p&gt;We tend to prefer weaker consistency models because they mean lower latency and higher availability. To highlight this point, consider the fact that the memory models for most programming languages are &lt;em&gt;not&lt;/em&gt; serializable by default. More concisely, programs with shared memory are not inherently thread-safe. This is a conscious design decision because enforcing memory serializability incurs a significant latency penalty. Instead, programming languages require explicit &lt;em&gt;memory barriers&lt;/em&gt; which can be used around the critical sections which need this property.&lt;/p&gt;</description></item></channel></rss>