QA-Логия

Тестирование идемпотентности в продакшене: как ловить дубли событий до инцидента Идемпотентность не заканчивается unique key в базе: при at-least-once delivery одно событие может прийти несколько раз. Частая ошибка QA и разработки - проверять только happy path, не доказывая, что повтор не создает второй бизнес-эффект. Что проверять Инвариант не "событие пришло один раз", а "повтор не изменил состояние второй раз": * один payment_id - максимум одно списание * один order_id + event_type - один переход статуса * один external_webhook_id - одна обработка * один idempotency_key - один результат операции * повтор не меняет баланс, лимиты, остатки Production probes без риска Практичный подход - безопасные контрольные дубли: * отправить событие * повторить его с тем же event_id или idempotency_key * проверить, что нет нового side effect * убедиться, что ответ совпал или вернулся already processed * проверить рост метрики дедупликации Предупреждение: не делайте это на живых деньгах и реальных клиентах. Используйте test tenants, synthetic users, sandbox merchants, zero-amount операции или internal-only флаги. Логи и метрики Если нельзя связать дубль с эффектом, observability бесполезна. Логируйте: * event_id, idempotency_key, trace_id * consumer_group, handler_name * dedup_decision: new | duplicate | conflict * side_effect_created: true | false * business_entity_id, версию схемы Алерт на events_duplicate_with_side_effect_total > 0 почти всегда оправдан: это уже инцидент или состояние перед ним. SQL-инвариант

SELECT idempotency_key, COUNT(*) AS effects
FROM payment_charges
WHERE created_at > now() - interval '10 minutes'
GROUP BY idempotency_key
HAVING COUNT(*) > 1;

Смотрите таблицу эффектов, а не входящих сообщений: событие может повторяться, эффект - нет. В regression и CI/CD quality gates добавляйте replay after TTL, timeout retry с тем же ключом, restart consumer-а до commit offset и payload conflict. Вывод: Идемпотентность нужно тестировать как production-инвариант с логами, метриками и безопасными дублями, иначе дефект проявится уже в деньгах, статусах или данных клиента.