Иногда лучший способ «сделать асинхронно» — не городить два режима, а честно сломать совместимость и переписат

Иногда лучший способ «сделать асинхронно» — не городить два режима, а честно сломать совместимость и переписать всё под один контракт. В проектах на Битриксе я такую логику вижу регулярно: сначала добавляют второй путь «на всякий случай», потом растёт матрица тестов, усложняется поддержка, а выигрыш в производительности съедается зоопарком исключений.

Типовой кейс из проекта: был модуль интеграции с CRM, где часть вызовов шла синхронно, часть — через очереди и агентов. В итоге отладка занимала больше времени, чем сама обработка. После перевода на единый сценарий — один вход, один формат ответа, один слой ошибок — код стал короче, а поддержка предсказуемее.

Схема простая:
инициатор → единый обработчик → очередь/фоновая задача → запись результата → уведомление.

Мой вывод сухой, но практический: если архитектура уже расползается на «старый» и «новый» режимы, почти всегда стоит сначала считать не throughput, а стоимость поддержки. В enterprise это часто важнее. ⚙️