Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

I built a fuse box for microservices

Details

External ID
47061013
Source
HN
Company
—
Product
I built a fuse box for microservices
Website domain
openfuse.io
Launched
Feb. 18, 2026
Cohort
—
Upvotes
28
Upvotes percentile
0.7371967654986523
Tags
—
Fetched at
Sept. 7, 2026, 9:25 p.m.
Updated at
Sept. 7, 2026, 9:25 p.m.

Description

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 running 20 instances of a service and Stripe starts returning 500s, each instance discovers that independently. Instance 1 trips its breaker after 5 failures. Instance 14 just got recycled and hasn't seen any yet. Instance 7 is in half-open, probing a service you already know is dead. For some window of time, part of your fleet is protecting itself and part of it is still hammering a dead dependency and timing out, and all you can do is watch.Libraries can't fix this. Opossum, Resilience4j, Polly are great at the pattern, but they make per-instance decisions with per-instance state. Your circuit breakers don't talk to each other.Openfuse is a centralized control plane. It aggregates failure metrics from every instance in your fleet and makes the trip decision based on the full picture. When the breaker opens, every instance knows at the same time.It's a few lines of code: const result = await openfuse.breaker('stripe').protect( () => chargeCustomer(payload) ); The SDK is open source, anyone can see exactly what runs inside their services.The other thing I couldn't let go of: when you get paged at 3am, you shouldn't have to find logs across 15 services to figure out what's broken. Openfuse gives you one dashboard showing every breaker state across your fleet: what's healthy, what's degraded, what tripped and when. And, you shouldn't need a deploy to act. You can open a breaker from the dashboard and every instance stops calling that dependency immediately. Planned maintenance window at 3am? Open beforehand. Fix confirmed? Close it instantly. Thresholds need adjusting? Change them in the dashboard, takes effect across your fleet in seconds. No PRs, no CI, no config files.It has a decent free tier for trying it out, then $99/mo for most teams, $399/mo with higher throughput and some enterprise features. Solo founder, early stage, being upfront.Would love to hear from people who've fought cascading failures in production. What am I missing?

Enrichment

Theme
AI agent frameworks and developer tools
Vertical
Horizontal
Function
Data infrastructure
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
microservice orchestration tool
Manually corrected
False

Could you build this?

Partial While basic circuit breaker logic is simple, synchronizing state in real time across distributed microservice instances without adding latency requires distributed systems expertise.

What it would actually take: The architecture requires client-side interceptor libraries (middleware in Go, Node, or Java) communicating with a low-latency shared state store or gossip/Raft coordination daemon. The hard problem is sharing failure metrics across dozens of distributed nodes within milliseconds while preventing the coordination plane itself from adding latency or becoming a single point of failure. This demands distributed consensus engineering, resilient network protocols, and sub-millisecond serialization performance.

Discussion

20 comments analyzed.

Competitors mentioned: Feature flag providers (for manual recovery/fallback), In-house circuit breaker solutions, DataLoader (for request coalescing/deduplication)

Concerns raised: Global circuit breaker state causes problems with partial failures across regions/datacenters, Adds complexity vs just adjusting local circuit breaker settings, Network latency of coordination layer in hot path, Risk of false positives affecting all instances when one sees errors, Self-hosted version not yet available

Feature requests: Gradual recovery with percentage-based traffic restoration, Custom metrics support beyond error rates/timeouts/latency, OpenTelemetry metrics integration for trip decisions, Local sidecar model for high-density deployments (PM2 multiple processes), Request coalescing/dogpile prevention for half-open probes

Competitors

Other products that read as similar to this one — 55 launches clear the similarity bar, closest 8 shown.

Attention rank: #22 of 56 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 106 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a data infrastructure tool for Media & entertainment yet.