Лимит памяти: как не уронить процесс 🧠 Ограничение памяти выглядит как страховка: процесс не съест всю машину. Но у него есть цена — упёршись в лимит, процесс завершится, и это не всегда лучше перерасхода. 🧩 Условный пример. Сервису задали лимит 512 МБ, а он держит кэш в памяти. Под нагрузкой кэш растёт, лимит срабатывает, и процесс падает. Соседи по машине целы, но клиенты видят ошибки. 🔍 Главная мысль: лимит памяти — это не защита от утечек, а граница, за которой процесс умрёт. Поэтому его ставят вместе с метрикой потребления и алертом на рост, а не вместо них. А вы задаёте лимит памяти сервису или полагаетесь на ресурсы хоста?

Мягкая остановка сервиса 🚦 При деплое процесс получает сигнал остановки. Если выйти сразу, принятые запросы оборвутся: клиент увидит ошибку, а транзакция не закроется. Мягкая остановка сначала выводит инстанс из ротации и прекращает приём нового, затем доигрывает активные запросы и освобождает соединения. 🔍 Вывод: порядок шагов важнее самого факта остановки. И обязателен таймаут — без него оркестратор всё равно убьёт процесс, не дождавшись завершения.

Health check, который врёт 🩺 Самая частая ошибка — проверка, что процесс жив. Приложение отвечает 200 OK, а внутри уже нет соединений с базой или исчерпан пул. Балансировщик считает инстанс здоровым и шлёт туда запросы. 🧩 Условный пример: сервис поднялся, но к базе подключиться не смог. Эндпоинт /health возвращает успех, потому что сервер слушает порт. Трафик идёт, пользователи видят ошибки. 🔍 Полезно разделять две проверки. Liveness — жив ли процесс, чтобы оркестратор перезапустил зависший контейнер. Readiness — готов ли инстанс принимать трафик: доступна ли база, не переполнен ли пул. Вывод: health check должен проверять зависимости, без которых запрос не обслужит, а не только факт запуска. И отвечать быстро — иначе проверка сама станет узким местом.