Вы очень поверхностно описали вопрос.
Nginx + php-fpm очень рекомендую. Но самая главная замарочка — репликация/шардинг базы данных. Рекомендую читать не только на официальных сайтах баз данных (там всегда всё «быстро надёжно автоматически»), но и на serverfault, news.ycombinator.com. MySQL очень плоха в репликации, MongoDB тоже имеет с этим косяки. Про PostgreSQL хорошо отзываются (даже master-master есть), но я сам не пробовал на практике. Пробовал Couchbase — прекрасно кластеризуется, даже ребёнок справится, умеет кросс-датацентр репликацию. Но это NoSQL — бд нужно выбирать по задаче. Если больше подходит именно rdbms, то лучше PostgreSQL, imho :)
Ещё вам понадобится кластеризация кэша — как варианты: Amazon ElastiCache, Couchbase, Riak. Через несколько месяцев будет Redis Cluster :)

На одной vps не храните несколько разношёрстных сервисов. Например, сервисы, которые по крону будут делать долгие тяжёлые задачи, лучше вынести на отдельную vps.

Ещё рекомендую сделать api для внутреннего взаимодействия приложений, чтобы они не общались дру с другом, изменяя значения в «чужих» базах или таблицах.

Что, *лядь, за ересь тут в комментариях? Хабр высокообразованный интеллектуальный народ. Считать не умеют. ппц, слов нет. В школе не учились? Когда перед скобками нет знака — это умножение. Сначала выполняется операция в скобках. Операции умножения и деление равнозначны по приоритету.

6/2(1+2)=6/2*(1+2)=6/2*3=3*3=9

Каменное лицо. Только вам еще раскрепощенная участница понадобится.

У вас кривая система авторизации — вам ее исправлять надо, а не ботов различать. Например, как быстрое решение, вместо принудительного редиректа можно в ифрейме показывать форму авторизации.

Если у вас не очень много пользователей и настроек ленты почти нет, можно хранить все новости без дублирования и делать выборку, как советовали выше.
Однако, что получится, если есть не только таблица подписчиков, но и таблица с информацией о приватности новостей (кому из подписчиков что показывать), есть таблица с информацией о людях, чьи новости ты не хочешь видеть в своей ленте (однако не удаляешь из друзей, например). Получается, что с каждой такой фичей запрос на вывод новостной ленты будет обрастать JOINами и вложенными запросами, что весьма негативно скажется на производительности работы. В таком случае, лучше пожертвовать памятью сервера и хранить ленту новостей для каждого пользователя отдельно. Тогда вывод ленты может быть простым SELECTом по индексу.

Могу посоветовать статью про ленту обновлений. Возможно, вы будете использовать другую СУБД, однако идеи и мысли могут оказаться полезными.

Чтобы на пожаре не останавливались перекурить, сидя на перевернутых ведрах :)