Notes

[andrewhowdencom]

• Written in Golang
• Authenticated via OpenID
• Scopes as part of example
• gRPC + REST adapter as part of example
• 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.

[andrewhowdencom]

Todo: Split these out into manageable chunks.