Как быстро менять параметры выплат без доработки фронтенда

Что проверяют

Умеете ли вы вынести изменчивые бизнес-параметры из кода и сделать бэкенд единственным источником правды. Следом обычно спрашивают, как не пересчитать уже проведённые выплаты по новым правилам и кто вправе менять параметры.

Как отвечать

Суть в том, что фронтенд не знает ни лимитов, ни ставок, ни формул: он получает всё из API и только отображает. Каркас на Java-стеке:

• параметры в базе, а не в коде: таблица тарифов, лимитов и комиссий, у каждой записи версия и период действия (valid_from, valid_to). Деньги в BigDecimal и NUMERIC, никакого double;
• история и аудит: выплата хранит ссылку на версию параметров, по которой её посчитали. Смена ставки не трогает прошлое, а спор с получателем разбирается по фактам;
• админка или конфиг-сервис: изменение через интерфейс с ролями и правилом двух ключей (один вносит, другой подтверждает). Для настроек уровня приложения подходят Spring Cloud Config с @RefreshScope или Consul;
• кэш с инвалидацией: Caffeine или Redis с коротким TTL, а при изменении событие через Kafka или Redis pub/sub, чтобы все инстансы переключились одновременно;
• серверное описание формы: если меняется набор полей, API отдаёт схему (например, JSON Schema) с полями, типами и ограничениями, а фронтенд рисует форму по ней;
• формулы: если меняется не число, а логика, подойдёт Strategy с выбором реализации по параметру или движок правил (Drools, DMN-таблицы), когда правила правит бизнес.

Валидация на фронтенде нужна только для удобства, решающая проверка всегда на сервере.

Где спотыкаются

Хранят только текущее значение. После смены ставки уже не объяснить, почему прошлая выплата была другой.

Перечитывают .properties на каждом инстансе отдельно. В кластере из нескольких подов параметры расходятся, и один и тот же запрос платит по-разному.

Сразу тащат движок правил, когда хватило бы таблицы с версиями. Сопровождать Drools дороже, чем пять колонок в PostgreSQL, и оправдан он только при частой смене логики.