Amazon web services 无法轮询/重试/排队时设计失败

我正在设计一个在云中托管的网站/web服务（特别是AWS，尽管这基本上无关紧要），我花了很多时间思考“为失败而设计”。我希望我的系统能够无缝地处理节点故障，即没有任何重大的用户影响或工程师干预

在大多数情况下，很容易看到如何处理突发节点故障。如果我的应用程序有一个由负载平衡器后面的4台服务器处理的API，由AJAX或iPhone应用程序轮询，轮询器可以简单地检测失败的TCP/IP传输并重试。。。假设负载平衡器行为正确，它将命中一个正常的实例

如果应用程序更倾向于处理，那么可以使用类似SQS的队列服务来允许无状态节点在故障节点停止的地方拾取

我看到的困难在于“入口点”，因为应用程序还没有加载，所以不可能进行重试/轮询，而失败意味着应用程序永远不会启动。例如，网页上的index.html。。。如果节点在传输该文件时失败，用户的浏览器可能会挂起，而不会自动重试（需要刷新）

负载平衡器也是一个“入口/故障点”。但是，在这种情况下，我们似乎可以通过创建多个负载平衡器来解决问题，并使用DNS负载平衡对其进行负载平衡，如下所述：

这是一个适用于更简单的index.html的解决方案吗？总的来说，在无法进行轮询/重试/排队的情况下，我们如何创建冗余

编辑：另一个想法是将index.html静态托管在CDN、S3等（其中资源可用性更可靠）上，尽管这会阻止使用动态内容。如果页面使用JS填充自身，则可以添加动态内容，但这会增加对JS的依赖性以及用户的延迟