Román Mirilaczvili

Уверен, что есть множество реализаций AMQP и для Python. У каждой из них должная быть своя документация.
При инициализации проекта можно создать соединение или даже лучше пул соединений, используя которое/ый в некотором издателе, отправлять в нужную очередь.

Есть множество генераторов статических сайтов. Например, Jekyll

Если на скорую руку, то при помощи сериализации Pickle или JSON/XML.
Или по-хорошему, в СУБД. Тогда нужно проектировать БД. Но зависит и от объемов данных. Не всегда целесообразно, особенно если их мало.

Для хранения файлов запустить MinIO (протокол S3) на своих мощностях или выбрать любого провайдера S3.
Обращаться к S3 по API из приложения при помощи библиотек.

В коде, используя PHP обертки над командами SCAN и DEL.

Можно выполнить команду
split book.txt -l 100000
обвернув в системный вызов в Питоне.

Jekyll - из самых простых, наверное. Там же и про хостинг написано.

C# для встраиваемых устройств:
https://en.wikipedia.org/wiki/.NET_Micro_Framework
https://stackoverflow.com/questions/568266/c-sharp...

Язык Vala синтаксически похож на C# и используется в проекте GNOME.
https://en.wikipedia.org/wiki/Vala_(programming_la...

Очевидно, нужно выбрать пакет Hobby или выше, который гарантирует, что приложение не будет засыпать и также решает проблему с сертификатом.

Не нужно перезаписывать файл заново.
with open("file.txt", "w") as f:вынести за цикл for.
Закрывать файл нужно только после for.

Возможно подойдет https://sslip.io/

Неправильно как-то все это.
Если есть запрос, значит, и соединение. Пока ответ не отдан, веб-сервер должен держать соединение. А если ответ не возвращается, то клиент ждет, пока соединение не отвалится по таймауту. Так что эта техника довольно затратна с точки зрения ресурсов, которые могут быть исчерпаны. Особенно, при наличии достаточно большого количества клиентов.
Ну а так, ошибка 500 может означать и логическую, и ошибку соединения с СУБД, и что какой-то ресурс 3-й стороны недоступен, и многое другое. Так что если логическая, то сервер не "исправится" и, при этом, не выйдет из спячки, если будет ждать ответа 200.
Ну а так, блокировать выполнение можно при помощи каналов (channel). Но практический смысл в этом не вижу.

Тогда нужно переключиться на средства мониторинга MySQL.
Виновником может быть запрос наподобиеselect * from users
без limit.
При наличии большого количества записей может забить весь канал.
Такой запрос от пользователя с достаточными привилегиями покажет какие текущие запросы выполняются долго и что выполняется в тот момент, включая операции по передаче данных по сети.
show full processlist

https://docs.docker.com/storage/bind-mounts/