Функции-мутанты: рассмотрим на практике

Теория была вот 👉 тут

Продолжим «раскручивать» дубликаты!

KYC: поиск + запрет регистрации нового аккаунта

Нашли совпадение по имени, дате рождения и частично документу → запретили создание нового аккаунта или подклеили аккаунты друг к другу.

При запрете:
— продуктовое ограничение пользователей: я не могу на tel_1 иметь один кабинет под один вид деятельности, а на tel_2 - под другой
— версии поиска будут меняться, значит будут те, кого «незаконно» не пропустили или кого «зря» пропустили

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

Везде:
1️⃣ В аудите невозможно понять, где была ошибка.
2️⃣ Система «оптимизировала», но потеряла управляемость.

Платежи: поиск + дедупликация транзакций

Похожие платежи → «это дубликат» → один отменяем.

А если:
— клиент реально платит дважды (представьте, как бесит, когда терминал продает ток по одному билетику, а у вас одна карточка с собой (Apple pay не работает в стране), а банк отбивает как дубликат)
— автосписание и ручной платеж совпали
— разные мерчанты с похожими атрибутами

Ну и самое интересное: нахождение дубликата до проведения платежа и после его проведения базируется на одних и тех же проверках, но вызывает абсолютно различные действия!
А вы уже вмешались в финансовую операцию на основании вероятности.

Уползем с уровня процесса на уровень реализации.
Для примера про KYC удобно запрятать поиск дубликатов на уровень Conplience платформы и результаты поиска: с кем и на сколько совпало и по каким параметрам и по какой версии алгоритма хранить в одной табличке. Но, если дубликаты понадобятся для внешнего к платформе сервиса — выдать API, с методом который ищет, по переданным снаружи данным, но не сохраняет результат (пример, когда надо: у вас есть мерчант, который хочет понят объем пакета, собираемого с пользователя по одному документу и номеру телефона).

💬 Стало ли на примерах понятнее?