Дедупликация кандидатов, когда площадка присылает одно и то же событие два раза

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

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

Дедупликация кандидата учитывает не только идентификатор события, но и совпадение по контактным данным — если кандидат с такими контактами уже существует, новое событие присоединяется к нему, а не создаёт запись-дубликат.

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

А если событие в принципе невозможно обработать сразу — например, вакансия на площадке ещё не синхронизирована — оно не отбрасывается, а сохраняется целиком и может быть переиграно позже.

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