Пункт 5 может сыграть злую шутку. Что значит “минимизировать зависимость от БД”? Это может толкнуть на разбиение целостных данных на кучу разных БД (ибо файл - та же БД, хранение данных в памяти - тоже БД). Что впоследствии может создать просто неимоверную тучу проблем при расширении на большее количество серверов (увеличение самих логических единиц). Так что к этому совету нужно отнестись аккуратно.

Пункт 6 и вовсе спорный. Даже самую страшную утечку памяти можно нивелировать дав “долгоиграющим” (кстати - дурацкий термин) процессам какой-либо лайфтайм. Заставлять систему порождать уйму форков по пустякам - не разумно.

Так или иначе это просто описания проблем с которыми столкнулся автор. Ну никак нельзя принимать такое как руководство к действию. Тем более это относится к пунктам без доводов (5 и 6 как раз =)). К 5 доводы есть, но они совсем не выдерживают критики - “дополнительное звено” черт побери. И что теперь от БД совсем отказаться? Если БД умрёт то никаким кешем проект все равно не останется работоспособным. Лучше уж сделать это звено максимально отказоустойчивым. И это вполне возможно.

На счет доступности 99,99% - это очень высокий показатель, для достижения которого придется предъявлять очень высоки требования ко всему, начиная от архитектуры самого решения и заканчивая маркировкой кабелей в ЦОДе. Вообще в ЦОДе сделанном не по стандарту ANSI/TIA-942 добить такой доступности практически невозможно, а строительство таких сооружений достаточно дорого (стоимость по площади фальш-пола будет превышать 10000 долл./кв.м.).
Во общем работать над такими проектами очень интересно

согласен по поводу 99% и по поводу того, как нужно организовывать мониторинг. Мы сейчас пытаемся добиться 99.99%, что ой как непросто
По поводу требований к доступности. Есть две точки зрения на это:
- внешний пользователь не получает сервис в ожидаемое время и перестаёт пользоваться сервисом. Мониторить количество пользователей - вполне очевидное для этого решение.
- внутренний пользователь (человек или другое приложение) не получает сервис, и компания теряет деньги. Решается это оценкой ущерба или недополученной компанией прибыли. (Мы активно пользуемся этим подходом)

По поводу пунктов 3 и 7: тут стоит вопрос о том какой уровень доступности должна гарантировать платформа (в данном случае WEB-сервис)…

Если требуется гарантированная доступности 90% (т.е. возможность неоказания сервиса в течении десятков суток в год), то может быть достаточно и настроенного на смартфоне почтового клиента, службы мониторинга сайтов и одного ответственного. Но это не параметры доступности коммерческой системы.

Если требуется доступность хотя бы 99% (т.е. не более 3 с небольшим дней в год), то уже требуется нормальный круглосуточный мониторинг и 1-2 ответственных специалиста второго уровня суппорта, которые посменно готовы поддерживать по телефону мониторинг.

Мне интересно какие требования к доступности предъявляются к WEB-приложениям (когда с пользователем не заключен какой-либо договор об обязательствах)?

Например в коммерческих системах сервисных платформ оператора сотовой связи, которые эксплуатирую я, требования к доступности - 99,9 (чуть больше 8 часов простоя в год). И тут уже требуется очень проработка даже таких вещей как организация мониторинга и режима работы сотрудников эксплуатации. Не говоря уже о многих других аспектах, которые в совокупности и позволяют обеспечивать такие показатели (и которые, что удивительно, поставщики, продающие платформы за миллионы и десятки миллионов USD периодически не учитывают в своих решениях и потом натыкаются на это при установке и поддержке решений).