&quot;I think that author just does not have experience outside of what he does.&quot;<p>Kelsey&#x27;s recommendations aren&#x27;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.<p>&quot;But what is sane default if you have to communicate with 3rd party server and your system is worthless when connection is not there? &quot;<p>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).<p>The point is that, if you&#x27;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&#x2F;or restarted at will.  It might do so when your backing services are currently unavailable.<p>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&#x27;t come up after a certain time period).<p>Baking in timing dependencies as a failure mode makes software less resilient.