Functional options (dave cheany); bind to viper. Options titled WithFoo.
Systemd service (?)
Docker container
Reliability
Fallback strategies
When creating a service it is important that we express not only when we are healthy, but also when we are not healthy. That allows users to proactively switch their own services into a failure handling service.
This includes things like:
retry strategies; transaction ID (for example), timeouts, circuit breakers etc.
SLOs
Need to specify the applications health in some way.
It might be reasonable to :
Specify this in protobuf as a metric that can be checked (even if in binary y/n). This is problematic if downstreams can reverse this for internal business data
Specify this in protobuf even if just to render it to a doc. Or yaml, or whatever. Maybe "proposed SLOs" that can be returned by an API.
Specify this in doc
Advisory fallback behaviour
Given an API endpoint it should be reasonable that we document what to do when that endpoint is unavailable. For example, buffering requests, retrying and so fourth.
Maybe all this goes in a FAILURE.md doc? or RELIABILITY.md? Hmm.
WithFoo
.Reliability
Fallback strategies
When creating a service it is important that we express not only when we are healthy, but also when we are not healthy. That allows users to proactively switch their own services into a failure handling service.
This includes things like:
SLOs
Need to specify the applications health in some way.
It might be reasonable to :
Advisory fallback behaviour
Given an API endpoint it should be reasonable that we document what to do when that endpoint is unavailable. For example, buffering requests, retrying and so fourth.
Maybe all this goes in a FAILURE.md doc? or RELIABILITY.md? Hmm.