Кто виноват в сливе рекламного бюджета? При создании рекламного line item рекламодатель устанавливает бюджет - N долларов в день. С точки зрения любого line item стратегия (в Х) простая: в каждом аукционе он делает ставку из расчёта k долларов за целевое действие (показ, клик, покупка): k * p(event). Значение k определяет компонента под названием пэйсинг (pacing). Количество выигранных аукционов в течение дня, а также потраченный бюджет - строго монотонная функция от k. Пэйсинг занимается подбором такого k, чтобы было потрачено ровно N долларов за день. На практике возникает неловкая ситуация. Пэйсинг как будто бы компонента, принимающее важное решение, от которого зависят все метрики рекламодателя, а не просто маленькая калибровочная компонента. И он получает все косые взгляды в момент, когда что-то идёт не так. Команде бэкэнда одним непримательным утром пришла стопка жалоб от рекламодателей - в районе 7 утра у многих сильно скакнули стоимости показов, и бюджет на два часа был слит за 15 минут. Разумеется, все пошли искать какие-то инциденты в пэйсинге и проверять, почему у него поехала крыша. Той же ночью произощёл ещё один инцидент, в котором копалась команда моделинга - ночью поплавилась одна инфровая компонента и в результате очень сильно упал Success Rate модели с 4 до 6 утра, после чего выкатили фикс. На общей встрече рекламы, когда рассказали про проблему со слитым бюджетом, почесав репу, я на опыте предположил, что эти 2 инцидента связаны, и что именно произошло, и оказался в точности прав - мелочь, а приятно. Когда бэкэнд, считающий p(event) с помощью вызова инференс движка модели, получал 🖕вместо ответа, он использовал 0 в качестве p(event). Таким образом, у оптимизирующих клики или продажи ставка за показ превращалась в 0 и они не могли выиграть в аукционах. Видя, что бюджет тратится сильно медленнее целевой скорости, пэйсинг начинает накручивать k - стоимость события, и в итоге нарастил его в несколько раз у многих line item. Условно, в трубе, засоренной на 80%, пэйсинг увеличил давление в 5 раз, чтобы вся вода успела протечь. В чудо-момент, в который мы чиним инференс, Success Rate взлетает до 100%, и все участники аукциона стали получать честный p(event). Нормальный p(event), умноженный на раздутый k, дал всем огромную стоимость показов, которую все дружно заплатили. Два урока, который мы из этого вынесли - во-первых, fallback не должен быть нулевой - какое угодно плохое предсказание среднего не возбудило бы пэйсинг так сильно. Во-вторых, внезапно, но в случае больших проблем с моделью восстанавливать норму нужно медленно, потому что пэйсинг поддерживает хрупкий баланс в системе и ему нужно давать время на подумать. Уже через пару недель, когда у нас сломался чекпоинт ретривала, я не выкатывал фикс на весь движок, а выкатывал вручную, начиная с 1 ноды, потом 2, 4 и т.д., и тем самым избежал повторения ситуации. @knowledge_accumulator

Почему монолиту приписывают одну базу данных (БД)? Нет такого требования, что если монолит, то должна быть одна БД. Но любители микросервисов часто приписывают монолитам недостаток в виде одной базы. Монолит может работать с несколькими БД и хранить данные в отдельных базах на одном сервере или даже на разных серверах. У меня в SonyRewards было несколько баз данных: основная пользовательская, банковская, почтовая с маркетингом, сессии, каталог и база для контроля отгрузок. Каждая база может быть настроена по разному на производительность, разные стратегии резервного копирования и безопасности в зависимости от данных, которые там хранятся.