Replicate's threshold is the number to stare at. The Vertex template opens on three failures inside 60 seconds [12]. Replicate instead gets five inside an hour, because the integration takes roughly one invocation a day and, in the author's words, a one-minute window is statistically unreachable [13]. Run the rate: one call a day is about 0.0007 calls in any given minute [1], and the default wants three failures in that window. Widen to an hour and the expectation is still only about 0.04 calls [2], against a threshold of five.
A breaker on a dependency that quiet cannot open on organic traffic. It opens when something bunches calls together. In a Rails app the usual bunching agent is the retry: a Sidekiq job fails, retries, hammers the dead service, ties up a worker, and the queue backs up behind it [3]. So the threshold on a low-traffic integration is calibrated against retry behaviour and against the provider's rate limit, which the author says produces short failure clusters more often than a real outage does [13]. "The thresholds describe the service, not a global default" [14] is the load-bearing sentence in the write-up.
The four-circuits decision reads the same way. Four services call the same gemini-2.5-flash model, so one shared circuit is the tidier configuration and they genuinely share fate [8]. The design note gives three reasons for splitting them, and the third decides it: a false-positive open on MissingItemDetector returns an empty array, while a false-positive open on OutfitSuggestionService blocks a paywalled flow [11]. Merging the circuits merges the failure counts, and it also sets the group's false-positive cost to that of its most expensive member. The April 23 incident came out of ImageAnalysisJob under load [9], which is precisely the noisy neighbour a shared circuit would have let degrade outfit suggestions and trip planning by contagion [9].
Then the Redis choice, which is the part most likely to bite someone copying this. State has to be visible to web dynos and Sidekiq workers alike, so it lives in Redis, and specifically in db 1 rather than db 0 alongside Rails.cache [15]. Rails.cache.clear and Rack::Attack key churn wipe db 0 wholesale, and losing breaker state during an outage re-arms the breaker mid-incident and lets traffic stampede a service that is already down [16]. The key namespace does not save you: ActiveSupport's :redis_cache_store namespaces keys and does not isolate them [17].
For any of these settings to transfer, the feature needs enough volume that three failures in 60 seconds is reachable, and a provider that recovers on roughly the 30-second reset the template assumes [12]. The same declaration carries jitter: 0.25 [12], and the material does not say how the gem applies it, so treat that one as unverified.
The write-up is titled for having had to patch the gem twice [18], and the available text stops inside the Redis section without naming either patch [18]. The wiring took an afternoon; the week went to everything the DSL does not cover [6][7]. Two things here are reusable even without the patches: keep breaker state out of the database your cache clears, and let each integration's call rate set its own window.
