3ton

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

P.S. Поздравляю всех с наступающим новым годом и желаю каждому непрерывного самосовершенствования и профессионального роста. Не бойтесь ошибаться, ведь ни один веб-дизайнер не делал прям сразу красивые сайты. Сначала у всех получалось коряво, потом делались какие-то изменения, потом всё снова переделывалось... и так с каждым разом становилось всё красивее.

По первому: наиболее секурно все же отдельные виртуальные машины.
Однако если вопрос только в БД, при условии нормальной архитектуры самого приложения и бд скажем PostgreSQL/Oracle То я бы остановился на схемах. Причем каждый поддомен работает от своего пользователя/схемы с четко разграниченными грантами.
С управляющей схемой контактируют только системы полностью изолированные от пользователя.
Начальное копирование баз для posgre, скажем: от простого дампа основной схемы/create table like до create table of type / inherits

По второму пункту: при грамотной реализации ничего тормозить не будет, во всяком случае у меня 250млн сообщений при 2тысячах активных пользователей не тормозили абсолютно. Тут больше думать нужно над реализаций самих сообщений. Если скажем мы можем удалять свое сообщение из переписки то его копия не нужна, если не можем то табличка вида
-message_id
-message_text
-message_theme (если нужно)
-parent_id (для иерархии ответов, если нужно),
-folder_id (если нужны папочки)
-author_id
-author_name
-recipient_id
-recipient_name
-keeper_id
Решает все проблемы. На каждое сообщение создается два экземпляра и соответственно если keeper_id==author_id то это исходящее, если keeper_id==recipient_id - входящее. Имена отправителя/получателя кешируем в соответствующих полях дабы не выполнять на каждый чих лишний джоин а так же дабы не потерять адресата если вам захочется потереть пользователя из бд (что само по себе плохая идея). Определяемся нужны ли темы,папки итд и составляем индексы под наши запросы - все: радость и счастье, бабочки летают.

Есть.
Причина утечки - прокладка. Между стулом и монитором.
В данном случае причина -

Получаю массив записей из бд

Получать записи надо не массивом, а по одной.
И никакая память никуда утекать не будет. ДАЖЕ если не ансетить те переменные, которые и так будут перезаписаны при следующей итерации.

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

Этот гайд посмотри, как раз похожий пример.

Настроить fail2ban

IP2ASN
Узнать кому принадлежит подсеть, и написать в суппорт.

Надеюсь эта компания не знает мой номер)

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

А вот на вопрос - как выгладит application сервер - однозначного ответа не существует. Простейший пример - apache/mod_php, отдающий некий сайт. Или php-fpm. Или node.js. Или… тыщи их.

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