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

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

Значит открытие донышки и не имели резерв

Можно вопрос чуток не по теме?
Насчет вообще архитектуры веб проекта.

Есть сервер, на котором висит вебхук от Телеграма.
Есть сервер, где каждый час происходит достаточно тяжелая задача (поэтому для неё и выделен отдельный сервер) - веб парсинг в многопотоке
Есть потребность хранить данные => выделеный сервер под PostgreSQL или вместе с парсером.

Итак: пока надумал три варианта
1. все элементы на отдельных серверах связь каждого с каждым по rest api
2. сервер с телеграмом работает только на ввод/вывод данных => вся обработка и общение с бд лежит на сервере с парсером.
3. объединить парсер с базой данных на одном сервере.

Данные в бд гоняются туда-сюда достаточно часто, хватит ли для парсера и этого одного сервера?
Какая практика вообще присутствует? Всё разделять? Или может посильнее кучковать, а не делигировать, чтобы было меньше шансов, что что-то отлетит?

а зачем вам рест между сервером и бд?

бд же по сокету по протоколу самого постгреса работает

имхо (не эксперт в архитектуре) - если парсер не кушает много ЦП ресурсов и ОЗУ - можно и там бд хранить

но лучше конечно отдельно, потому что проседать будет либо парсер, либо бд

Просто сервер с телегой точно завязан на бд
Если бд отпадет, от бота не будет смысла)
Поэтому и планирую раскидать

почему бы во втором варианте не поменять парсер и бд местами? парсер кидает в бд данные, бот их оттуда берет. Или вам надо чтобы бот общался с парсером?

Хм
Спасибо, очень дельная мысль)
Как-то не подумал
Просто первоначально парсер был частью сервера с телегой
И там и крутилась крон задача на парсинг каждый час
Поэтому априори считал, что задачу парсеру задаёт сервер с вебхуком..
.
Тогда теперь надо выбрать между первым и вторым))

ну между первым и вторым (где бд на месте парсера) разница лишь в том, общается бот с парсером или нет. Тут уж как вам нужно архитектурно

А, ну конечно
Я вспомнил почему я так решил
Парсер должен отправить боту новые данные для рассылки
Дело в том, что невозможно заранее определить сколько парсинг займет времени (зависит от количества вводных данных == пользователей)
Если бы время было фиксировано, я бы просто допустим через 5 минут после парсинга забирал бы обновленные данные с бд и делал бы рассылку

Поэтому и логичным для меня было отправлять с бота запрос на парсинг, а потом через какое-то время просто получать ответ с данными

Значит второй вариант 100% отпадает

А для стабильной работы и третий тоже не подойдёт видимо

Итого у нас есть победитель))

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

Ну это естественно, куда в наше время без денег
Спасибо огромное за дельные мысли)