Author here. This is a challenging one, because it is intimately related to what is acceptable or not to your users.<p>By default you could say that if the storage mechanism must be up and available and it isn&#x27;t, then the front-end shouldn&#x27;t be responsive and it should crash.<p>You could also say that you want the front-end app to be available if the storage layer is offline. This has two possible consequences:<p>a) you disconnect the front-end and the back-end so that they do not depend on each other. This can be done either through application strategies (you can define the storage app as &#x27;transient&#x27; so it can fail without shutting down the system) or by putting the front-end on a different Erlang node.<p>The latter means that your dependency on the storage back-end is not as direct as it seems.<p>b) this is my preferred solution, and it requires you to rework what you think of as &#x27;depends on&#x27;. If you expect the storage layer to fail and that you must be able to service the front-end anyway, then the architecture demoed in the presentation needs an asterisk.<p>The reason for this is that the dependency as described crashes if the database is not available, because the storage subtree acts as a proxy for &#x27;the database&#x27;. The OTP structure encodes &#x27;my database is available&#x27;.<p>I can rework that requirement to mean &#x27;the storage layer is up and ready to talk to a database&#x27;. This is a huge change because it no longer promise the DB is available, it promises that something whose job it is to talk to the DB is available.<p>You can then change your interface accordingly. I go into some more detail about this in &quot;It&#x27;s about the guarantees&quot; <a href="http:&#x2F;&#x2F;ferd.ca&#x2F;it-s-about-the-guarantees.html" rel="nofollow">http:&#x2F;&#x2F;ferd.ca&#x2F;it-s-about-the-guarantees.html</a><p>In a nutshell, the difference in both initialization and supervision approaches is that in the one described in b), the client&#x27;s callers make the decision about how much failure they can tolerate, not the client itself. The client making the decisions is what is described in the presentation.<p>Sadly I could not fit all of that and the compromise of supervision structures within the hour I had allocated for my presentation, so this comment and the side-blog post ought to do (I&#x27;ve also put that material in Erlang in Anger, if you happen to grab that free ebook).