3 ms·

you don't mock it, you implement a real one that acts as a remote microservice. Sometimes it's a /health route on the same site, sometimes it's a status.example

you don't mock it, you implement a real one that acts as a remote microservice. Sometimes it's a /health route on the same site, sometimes it's a status.example.com, etc. The only thing it should do is give you a static errors-or-not file that gets regenerated at some reasonable interval by an independently running process, off of all known dependencies that you control. If the health route says everything's up and running, then you can try a normal request, and if that fails, you back off anew (and you log an error entry that can be used to update the health endpoint's data generator, because something, somewhere, is misreporting)

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.

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.