3 ms·
The only way a health endpoint is not mocking anything is when it does a large variety of full valid requests, having the same complexity and functionality of t
by dtech 7y ago
The only way a health endpoint is not mocking anything is when it does a large variety of full valid requests, having the same complexity and functionality of the service. Oh and all of them should fail or succeed identically. At that point why not use the real request.
Or you're overshooting. Say you have a service with 2 endpoints, both depend on the DB and 1 depends on an external API. External API goes down, you don't have a correct choice if you have 1 health endpoint for circuit breakers. If you open the breaker you needlessly disable requests to the healthy endpoint. If you leave it closed your circuit breaker is not working for the broken endpoint.
You can of course use a health check in addition to the normal endpoint in your circuit breaker, but then its just a fail-faster for the scenarios that the health endpoint covers.
- derefr 7y ago> You can of course use a health check in addition to the normal endpoint in your circuit breaker, but then its just a fail-faster for the scenarios that the health endpoint covers. Er, yes, that was the thing I was trying to suggest. You want to fail fast (or, more precisely, keep the system in the "circuit open, degraded functionality code-path" state) so your users don't experience mysterious latency spikes when their request becomes the guinea-pig for the circuit-breaker. That'll still happen, but not as often if a health check can tell the service there's not even a chance the service is worth checking via user-request.