HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jlouis
fuse
Erlang2014–2024
jlouis / fuse

fuse

A Circuit Breaker for Erlang

Hardware & Embedded
Explore on GitHubRead Hacker News discussions
4Distinct people
11Mentions
0Explicit recommenders
512GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Circuit Breaker for Erlang

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2014-08-20 12:31:25 UTC to 2024-02-08 15:06:55 UTC.

01232014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

11 sources
davidw·Feb 8, 2024
Indeed. I do wish there were a few more "extras" in OTP, because "let it crash" needs some more details in some circumstances. For instance if you have a system with a user interface and some various components, like say, a database, and the database becomes unavailable, you don't want the entire system to crash. You want it to display an error message to the user and maybe go into some kind of diagnostic mode or other "things are not normal" state. Something like https://github.com/jlouis/fuse is one approach. I had a small stab at creating something similar: https://github.com/davidw/hardcore
In When "letting it crash" is not enough
davidw·May 16, 2023
This is the kind of thing I'm talking about though... we go from "Erlang is a piece of cake for distributed systems" to some pretty advanced concepts and telling people to "roll your own" for an extremely common use case: not wanting your entire application to be taken down by an unreachable external service. Back in the day, I found this to be a pretty good 'circuit breaker' type of thing: https://github.com/jlouis/fuse I wrote something similar for the (OTP) application level: https://github.com/davidw/hardcore
In Erlang/OTP 26 Highlights
davidw·Aug 18, 2017
> I mean I've got lots of books on OTP. But if i'm building a daemon which reads off a queue and talks to some databases - where are some patterns I can follow? This is a fair point, even in Erlang land. There are a zillion things encouraging you to "let it crash" and far fewer going beyond that. One thing that doesn't get mentioned often enough is a circuit-breaker like fuse: https://github.com/jlouis/fuse This also has some more advanced topics: https://www.erlang-in-anger.com/
In Why Elixir (2014)
jlouis·Jul 23, 2016
Disclaimer: I'm the author of fuse. Circuit Breakers provide three things not provided by your above scheme: First, there is a configurable policy on how many errors to tolerate before breaking. This policy is not baked into your code, but lives outside, often in configuration files. Some of the work that is currently going on is the support for more advanced policies and more advanced ways of ramping up connectivity again on the flip side. Second, there is no resource buildup. In your example, every request to iTunes will wait and use resources while it is waiting. Once the circuit breaks, you immediately respond with an error. In a system with 10k req/s the buildup is pretty serious if you have a timeout of 5 seconds, say, since it will effectively be 50k reqs waiting. Which could be 50k network sockets. Third, fuse has a monitoring sys
Read the rest
tem built in. Any fuse you create will post its current state to an event manager which can be used to build monitoring applications (essentially this is a low-volume pub/sub pattern). Rolling your own, you have to provide this monitoring yourself, but using fuse, you get a nice way to plug into the fabric. This is used by Riak's Search system yokuzuna for instance. Finally, what makes fuse special from the other circuit breakers is that it has a full QuickCheck specification. I.e., we have a pseudo-formal account of fuse working as intended according to the specification. In particular, I tend to generate random fuse scenarios for a couple of hours before releasing new versions. This amounts to a couple million random test cases, and we approach a full model-check of the code as we spend more time generating test cases. There are some novel work in there with respect to handling randomness and time in test cases via Erlang's QuickCheck's excellent mocking system. As a result, there have been few bug reports and likewise few fatal errors reported. (Edit: for completeness, all the code of fuse is online here: https://github.com/jlouis/fuse including documentation)
In Circuit Breakers in Elixir
MartinMond·Jun 26, 2015
A simple approach: Set up your apps' supervision tree such that you got poolboy [1] with a fixed pool of 20 worker processes and the one GenServer that distributes the work. If you go with one GenServer per node, then that one just connects to redis and just pulls jobs (using BLPOP or whatever). When it has gotten a job it checks out a worker from poolboy and assigns it that work. You could also just have every single worker process go directly to redis and have it pull jobs in a loop. But where's the fun in that ;) If you want a single global coordinator instead of one per node you can use :global [2] to globally register a process in the cluster. This process is then cluster-wide reachable under its registered name. It can talk to each of your worker pools in the cluster and round-robin try to check out workers and assign them work. And
Read the rest
if you do this you might as well ask yourself if you really need redis instead of keeping it all within your Elixir system. Deciding on which node this process lives is still up to you, but there are libraries like locks [3] that allow you to automatically determine a leader in your cluster. And once this is done you can start dealing with overload :) Of course this is just a simple and naive approach, there are a lot of really useful Erlang libraries to check out. Here's a list of libs that helped me when getting started by reading their docs and sources in no particular order: https://github.com/heroku/canal_lock - Erlang lock manager for concurrently variable resource numbers https://github.com/jlouis/safetyvalve - queueing facilities for tasks to be executed so their concurrency and rate can be limited on a running system https://github.com/fishcakez/sbroker - process broker for matchmaking between two groups of processes using sojourn time based active queue management to prevent congestion. https://github.com/ferd/backoff - exponential backoffs and timers to be used within OTP processes when dealing with cyclical events, such as reconnections, or generally retrying things https://github.com/jlouis/fuse - A Circuit Breaker for Erlang https://github.com/basho/sidejob - Parallel worker and capacity limiting library for Erlang https://github.com/pspdfkit-labs/sidetask - My humble Elixir wrapper for basho's sidejob [1] https://github.com/devinus/poolboy also used in Ecto, look through the Ecto sources if you want to see how it's used in Elixir. [2] http://erlang.org/doc/man/global.html [3] https://github.com/uwiger/locks and then https://github.com/uwiger/locks/blob/master/doc/locks_leader...
In The Little Schemer Exercises in Elixir

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.