axelson
Scenic Core Team
6) Lonestar ElixirConf 2018 - Consistent, Distributed Elixir - Chris Keathley
Consistent, Distributed Elixir - @keathley
Elixir and Erlang provide powerful mechanisms for building systems that are always available. But when it comes to building distributed systems that need consistency Erlang leaves many of the implementation details up to the programmer.
In this talk we’ll discuss the trade offs between systems that are always on and systems that are consistent. We’ll look at the types of guarantees that standard Erlang tooling gives us as well as their shortcomings. Finally we’ll look at several patterns and techniques for building consistent, distributed systems using elixir.
Audience: Intermediate, Advanced
Trending in Talks
Mise en Place for Ecto: Organizing Domain Complexity w/Business Rules-Nicholas Henry|ElixirConf 2025
Comments welcome! Vi...
New
Leaving a BEAM cluster (basically) unattended for 2 years - Yuri Oliveira | ElixirConf US 2025
Comments welcome! View the...
New
From Notebook to Production: Evolution of Elixir Projects - Emmanuel Pinault | ElixirConf US 2025
Comments welcome! View...
New
You can build an AI agent - Dennis Beatty | ElixirConf US 2025
Comments welcome! View the <span class="hashtag-icon-place...
New
Test-Driven Elixir: Fast Track to Senior Engineer – Britton Broderick | ElixirConf US 2025
Comments welcome! View the <sp...
New
Engineering Network Protocol Clients - Carlos Souza | ElixirConf US 2025
Comments welcome! View the <span class="hashtag-...
New
Elixir’s Configuration Layers: A Visual Journey - Stephanie Lane | ElixirConf US 2025
Comments welcome! View the <span cl...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
I just stumbled on a newly redesigned elixir-lang.org. :tada: It looks like @Software_Mansion did the work, and I think it is generally a...
New
@hugobarauna and I (Alex Koutmos) have been hard at work on writing a book on Nerves that takes you from simply blinking LEDs to building...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First 5 of 5 Posts
idi527
@keathley

Have you looked into other raft implementations on beam, like rabbitmq/ra or maybe dreyk/zraft_lib? What are the main differences of
:raftfrom those other implementations?andre1sk
@keathley very good talk!!! and amazing work this will enable a lot of cool apps in Elixir ecosystem once ready for prod use.
keathley
Thanks! We’re getting closer to production readiness so hopefully it’ll be useful soon.
andre1sk
I actually think the work you are doing will be the enabler of killer apps for Elixir ecosystem especially in data processing pipelines. Among other things it will enable a Elixir native kafka like system that can expose a GenStage producer with no external dependencies on ZK. That would make Elixir the killer platform for data processing pipelines.
keathley
Even after all of my searching I hadn’t seen zraft so I’ll have to look into it more. One of the design characteristics that I wanted was a backend that used an established database engine instead of handling files directly. Thats why our implementation uses rocksdb (although since its pluggable you could really use whatever you want). Based on a quick glance at zraft it looks like its managing the log file directly. That doesn’t mean that its a poor implementation by any means. Just something I noticed and probably would have been a deal breaker for my uses. Hard to say though so I’ll have to dig in more.
Ra seems great but its under heavy development and is a sufficient departure from the original raft algorithm in regards to its failure detection that I felt better about building a solution that was a little closer to the original specification. Ra has made a bunch of tradeoffs that make total sense for its use in rabbitmq. Those are reasonable tradeoffs for them but aren’t tradeoffs that I need.