Fallbacks are worse than we think they are
Here is a post I made a while ago about fallbacks. I stand by it, but models are a lot better now at not inserting bad fallbacks. I don't know whether that's a product of my guidance, the models' improvement, or both.
Now I'd like to make explicit why I like fallbacks a lot less than most of my peers.
- Throwing an error is often better than falling back (to a default, to a different service, or whatever).
- If fallbacks are treated as successes, underlying errors become hard to detect.
- If you emit metrics or set off alarms when you fall back, it's hard to configure these in a way that isn't flaky or noisy.
- Many services are so reliable these days that it's not worth the time to configure a fallback. (Do you really need to worry about DynamoDB going down? Is the fallback going to do something better than an alarm would?)
- Fallbacks are often used to make code changes safer, but better testing often beats fallbacks with respect to both immediate change safety and long-term tech debt.
In short: extremely reliable functioning (of the main, non-fallback path) tends to be a bit more achievable than we think, and this is getting more and more true over time. And when the main path fails, crashing and/or alarming is somewhat underrated relative to falling back.
None of this means that you should never use fallbacks, just that they're overrated. Inserting fallback paths feels to me like one of those things (like writing too many integration tests) that, for sociological and psychological reasons, has become associated with wise professionalism and is overrated.