rPman

Вопрос в том от чего защищаешься?

если твой проксируемый сайт находится в твоей защищенной сети (vpn) или к примеру на его фаерволе стоит блокировка входящих подключений (лучше всего что не нужно, даже исходящих) кроме собственно где находится твой основной сервер, то проблем не ожидается.

Единственное место, где можно опасаться подключений по незащищенному соединению - это атаки на каналы связи. Т.е. если тебе нужно как то защитить свою информацию от атаки провайдерами (всеми кто стоит между твоим сервером и проксируемым), то лучше включи ssl или настрой vpn с шифрованием.

p.s. провайдеры, на основе таймигов и размеров пакетов, (если не пользоваться технологиями как у i2p, которые подмешивают в канал мусорные сообщения) смогут понять и при наличии шифрования, что сервер проксирует информацию и откуда

Поэтому главный вопрос, чего ты боишься, остается

{$txt}

текст в ссылках должен быть пропущен через urlencode, а еще у тебя там минус в идентификаторе

так же настоятельно рекомендую, прежде чем делать приложение, протестировать ссылки вручную через curl, будет видно и ответ, а с ключом -v подробности и заголовки ответа.

fopen не самый лучший способ коммуникации по сети, проще было бы file_get_contents использовать, и у него есть context, который позволяет много что настроить в запросе) но лучше пользоваться встроенный curl_xxx

nodejs полностью асинхронный, когда ты вызываешь метод, помеченный async (при вызове не надо писать await) то в любой момент когда в этом методе вызывается асинхронный метод или стоит await, node будет вываливаться в свой главный event loop и обрабатывать другие запросы

ты спокойно пиши свой setTimer, внутри вызывай свой метод без await (он должен быть помечен как async) и все должно красиво работать, везде где это возможно либо заворачивай в async метод, либо работай с promise либо пользуйся готовыми асинхронными методами

На сколько мне известно, популярные библиотеки telegram - асинхронные, т.е. многопоточность в них используется только для реализации асинхронности обработки соединений на уровне питона, а значит вероятность того что твой код упрется в потолок производительности ядер по ним практически нулевая, даже тупой сетевой hello world на питоне оказывается неожиданно очень медленным.

Т.е. скорее всего тебе хватит двух ядер даже в худшем случае.

p.s. оперативная память - это то что любит питон, будет жрать как не в себя, поэтому если это прямо сейчас надо решать - бери больше оперативной памяти

Но правильно - брать больше ресурсов именно в тот момент, когда это действительно нужно, а стартовую оценку нужно брать с тестов своего кода на основе текущего размера своей аудитории и их активности.

p.p.s. тут недавно человек спрашивал про проблемы нагруженного бота (он зачем то удалил вопрос, не помню какая библиотека была), там из-за ошибки в реализации библиотеки на каждое новое сообщение выдавался запрос одного последнего сообщения через тяжелый запрос поиска сообщений от и до (указывался один и тот же id), при этом библиотека была не асинхронная, при большой нагрузке бот отправлял 100500 таких запросов и сервер отказывал в обработке... т.е. первое о чем нужно беспокоиться в нагрузке - это вот такие баги а не нехватка сервера

в нормальной ситуации, даже большое telegram сообщество сможет обработать слабейшая малинка.

загляни в файловую систему и посмотри с какой скоростью растет tablespace файлы, так же можно с помощью запроса
select pg_tablespace_size ('new_tablespace');
так как в момент добавления колонки таблица копируется (это потому что default значение прописано) значит места должно потребоваться приблизительно в два раза больше чем было изначально, соответственно оценивай приблизительно по скорости роста файла

https://habr.com/ru/company/yandex/blog/435880/