"I think that author just does not have experience outside of what he does." Kelsey's recommendations aren't that different from general resilient systems guid

"I think that author just does not have experience outside of what he does." Kelsey's recommendations aren't that different from general resilient systems guidelines in the Erlang community, or any of the many notes on how distributed system development is Different. "But what is sane default if you have to communicate with 3rd party server and your system is worthless when connection is not there? " The sane default is to wait and keep trying to connect for at least a bounded period of time (and a sensible approach to backoff). The point is that, if you're building distributed systems, you need to account for partial failure. One of the 12 factors is the process model: your app should be considered a process that will be killed and/or restarted at will. It might do so when your backing services are currently unavailable. The sensible thing is to retry a bounded number times (with backoff) before giving up. Sometimes the underlying application platform also does this for you (by killing your app process and rescheduling it, if it doesn't come up after a certain time period). Baking in timing dependencies as a failure mode makes software less resilient.