Vamp

Подойдёт любая тикетница. Например, OTRS или osTicket. Каждое обращение - новый тикет. Тикетам можно настраивать напоминания, если они не закрыты какое-то время (sla), приоритеты.

Ruby on Rails

Вы же зачем-то решили переместить основной сайт в onion? Вот те же самые причины применимы и к поддомену.

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

Распараллелить выполнение в самом воркере с помощью ReactPHP или лучше GuzzleAsync. В таком случае не придется держать 5000 воркеров именно

Вариант с GuzzleAsync - самый лучший. Под капотом он использует возможности curl_multi_exec, которые позволяют асинхронно отправлять несколько запросов, не плодя при этом лишние процессы. Не уверен конечно, что осилит 5000 параллельных запросов, но даже если и не сможет, то можно разделить 5000 между несколькими воркерами.

2. "Правильно ли" это вообще делать с помощью PHP или это все таки задача уже других языков которые умеют в параллельное выполнение, корутины? Go, NodeJs?

У вас нагрузка в основном IO bound, так что не имет значения какой язык выбрать. Главное чтобы он поддерживал IO multiplexing (который поддерживается в PHP через вышеупомянутый curl_multi_exec).

3. Может уже есть готовые решения в виде библиотек на PHP? Искал, но не нашел

Guzzle

В dev окружении почти никогда не бывает такой же образ как в prod. Но docker позволяет сделать очень близко к проду при помощи наследования. То есть prod наследуется от, допустим, php:7.3.3-fpm, устанавливает нужные модули и опции php.ini, а dev образ наследуется от prod и доустанавливает xdebug, composer, node, модифицирует только нужные для дева опции php.ini.

Такая организация позволяет почти не тратить время на актуализацию dev образа. Поменялся prod - в одну команду пересобрали и dev. Очень удобно.

Корнем всей иерархии будет это базовый prod образ, в котором нет никаких файлов проекта. Уже от него наследуются dev и образы с запакованным приложением. В контейнер на основе dev образа монтируете рабочую директорию проекта и работаете как удобно.

Иерархия наследования получается примерно такая:

php:7.3.3-fpm
└─ prod:base
   ├─ dev:latest
   ├─ prod:0.0.1
   ├─ prod:0.1.15
   └─ prod:1.0.4
      └─ prod:latest  (плавающий тег, указывающий
                       на самый свежий релиз)

При таком подходе у вас будет 3 докерфайла - prod:base, dev и финальный prod.

Можно обойтись двумя докер файлами, если на прод подсовывать скрипты проекта через volume, как и в dev. Я как раз использую этот вариант, так как в моей компании применяется continuous delivery. Грубо говоря, это когда почти каждый коммит в master сразу улетает на прод. Если каждый раз собирать новый образ, становится слишком много образов, за которыми приходится отдельно следить и удалять старые, чтобы избежать переполнения реестра. Плюс возникают сложности с обеспечением атомарности деплоя, так как сервис становится недоступен в момент рестарта контейнера, из-за чего приходится городить балансировку и/или blue-green деплоймент.

С volume всё просто - залил в него новый код, переключил симлинк и всё готово. А базовый образ меняется относительно редко - обычно когда выходит новая версия PHP. В этом случае можно и ручками обновить базовый образ на сервере. Но этот вариант хорош только когда мало серверов. Для больших кластеров конечно лучше работает вариант с упаковкой приложения в отдельный образ.