Дмитрий Энтелис

На трафик могут влиять 2 вещи:
a) изменения в рейтинге поисковиков - видны на длинных интервалах
b) поведенческая модель пользователей (интересность темы в зависимости от дня недели, времени года, конкретной даты итд)
Судя по количеству посетителей и фразе "запросы входят в топ-10" - запросы у Вас крайне низкочастотные.
На НЧ запросы по факту не влияют поведенческие факторы, поэтому и стабильность.

Почему люди, который пришли ко мне на сайт в четверг, пятницу или субботу не пришли всем скопом в понедельник и не сделали мне посещаемость в 450 чел ? Неужели поисковые системы так дозируют показы, что люди равномерно приходят на сайт ?
Кто-нибудь может это объяснить ?

Поисковые системы ничего не дозируют. Просто НЧ запрос это фактически событие с крайне низким шансом. На большом количестве попыток (аудитория интернета) оно стремится к нормальному распределению насколько я помню курс тер-вера.
Вам кажется что оно стабильно потому что у вас небольшая выборка наблюдений.
На длинной выборке (XX лет) Вы непременно поймаете дни когда будет экстремально низкий и экстремально высокий трафик.

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

1) Зависит от проекта. Есть 2 большие группы студий: первые делают "шаблонные" сайты и cms используют всегда.
Вторые делают более сложные/нагруженные вещи - и там как правило используется фреймворк, зачастую свой собственный.
Отдельной группой стоят битриксоиды - они вставляют свой битрикс всюду, и пофиг что он начинает падать уже на смешных нагрузках. Зато энтерпрайзненько, сертификаты есть, клиентам нравится пока падать не начнет)

2) Если клиент не собирается развивать бекенд самостоятельно - ему по большому счету все равно на стек технологий, хотелки как максимум идут на уровне "где то слышал", бороться с этим легко.
Если ситуация иная, у клиента есть команда которая после Вас подхватит проект и есть претензии к Вашему стеку - с вероятностью процентов 90 это просто не Ваш клиент.

3) Никакого rocket science тут нет.
Общая цепочка всего проекта:
сбор функциональных требований > проектирование ux > дизайн > верстка > проектирование db > программирование backend.
С последними двумя пунктами, при наличии утвержденного дизайна, справится (так или иначе) любой человек называющий себя backend программистом.

По мере роста сложности проектов и разрастанию команды, Вам понадобятся лиды что бы контролировать качество кода разработчиков и архитектуру, QA что бы тестировать то что получилось, менеджеры что бы управлять потоком задач, ну и тех директор что бы выстроил весь этот процесс ;-)

По факту же, многие студий выстраиванием такого процесса не заморачиваются(он дорогой реально), а просто отдают готовую верстку разработчикам со словами "собери что бы работало". Серьезные проекты так не соберешь, а стандартные корпоративные сайтики, магазины итд - легко

1000 запросов в параллели - это реально не мало.
Может упасть и по памяти, и провиснуть по трафику (если не dedicated сервер), и по быстродействию, и по антиддос.
Нюансов много, тестируйте.

Я бы пересмотрел архитектуру либо в сторону минимизации запросов (если это возможно вообще), либо в сторону введения очередей.

По запросу whatsapp на гитхабе вылазит огромная пачка репозиториев реализующих протокол.
Некоторые из них даже работают.

PS Если есть возможность сменить мессенджер на телеграм - категорически рекомендую.
С новым bot api реализация занимает 5 минут ровно.

Ключевые люди:
1) Product owner - тот у кого есть видение всего
2) условный CTO - тот кто отвечает за техническую реализацию.
И того и другого нужно иметь фуллтайм.

По остальным участникам на усмотрение CTO - как правило это дизайнер, верстальщик и backend программист.
Если сроки не горят - последние 2 могут быть одним человеком, но я бы не советовал.
Кто точно нафиг не нужен на старте, - это Database Developer.
Ваша первая задача - сделать быстрый MVP - если будет трафик, вы успеете 10 раз изменить архитектуру и переписать все заново.

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

Imho подход плохой.
а) рекурсивно обходить папки - это ооочень долго
б) в нормальной ситуации, у скрипта не должно быть прав на изменение исполняемых файлов.

Собственно для этого и придумали PSR4 (хотя нечто похожее можно и без namespace использовать легко)
Главная идея - по названию класса должно быть однозначно понятно где он лежит.
Если вдруг есть любимый класс у которого название не совпадает с местоположением - вот тогда на сцену выходит map файл который заранее заполняется ручками разработчика.

1. Можно например попробовать написать через https://www.nic.ru/cgi/whois_webmail.cgi?domain=PO...
2. Насколько я понимаю исходники этого дела опенсорс https://github.com/popcorn-official

Хранить html как мне кажется точно не лучшая идея.
Я бы сформулировал все возможные типы уведомлений, предполагается ли по ним поиск, и в зависимости от того насколько они различные уже думал. Вариантов может быть море:
1) если уведомления однотипные - поля в базе (условно event_type, date, user_id, post_id итд)
2) если уведомления частично однотипные - часть полей в общей базе (event_type, user_id, date), а часть
2.1) в виде json объекта в строке
2.2) в виде отдельной таблицы на каждый event_type с доп полями
3) какие то денормализированные варианты.
Мы делали однажды очередной клон инстаграма, уведомлений было море - мы хранили сами события в sql, а в redis хранили для каждого user список id уведомлений которые он должен увидеть.