Возврат уже выполнен, а сайт всё ещё показывает «В обработке»

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

Когда страница отображает информацию о возврате денежных средств, подобная ошибка уже не является косметической. Если деньги действительно возвращены, система обязана честно сообщать об этом пользователю — именно эту проблему мне предстояло решить.

Загадка «замороженного» статуса

Основная страховая система, с которой работает бухгалтерия, сразу знала актуальный статус заявки. Однако сайт хранил собственную локальную копию каждой заявки, которая создавалась только в момент её отправки, — и раздел «Мои заявки» отображал именно её. Единственный механизм обновления существовал внутри мастера расторжения полиса: только там сайт спрашивал у внутренней системы «каков текущий статус?». Проблема в том, что после отправки заявки пользователю больше незачем открывать этот мастер — поэтому локальная запись никогда не обновлялась.

Я подтвердил это на реальных данных: в один и тот же момент страховая система возвращала «Завершено», тогда как локальная запись продолжала хранить «В обработке», не изменившись с момента создания. Правильная информация существовала — устаревшей была её копия. Заодно обнаружилась ещё одна деталь: две системы использовали разные обозначения одного и того же состояния — одна возвращала success, тогда как сайт ожидал completed. Даже если бы данные обновились, статус всё равно отображался бы неправильно.

Решение — страница сама незаметно проверяет актуальный статус

Вместе с коллегой, отвечающим за backend, мы выбрали решение, которое не ухудшает скорость загрузки: список заявок по-прежнему моментально отображается из локальной базы, а затем страница незаметно, в фоновом режиме проверяет каждую незавершённую заявку в основной страховой системе. Как только приходит ответ, статус на экране обновляется автоматически — и одновременно обновляется локальная запись в базе данных. Получается, что база постепенно исправляет сама себя: достаточно, чтобы пользователь просто открыл страницу своих заявок.

Ограничения для продакшена: проверки выполняются по одной (пул PHP-воркеров невелик), неудачная фоновая проверка ничего не меняет на экране, уже завершённые заявки никогда не проверяются повторно, а строка, статус которой изменился во время просмотра, обновляет только значок и не перемещается между вкладками — интерфейс не выглядит нестабильным.

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

Сегодня два статуса, завтра — четыре

Пока основная страховая система поддерживает только два состояния: «На рассмотрении» и «Завершено». Полный жизненный цикл — включая «Отклонено» и «Средства выплачены» — ещё находится в разработке на стороне бухгалтерской системы 1С. Вместо того чтобы откладывать работу, я сразу подготовил систему для всех четырёх статусов: если сегодня приходит неизвестное значение, интерфейс корректно его обрабатывает и продолжает работать без ошибок, а когда бухгалтерия начнёт передавать новые статусы, потребуется лишь добавить соответствующие подписи — архитектуру или пользовательский интерфейс менять уже не придётся. Ожидание изменений от другой команды — обычная часть разработки; гораздо важнее заранее подготовить систему к этим изменениям.

Ещё две задачи этой недели

Помимо исправления статусов, онлайн-оплата стала доступна для всех страховых продуктов. Раньше оплата банковскими картами UzCard и Humo с SMS-подтверждением работала только для одного страхового продукта — интеграция с платёжным шлюзом не была готова для остальных. Теперь она полностью готова, и возможность оплаты постепенно включается для всех страховых продуктов, с логичным разделением обязанностей: сайт предлагает доступные способы оплаты, а backend определяет, какие продукты поддерживают оплату банковской картой.

Кроме того, я провёл глубокий аудит производительности всей платформы — как клиентской, так и серверной части. Результаты показали несколько серьёзных проблем: слишком тяжёлые изображения размером в несколько мегабайт, отсутствие кэширования на разных уровнях системы и база данных, выполняющая значительно больше операций, чем необходимо. Оптимизация производительности станет следующим крупным этапом, а главный результат аудита — не просто список проблем, а приоритизированный план, позволяющий начать с тех изменений, которые дадут наибольший эффект.

Самый важный вывод, который я постоянно подтверждаю на практике: когда две системы показывают разные данные, ошибка редко находится в одной из них. Чаще всего она возникает именно между ними — там, где данные перестают синхронизироваться.