QA-Логия

⁣Shadow testing асинхронных консьюмеров на прод-трафике: как сверять побочные эффекты без риска для данных Shadow testing нужен, когда новый consumer проверяется на реальных сообщениях, но не должен менять prod. Частая ошибка - считать успехом no exception, не сравнивая реальные side effects. Суть паттерна Боевой consumer обрабатывает сообщение как обычно, shadow consumer получает копию и пишет “предполагаемые действия” в изолированный sink: * shadow-таблицы * отдельный topic * audit storage * recorder вместо БД, event bus и внешних клиентов Главное правило: не “мы не будем писать в prod”, а технически не можем - отдельные credentials, network policy, запрет write-доступа. Что сравнивать Comparator должен сверять не только финальный статус, а модель побочных эффектов: * созданные/обновленные записи * downstream events и HTTP/gRPC вызовы * суммы, комиссии, даты, reason codes * idempotency key, retry/dedup/DLQ поведение * отсутствие лишних действий Перед сравнением нормализуйте timestamp, request_id, UUID, порядок JSON-полей, метаданные брокера и версии схем, если они не меняют бизнес-смысл. Иначе получите шум вместо полезных расхождений. Production guardrails Для Kafka shadow обычно запускают в отдельной consumer group; для SQS/RabbitMQ часто нужен fan-out или shadow-очередь, иначе consumers начнут конкурировать. Практический минимум: * feature flag для отключения * sampling и rate limit * TTL для shadow-данных * маркировка shadow=true * запрет реальных платежей, email, SMS, delivery, CRM * dashboard по diff, а не падение prod-flow Trade-off: больше инфраструктуры и поддержки recorder’ов, зато быстрее feedback loop на реальном трафике и ниже риск релиза async-логики. Вывод: Shadow testing полезен только тогда, когда побочные эффекты измеряются инженерно, а риск для prod-данных исключен архитектурно.