Как я защищаю проект от хаоса, дублей и случайности
Самая неприятная вещь в таких проектах не ошибки, а тихий накапливающийся хаос.
Когда одно и то же событие приходит дважды.
Когда медиа сохраняется повторно.
Когда система постепенно начинает противоречить самой себе.
Снаружи это почти незаметно.
Но именно так проект и теряет форму.
Первое, что пришлось сделать, это остановить дубли на самом низком уровне:
UNIQUE(chat_id, msg_id, media_type)База просто не даёт записать одно и то же дважды.
Без дополнительной логики и без надежды, что это потом кто-то разберёт вручную.
Следом идёт второй слой:
INSERT OR IGNORE INTO ann_message_mediaЕсли событие уже было, оно просто не проходит дальше.
Лишнее состояние не создаётся.
Но дубли это только часть проблемы.
Есть и другая форма хаоса: повторные действия.
Когда система отвечает лишний раз, публикует лишний раз или снова запускает то, что уже не нужно запускать.
Здесь появляется:
cooldown_untilСистема хранит момент, раньше которого она не должна ничего делать.
Это уже не про функциональность, а про дисциплину поведения.
Следующий принцип касается тяжёлых операций.
Их нельзя выполнять прямо в момент ответа.
Если пересчитывать профиль на каждую реплику, система становится избыточно чувствительной и начинает шуметь.
Поэтому часть логики вынесена в фон:
очереди, отложенные обновления, накопление материала перед действием.
И, наконец, сбои.
Если внешний слой падает, проект не должен превращаться ни в тишину, ни в мусор.
Поэтому здесь есть паузы, fallback-сценарии, восстановление состояния, а база работает через WAL, чтобы запись не блокировала систему целиком.
В итоге защита строится по слоям:
- база не пускает дубли
- код не усиливает повтор
- cooldown сдерживает лишнюю активность
- тяжёлая логика вынесена из диалога
- сбой не разрушает весь поток работы
И только после этого вообще можно говорить о качестве ответов.
