в догонку к вышесказанному:
1. если СЕО позволяет, постарайтесь побольше делать на стороне клиента (javascript templates/ajax/..) и поменьше на сервере
2. не экономьте на разработке кода-управления кластером (а для высконагруженных проектов кластер нужен хотя бы для надежности): скрипты обновления (а и в проекте необходимо учесть что его код и данные могут обновляться), резервирование и восстановление из резервной копии, управление кластером — добавление/удаление/настройка узлов, и т.п.
Просто при плохой организации высоконагруженные проекты глючат чаще :) потому что банально 'тестеров' больше.
3. не гонитесь за технологиями, не стоит нагромождать фреймворки, плагины и библиотеки друг на друга, быть проще всегда полезно, и возможно свой велосипед в некоторых местах моет оказаться предпочтительнее (я не говорю про случаи, когда практически вся задача в полном виде решается уже чем то готовым, всегда есть нюансы)
4. оптимизация sql это круто, но очень часто nosql решения (+что то по сериализации) вполне себе заменяют sql (а уж по скорости безусловно побеждают), как вариант — комбинированные решения (но последнее порождает чуть больше проблем при обновлениях структуры и кода)
* memcached — это кстати тоже nosql, только не является хранилищем (не гарантирует что если данные сохранил, то их можно будет извлечь)
* вот в решениях хранения не стоит городить собственных велосипедов и не стоит изобретать кошмар на файлах. НО, например небольшие статичные (редкоизменяемые) куски БД гораздо эффективнее подгружать прямо в виде PHP массива (до размера сотен кб php код иннициализации переменных работает значительно быстрее любого БД-фреймворка, не говоря уж про накладные расходы на соединения с БД и т.п.)
P.S. будьте готовы все переписать, это актуально для развивающихся проектов, т.е. сначала используя сложные но готовые средства реализуется что то работающее, на чем обкатывается бизнеслогика, затем, когда этот монстр становится просто неповоротливым, на основе готового, с нуля, реализуется новый проект, без болячек роста, быстрый и простой.