Всё началось с архитектурного тупика. Я занимался бэкенд-частью low-code платформы, на базе которой автоматизировались внутренние процессы крупных компаний. У нашей платформы была жесткая специфика — обязательный и хардкорный оффлайн-режим. Наши пользователи — это прорабы на удаленных строительных объектах и геологи в тайге, где связь пропадает не на пару минут, а на целые дни.

Приложение при этом должно полноценно жить локально: пользователь забивает данные, меняет статусы сущностей, генерирует документы, прикрепляет фото. А затем, когда появляется сеть, на бэкенд одновременно прилетает лавина накопленных синхронизаций.

Поскольку платформа мультитенантная, микросервисная и крутится в Kubernetes, мы быстро упёрлись в проблему неэффективного использования ресурсов. Тенант отдельной компании может «спать» часами или даже днями, не создавая вообще никакого трафика, а потом пачка юзеров одновременно выходит из оффлайна, и нагрузка на сервис взлетает по экспоненте. Держать под каждый тенант постоянно запущенные и простаивающие поды — безумно дорого.

Логичное решение — поднимать сервисы по требованию ближе к моменту реальной нагрузки (Scale-to-zero). Но тут мы упираемся в Cold Start. Пока сервис просыпается, нагрузка уже успевает накрыть инфраструктуру. Так время запуска из абстрактной технической метрики превратилось для нас в инструмент экономии бюджета.