Heavy retry Lite

# Heavy retry Lite забывать обработать ошибки в async коде стоил нам N часов даунтайма. Больше не стоит. ## зачем Потому что дебажить проблемы с памятью. Не потому что так в блоге написали — а потому что реально бесит и тратит время. ## подход Один раз rate limiter не сработал и нас заддосили. С тех пор — правило. Не красивое, не академическое. Рабочее. ## правила 1. Всегда обрабатывай ошибки. Не try-catch который глотает всё, а реальная обработка. 2. Не доверяй внешним сервисам. Timeout + retry + fallback. 3. Логируй контекст. Request failed — бесполезно. Request to PAYMENT/charge failed 502, orderId=123 — можно дебажить. 4. Fail fast на валидации. Ошибка в input = 0. В business logic = минуты. На проде = дни. 5. Простое лучше умного. Объяснять > 5 минут — перепиши проще. ## когда НЕ использовать - Проект — прототип на 2 недели - Команда из 1 человека - А давайте добавим вместо нам это нужно прямо сейчас ## трейдоффы - Больше boilerplate — да. Но окупается при первом инциденте - Чуть медленнее — да. Но 12ms vs 15ms не стоит 3 ночи дебага - Поддерживать — да. Но проще чем тушить пожар в 3 ночи