Евгений Ромашкан

У меня сложилось впечатление, что вы изобрели велосипед.
В общем-то в вашем тексте много разумных находок и выводов.
Однако может вам имеет смысл выбрать какой-то фреймворк? Yii, Laravel, Symfony и т.п.
Вы автоматом получите и структуру, и порядок работы, и разделение и кучу всего, что упростило бы вам жизнь. М?

5 это нормально, не беспокойтесь. Количество не всегда важно, иногда и один запрос может базу положить ))

Скажу сразу - о сроках жизни даже не беспокойся)

Одним из главных факторов срока жизни SSD является количество перезаписей на ячейки диска. Чем объёмнее накопитель и больше допустимых циклов перезаписи, тем дольше он прослужит. Тип SSD с TLC имеет 500-1000 (возможно, и более) циклов перезаписи ячейки, и соответственно есть такой параметр, как TBW (Total Byte Write), - общее число байт которое можно записать на диск, после чего ячейки памяти израсходуют свой ресурс.

Все мои SSD (Samsung, Plextor) жили не более 4-5 лет, получается Macbook Air проживет также?

SSD в MacBook'ах стоят хорошего качества и с огромным количеством циклов перезаписи, да стоят они дорого. Если сравнивать твои SSD с теми, что использует Apple, цифры будут сильно отличаться в пользу Apple - и в цене, циклах перезаписи, и тп. На такие диски, как в iMac/MacBook, производители обещают срок службы до 10 лет.

А теперь посчитаем. Допустим, SSD у MacBook Air 2018 имеет объём 128Гб и 800 циклов перезаписи на одну ячейку памяти, а железо меняют раз в 4 года в среднем. Срок службы производитель заявляет до 10 лет.

1. "Чтобы угробить диск за 4 года, нужно...":
а) TBW = 128Гб * 800 циклов / 1024 = 100 ТБ информации можно записать на диск, чтобы ячейки памяти отказали.
б) 100ТБ / (4 * 365 дней) * 1024 = 70 ГБ нужно перезаписывать в день, чтобы диск за 4 года пришёл в негодность.
в) DWPD = 100ТБ / (128Гб * 4 * 365 дней) * 1024 = 0.54 - количество перезаписей всего объема накопителя в день (из 800 допустимых).

2. Время жизни с учётом погрешностей:
Средний пользователь записывает-удаляет 20Гб информации ежедневно (с учётом нагрузки софта на диск).
100 ТБ * 1024 / (20Гб * 365 дней) = 14 лет службы диска, берём в расчёт различные внешние факторы, влияющие на жизнь SSD = получаем 8-11 лет безотказной работы SSD у MacBook Air 18г.

3. "Если объём увеличен в двое":
Точно такой же диск, но с объёмом памяти 256Гб будет иметь показатели, увеличенные в 2 раза.
Например, TBW = 200Тб или 140 ГБ/день перезаписи за 4 года. Но DWPD останется прежним и срок службы тоже до 10 лет.

Вывод:
а) MacBook Air 2018 c 128Гб будет иметь жизнь диска 8-11 лет при условии эксплуатации среднего пользователя;
б) Если ты покупал недорогие SSD с 128-256Гб памяти с меньшим циклом перезаписи, срок службы для них 4-6 лет - как и получилось в твоём случае;
в) У более объёмных носителей показатель TBW может достигать и 900Тб, и даже выше.

https://duckduckgo.com/?q=Unity+biginteger

1. Закопать Fuel обратно в его могилу и больше не беспокоить прах этого умершего в далекой древности старца.
2. Вместо него учить Laravel
3. Открыть для себя документацию РНР и в непонятных случаях обращаться к ней. В это трудно, конечно, поверить, но там всё написаною Эта ссылка находится в двух кликах по запросу "РНР ООП"

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

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

Позднее статическое связывание

Решение:

public static function getMessage(): string
{
  return 'message - ' . static::getString();
}

Можешь тут глянуть реализацию https://github.com/qiao/PathFinding.js только там для поиска пути в лабиринте, но алгоритмы те же.
А задание отстойное, мне ни раз не приходилось на проде это делать. С задачей комивояджера только сталкивался, но там не было смысла трахаться с ней, с данными для нее и т.п., потому что есть osrm.

WHERE 
(
    `phone1` IN ('83519025115','87051036787', '88142531260', ...) 
  OR
    `phone2` IN ('83519025115','87051036787', '88142531260', ...)
)

То, что вы описываете называется long pooling.

1-2, 4. Зависит от реализации
3. Можно, либо посмотреть в сторону websocket