Show HN: I built a fuse box for microservices • Hacker News Board

Re: Show HN: I built a fuse box for microservices

#21

Post by rodrigorcs » Thu, Feb 19, 2026, 5:20 PM UTC

nzach wrote: post #20

rodrigorcs wrote: post #17

Earlier quoted context omitted.

You're right, for intra-cluster calls where failures are scoped between the node itself and the infra around it, per-instance breakers are what you want. I wouldn't suggest centralizing those, and I might be wrong, but in most of these scenarios there is no fallback anyways (maybe except Redis?) Openfuse is aimed at the other case: shared external dependencies where 15 services all call the same dependency and each o…

> where 15 services all call the same dependency and each one is independently discovering the same outage at different times I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. This solution will save a few hundred requests, but I don't think this really matters. If this is a pain point its easier to adjust the circuit-breaker se…

> I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter.

Each service discovering by their own is not really the main problem to be solved with my proposal, the thing is that by doing it locally, we lack observability and there is no way to act on them.

> what we done is to create flag where we put the % value we want to bring back

Oh I see, well that is indeed a good problem to solve. Openfuse does not do that gradual recovery but it would be possible to add.

Do you think that by having that feature and having the Openfuse solution self-hosted, it would be something you would give a try? Not trying to sell you anything, just gathering feedback so I can learn from the discussion.

By the way, if you don't mind, how often do you have to run that type of recovery?

Re: Show HN: I built a fuse box for microservices

#22

Post by rodrigorcs » Thu, Feb 19, 2026, 6:24 PM UTC

cluckindan wrote: post #19

rodrigorcs wrote: post #9

Earlier quoted context omitted.

Totally possible, and some teams do. You need a state store, a evaluator job, a propagation layer to push state changes to every instance, a SDK, a dashboard, alerting, audit logging, RBAC, and a fallback strategy for when the coordination layer itself goes down. It's not complex individually, but it takes time, and it's the ongoing maintenance that gets you. Openfuse is a bet that most teams would rather pay $99/mo…

That’s good. The ”open” in the name kind of implies a ”self-hosting first” approach.

I know this sounds weird, but it is in fact self-hosting first :)

The reason why I only launched the cloud version of it is just so I could have a faster iteration pace in the back-end after having people actually using it reliably.

Now it is pretty solid and self hosting is the next thing to go out.

If you check the SDK code, it is ready for self hosting.

Re: Show HN: I built a fuse box for microservices

#23

Post by nzach » Thu, Feb 19, 2026, 6:34 PM UTC

rodrigorcs wrote: post #21

nzach wrote: post #20

Earlier quoted context omitted.

> where 15 services all call the same dependency and each one is independently discovering the same outage at different times I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. This solution will save a few hundred requests, but I don't think this really matters. If this is a pain point its easier to adjust the circuit-breaker se…

> I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. Each service discovering by their own is not really the main problem to be solved with my proposal, the thing is that by doing it locally, we lack observability and there is no way to act on them. > what we done is to create flag where we put the % value we want to bring back O…

> Do you think that by having that feature and having the Openfuse solution self-hosted, it would be something you would give a try?

No, I don't think this is compelling enough to try it at work.

> By the way, if you don't mind, how often do you have to run that type of recovery?

I would say we use this feature once every 3 months.

Re: Show HN: I built a fuse box for microservices

#24

Post by netik » Thu, Feb 19, 2026, 7:45 PM UTC

rodrigorcs wrote: post #8

netik wrote: post #4

This a great idea, but it's a great idea when on-prem. During some thread, some where, there's going to be a roundtrip time between my servers and yours, and once I am at a scale where this sort of thing matters, I'm going to want this on-prem. What's the difference between this and checking against a local cache before firing the request and marking the service down in said local cache so my other systems can see it…

I agree with more of this than you might expect. On-prem: You're right, and it's on the roadmap. For teams at the scale you're describing, a hosted control plane doesn't make sense. The architecture is designed to be deployable as a self-hosted service, the SDK doesn't care where the control plane lives, just that it can reach it (you can swap the OpenfuseCloud class with just the Openfuse one, using your own URL). R…

Caveat: I was employee 13 at Twitter and I spent a long time dealing with random failure modes.

At extremely high scale you start to run into very strange problems. We used to say that all of your "Unix Friends" fail at scale and act differently.

I once had 3000 machines running NTP sync'd cronjobs on the exact same second pounding the upstream server and causing outages (Whoops, add random offsets to cron!)

This sort of "dogpile effect" exists when fetching keys as well. A key drops out of cache and 30 machines (or worker threads) trying to load the same key at the same time, because the cache is empty.

One of the solutions around this problem was Facebook's Dataloader (https://github.com/graphql/dataloader), which tries to intercept the request pipeline, batch the requests together and coalesce many requests into one.

Essentially DataLoader will coalesce all individual loads which occur within a single frame of execution (a single tick of the event loop) and then call your batch function with all requested keys.

It helps by reducing requests and offering something resembling backpressure by moving the request into one code path.

I would expect that you'd have the same sort of problem at scale with this system given the number of requests on many procs across many machines.

We had a lot of small tricks like this (they add up!), in some cases we'd insert a message queue inbetween the requestor and the service so that we could increase latency / reduce request rate while systems were degraded. Those "knobs" were generally implemented by "Decider" code which read keys from memcache to figure out what to do.

By "pushes to connected SDKs": I assume you're holding a thread with this connection; How do you reconcile this when you're running something like node with PM2 where you've got 30-60 processes on a single host? They won't be sharing memory, so that's a lot of updates.

It seems better to have these updates pushed to one local process that other processes can read from via socket or shared memory.

I'd also consider the many failure modes of services. Sometimes services go catatonic upon connect and don't respond, sometimes they time out, sometimes they throw exceptions, etc...

There's a lot to think about here but as I said what you've got is a great start.

Re: Show HN: I built a fuse box for microservices

#25

Post by rodrigorcs » Sat, Feb 21, 2026, 1:04 PM UTC

netik wrote: post #24

rodrigorcs wrote: post #8

Earlier quoted context omitted.

I agree with more of this than you might expect. On-prem: You're right, and it's on the roadmap. For teams at the scale you're describing, a hosted control plane doesn't make sense. The architecture is designed to be deployable as a self-hosted service, the SDK doesn't care where the control plane lives, just that it can reach it (you can swap the OpenfuseCloud class with just the Openfuse one, using your own URL). R…

Caveat: I was employee 13 at Twitter and I spent a long time dealing with random failure modes. At extremely high scale you start to run into very strange problems. We used to say that all of your "Unix Friends" fail at scale and act differently. I once had 3000 machines running NTP sync'd cronjobs on the exact same second pounding the upstream server and causing outages (Whoops, add random offsets to cron!) This sor…

This is incredibly generous context... thank you. A few of these hit close to problems I'm thinking about.

The Decider pattern you're describing (reading keys from memcache to decide behavior at runtime) is essentially what Openfuse is trying to productize. A centralized place that tells your fleet how to behave, without each process figuring it out independently. So it's validating to hear that's where Twitter landed organically.

On the PM2 point: you're right, holding a connection per process doesn't scale well at that huge scale. A local sidecar that receives state updates and exposes them via socket or shared memory to sibling processes is a much better model at that density. That's not how it works today, each process holds its own connection, but your framing is exactly how I'd want to evolve it. However, I can't say that is in the short-term goals for now, need to validate the product first and add some important features + publish the self hosted version.

On the dogpile: the half-open state is where this matters most. When a breaker opens and then transitions to half-open, you don't want 50 instances all sending probe requests simultaneously. The coalescing pattern you're describing from DataLoader is a neat way of solving it, I wonder if I can implement this somehow without adding a service/proxy closer to the clients just for that.

On failure modes: agreed, "service is down" is the simplest case. Catatonic connections, slow degradation, partial responses that look valid but aren't, those are harder to classify. Right now Openfuse trips on error rates, timeouts, and latency. However, the back-end is ready for custom metrics, I just didn't implement them yet. Having the breaker tripping based on OpenTelemetry metrics is also something I am looking forward to try, which opens a whole new world.

I'm not going to pretend this is built for Twitter-scale problems today. But hearing that the patterns you arrived at are directionally where this is headed is really encouraging.