zuborg

Хочу сразу все сделать правильно
Все хотят, да вот ни у кого не получается ;)

стоит ли тогда заморачиваться с выбором базы данных?
Разумеется, хранить надо в отдельной базе данных, можно и файловой. А то когда захочется шаблон html-ки поменять, будет не смешно.

Казалось бы, что может быть проще и легковеснее, чем отдавать статичные .html файлы
Собственно, ничего, поэтому для незалогиненых пользователей, которые генерируют 90% трафика, стоит использовать именно статичные .html файлы. Запросы пользователей, которым надо генерить индивидуальные странички, надо направлять на движок в обход кеша (например, по факту наличия соотв сесионной куки).

Где лучше хранить кэш с .html документами?
в соотв. documentroot, чтобы nginx мог их легко найти и отдать, прямо по запрашиваемому урлу. Крайне желательно поддерживать некоторую вложенность папок, чтобы в каждой папке было максимум несколько тысяч файлов или других папок.

Или может все хранить в тех же файлах?
Все нельзя. Только то что редко обновляется и долго остается валидным. Для короткоживущих данных лучше использовать все-таки memcached, во избежание лишней нагрузки на диск. Либо FS в памяти, если уж хочется работы с файлами. Для короткоживущих данных в php есть замечательное средство кеширования — pecl модуль APC (основное его предназначение opcode cacher, но данные он тоже может кешировать)

У работы с файловым кешем свои тонкости. Например, данные в нем менять надо атомарно, т.е. через временный файл и последующий rename(). Также желательно использовать блокировки чтобы избежать ситуации, когда несколько запросов паралельно начинают генерировать один и тот же элемент кеша. Часто нет необходимости немедленно перегенерировать элемент кеша при обновлении данных, достаточно его удалить, а генерация произойдет при запросе.

Лучше использовать кластер серверов — и надежнее, и дешевле, чем покупать один супер мощный сервер.
В мейнстримовых серверах по две 1Г сетевухи, их можно обьединить и получить 2Гбита на сервер (реальных 1.5-1.8 без потерь покетов)
Опять же, современные недорогие 1U корпуса вмещают 4 винта, вполне нормально для поставленой задачи, можно даже все объединить в raid1 для увеличения производительности чтения.
Проц совершенно неважен для отдачи статики, лучше взять меньше ядер — но больше частоту — положительно скажется на скорости обработки сетевых прерываний.
Памяти стоит напихивать по максимуму, для мейнстримовых мамок это 16Г.
Обязательно обратить внимание на сетевухи, это должны быть либо интел, либо броадком, ни в коем случае не реалтек и прочие марвеллы.
Балансить траф надо не рандомно, а так чтобы один и тот же файл отдавался с одного и того же сервера — так более эффективно используется ram под файловый кеш, грубо говоря — суммируется по всем серверам.
ssd — отдельная песня, в Вашем случае (маленький объем контента) возможно даже более предпочтительнее взять один ssd на 480G за 500уе, чем 4 винта, можно и на памяти сэкономить.

В общем, это уже cdn, возможно Вам будет проще и выгоднее воспользоваться уже работающими на рынке cdn сервисами.

1. 30К человек одновременно? один сервер навряд ли потянет, скорее всего придется строить классический кластер: фронтенды для балансировки -> бекенды для обработки < — дб и кеширующие сервера
Заранее что-то сложно сказать, для начала можно запустить на одном сервере на небольшом трафике и дальше масштабировать самые загруженные елементы.

2. поближе к основной аудитории

4. все равно живой трафик будет определять реальные проблемы архитектуры, запускайте потихоньку