Live data from Hacker News

Viewing profile — rodrigorcs

rodrigorcs

HN member
Joined
Wed, Oct 08, 2025, 1:27 PM UTC
HN karma
16
Public activity
17 items

About rodrigorcs

Wanna chat? Just reach out at rodrigo@openfuse.io :)

[ my public key: https://keybase.io/rodrigorcs; my proof: https://keybase.io/rodrigorcs/sigs/E0Osn3CPc_UcH8rihuIT16oCa3G6I43pKEpXluULm1w ]

Recent public activity

  1. comment
    Comment #48125365

    [flagged]

  2. story
  3. comment
    Comment #47100455

    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 deci…

  4. comment
    Comment #47077129

    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…

  5. comment
    Comment #47076312

    > 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 …

  6. comment
  7. comment
    Comment #47074225

    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 central…

  8. comment
    Comment #47072675

    Great question. Openfuse has a "systems" concept for exactly this. Each system is an isolated unit within an environment with its own breaker state. So you'd have us-east/stripe an…

  9. comment
    Comment #47071209

    Feel free to take a look at the SDK code if you want to, it's open :) https://github.com/openfuseio/openfuse-sdk-node

  10. comment
    Comment #47071203

    It makes the awareness global so instances stop independently hammering a service that the rest of the fleet already knows is down. You can always override manually too and it will…

  11. comment
    Comment #47071185

    Yup, that is true for both Cloud and Self-hosted, it never blocks any executions by any external factors other than the breaker is KNOWN as open. The state sync and the hot path ar…

  12. comment
    Comment #47071172

    Good question, that's exactly why the trip decision isn't based on a single instance seeing a few errors. Openfuse aggregates failure metrics across the fleet before making a decis…

  13. comment
    Comment #47071147

    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 loggi…

  14. comment
    Comment #47071129

    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…

  15. story
    Show HN: I built a fuse box for microservices

    Hey HN! I'm Rodrigo, I run distributed systems across a few countries. I built Openfuse because of something that kept bugging me about how we all do circuit breakers. If you're ru…

  16. comment
    Comment #46967933

    Really interesting idea! I've only seen stuff like that in ETL pipelines (which are a pain). This sits somehow between a python notebook and a ETL pipeline. By the way, I just shar…

  17. comment
    Comment #46960108

    I've been building Openfuse ( https://openfuse.io ), a centralized circuit breaker platform. Started building it about a year ago after dealing with the same problem across multipl…