prochanev

Мы в Монге хранили весь JSON со сценарием диалога. Сначала начинали на Постргресе делать, но потом это оказалось дольше и не так удобно на этапе MVP, потому засунули в монгу + фронт для создания этого сценария создавал весь этот JSON, который можно было просто и быстро провалидировать и дальше пользоваться.

Нормально ORM работает с JSON, но не понятно зачем вам именно реляционная БД, если вы фактически отказались от нормализации и джойнов.
Для вашего этого варианта подойдёт и NoSQL.

таких ботов/диалогов может быть много.

Много - это понятие растяжимое. Вы уже столкнулись с каким-то бутылочным горлышком и хотите уже что-то оптимизировать? Если нет, то делайте как проще и понятнее в рамках функциональных требовний.

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

В вашем случае можно сделать всё на ORM и реляционной базе. Включая отдельные модели для вариантов ответов и прочего.
Можно отказаться от ORM и размещать одного бота в одном документе. Тогда можно использовать монгу и десериализацию документа в собственную структуру классов. Тут писать получится больше, но и гибкость будет выше, можно будет пользовтаельские плагины какие-то прикручивать... вопрос - надо ли это и понадобится ли в будущем?

Фактически диалог - это конечный автомат. Его можно представить в виде графа. Человечество уже давно придумало много способов сохранять и оперировать графом в любой БД, в том числе реляционной.

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

Если не использовать замыкание, то надо определить следующую функцию

function log(timespan, lineNumber, msg) { 
   console.log(linNumber + " " + timespan + " " + msg;
}

и две переменные

var start = Date.now();
var lineNumber = 1;

Вызываем log так

log(Date.now()-start, lineNumber++, "один");
log(Date.now()-start, lineNumber++, "два");

Очевидно, что это неудобно.

Если использовать замыкание, то пишем так

var log = (function () {    // функция 1
   var start = Date.now();  // текущее значение сохранятся в start 
   var num = 1;             // также используется в замыкании в функции 2. 
   return function (msg) {  // функция 2 - сохраняется в var log
      console.log(num++ + " " + (Date.now()-start) + " " + msg);
   }
})();    // () -- вызываем функцию 1

Вызываем так

log("один");
log("два");

Результат

lineNumber   timespan     msg
------------------------------
1            0            один
2            1            два

Т.е. замыкание — это способ передачи данных в функцию.

Подробнее о замыканиях см Mozilla Developer Network
Примет взят отсюда

class Element:
    recipes = {
        ('Aqua', 'Air'): 'Storm',
        ('Aqua', 'Fire'): 'Steam',
        ('Aqua', 'Earth'): 'Dirt',
        ('Air', 'Fire'): 'Lightning',
        ('Air', 'Earth'): 'Dust',
        ('Fire', 'Earth'): 'Lava',
    }
    recipes.update({(b, a): c for (a, b), c in recipes.items()})
    classes = {a for a, b in recipes.keys()} | {*recipes.values()}
    
    @classmethod
    def __str__(cls):
        return cls.__name__

    def __add__(self, other):
        if isinstance(other, self.__class__):
            return self
        try:
            return eval(self.recipes[(str(self), str(other))])()
        except KeyError:
            return None

    
for cls in Element.classes:
    exec(f'class {cls}(Element): pass')

print(Air() + Aqua())

Ну я думаю, что не стоит рассказывать о прелестях и возможностях гита. Если вы работаете в одиночку, то не обязательно использовать ветки. Можно и в мастер коммитить, и использовать для того, чтоб всегда можно было откатиться к любой версии. Я тоже, когда работаю над небольшими проектами в одиночку не пользуюсь ветками. Но если проект "живой", и весит в вебе, то всегда есть риск, что что-нибудь сломается, и тогда, чтоб в попыхах не ломать голову, пытаясь найти ошибку, и не наломать дров, как обычно и бывает, когда срочно нужно что то поправить, можно спокойно откатиться до рабочей версии и искать неспеша ошибку. Хотя бы ради этого стоит использовать гит.

Потому что он на самом деле не скомпилирован. Утилиты типа pyinstaller, cx_Freeze и тому подобные просто создают самораспоковывающийся архив, содержащий интерпретатор и ваш скрипт. Запуск упакованного в исполняемый файл кода - это как раз то поведение, которое свойственно для вирусов.

ltree.

Берёте систему мониторинга Zabbix (или аналоги) и используете её функционал. Если чего-то не хватает, системы мониторинга обычно расширяемы.

Ну или пишите свой велосипед.

Собственно, что нужно настроить или реализовать:

• Периодический ping сервера с приложением;
  
• Периодические HTTP запросы в приложение с ожиданием HTTP кода 200;
  
• Для проверки websocket использовать websocket клиент;
  
• Логирование процессов приложения;
  
• Мониторинг логов приложений на предмет ошибок;
  
• Уведомления (EMail, Telegam, SMS), если что-то пошло не так.
  

Если написаны простейшие тесты и настроено логирование, то мониторинг на половину готов.

Если для операций IO, то есть ведь asycio.

Не всё можно сделать асинхронным. Например файловый ввод/вывод в Windows без блокировок можно осуществлять только в потоках.