Имя Фамилия

Вроде в firebase нет ограничений на пуши (бесплатно и сколько угодно)
По-умолчанию есть квота в 600к в минуту, но если очень-очень нужно, то можно попросить больше.
https://firebase.google.com/docs/cloud-messaging/c...

Очень много пушей за очень малое время не получится отправить (нужно размазывать на несколько минут) и на такое получить квоту нельзя принципиально.
https://firebase.google.com/support/faq#fcm-quotas

Также рейт лимиты могут быть ограничены в пики, когда большая нагрузка на сервис, по тому нужно обрабатывать нормально ошибку 429 и равномерно размазывать свои уведомления в течение дня.
https://firebase.google.com/docs/cloud-messaging/c...

600к отправок в месяц, если они размазаны - это мало и врядли упрётся в какой-либо лимит.

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

Что касается именно заголовков там же есть ограничения на размер и очень экономные. Мне кажется веб-сервер будет неверно воспринимать такой подход он не рассчитан на такие логические извращения. Если проще вещи надо использовать по назначению, чтобы потом самому не страдать.

В MySQL - GROUP BY, JSON_ARRAYAGG, IFNULL

Вы имеете в виду - как можно обойтись без написания и деплоя своего бэкенда для сайта?
Используйте Firebase или Supabase

сайт - это сервер. сервер -это backend.
Про какой "прямой поток" ты говоришь? Такого понятия нет в программировании

если есть сайт то очевидно есть какой-то сервер принимащий запросы?
и сайт и приложение это варианты отображающие состояние сервера
тогда "связь приложения с сайтом" обеспечивается через изменение состояния на сервере
а как именно изменять - зависит от апи этого конкретного сервера

Почитайте про Progressive Web Applications.

https://snipp.ru/php/phpquery

Считать разом все пары (`id`, `title`) в ассоциативный массив, обработать его, занося в новый массив id уникальных записей, затем порциями, например по сотне id, установить признак уникальности в базе, потом удалить все записи, где этот признак не установлен.
Но всё равно, в худшем случае будет 3 000 000*3 000 000/2 = 4 500 000 000 000 сравнений. Так что, в первую очередь надо ускорять функцию similar_text.

Перепиши логику similar_text в функцию. Или всю логику удаления в хранимую процедуру. Или хотя бы логику отмечания, чтобы потом дополнительным скриптом удалить, но ты по крайней мере предварительно сможешь узнать, какие именно данные будешь удалять и проверить их перед этим.

Паттерн внутри немного нечитаем по |, поэтому отделяем цифры любым доступным способом, в данном случае вот так. Обратите внимание что двойной пробел должен сработать раньше чем одинарный. Заметьте, что данный способ это просто удар в лоб, без использования регулярок.

$s = '|1||2||3||7|9|';
       $out =   trim (str_replace('|',' ', $s));
       $out =  str_replace(
           [1,2,3,7,9,'  ',' '],
           ['q','w','e','u','o',',',','],
           $out
       );
       echo $out;

preg_match_all('~\d+~', $s, $match);
echo implode(', ', array_map(fn($n) => '!qwertyuio'[$n], $match[0]));

Есть такая русская пословица, "дурная голова ногам покоя не даёт".
Вот она про это "изобретение".

- Что будет если пользователя взломали, и взломщик залогинен. Дальше пользователь бежит меняет пароль, но взломщик продолжит сидеть под пользователем, ибо файл.
- Что будет если пользователя вдруг забанят? А вы не сделали запрос к БД и не узнали этого.
- Вообще любая ситуация когда вам нужно получить актуальные данные о текущем авторизованном пользователе из базы, но вы этого не делаете, так как экономите на этом запросе. Например решили добавить роли пользователям на сайте, меняете role для юзера. Как без запроса к БД текущему пользователю это узнать, что у него поменялась роль и теперь доступны доп. функции?

Чтобы убрать этот долбозапрос

Поймите и примите простую истину - база данных создана для того чтобы РАБОТАТЬ, так пусть же работает и исполняет ваши долбозапросы. Не нужно тут ничего придумывать.

«Преждевременная оптимизация — корень всех зол». Дональд Кнут.

Проверяй функцией MAX() последний номер фото, не забыв указать в WHERE текущую дату