Как защититься от дублей REST-событий

Ключ из типа события, ID сущности и timestamp выглядит удобным, но не всегда различает два настоящих изменения в одну секунду. А случайный ID, созданный вашим обработчиком при получении запроса, не распознает повторную доставку.

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

Для внешнего действия храните собственную операцию со статусами «ожидает», «выполняется», «завершена» и уникальным бизнес-ключом. Фиксируйте завершение после результата. Простая запись «обработано» до запроса теряет действие при сбое, а только после запроса оставляет окно для повторения.

Это окно закрывают идемпотентным ключом на принимающей стороне либо сверкой результата. Один sha1 от случайно выбранных полей не даёт гарантии ровно одного выполнения.