QA-Логия

Read-after-write consistency в продакшене: пробы для обнаружения stale reads после релиза После релиза пользователь может успешно изменить данные, сразу перечитать их и увидеть старое значение. Частая ошибка QA и разработчиков - проверять только 200 OK на запись, не валидируя реальный read path в production. Где ломается контракт Типичный сценарий: * PATCH /profile - имя изменено на Alice-123 * GET /profile - вернулось старое имя * через 1-5 секунд данные стали актуальными Причины не всегда в БД: * чтение из реплики с лагом * stale cache * read/write split в ORM или gateway * async-проекция в read model * CDN/API cache * неверная инвалидация * eventual consistency без явного UX/SLA Production probe Синтетический клиент в проде меняет безопасную тестовую сущность, затем читает ее через тот же публичный путь, что и пользователь.

value = "probe-" + uuid()
PATCH /profile/probe-1 {displayName: value}

deadline = now() + 3s

while now() < deadline:
    data = GET /profile/probe-1
    if data.displayName == value:
        emit("raw_latency_ms")
        break
else:
    alert("stale_read_detected")

Важно проверять не только “когда-нибудь стало видно”, а контракт: * видно сразу или в течение N мс * видно из нужного региона * видно через public/mobile/BFF/API path * видно после обновления read model * значение не прыгает new -> old -> new Последнее - признак немонотонного чтения, которое для пользователя выглядит как потеря изменений. Как проектировать пробы Практические правила: * используйте отдельного synthetic user или tenant * пишите уникальное значение: UUID или timestamp * проверяйте все критичные read path: direct API, BFF, GraphQL, mobile endpoint, search/read model * логируйте version, timestamp, region, shard, trace_id * разделяйте SLO и alert: если допускается 2 секунды eventual consistency, не алертите на 300 мс, но стройте метрику latency Вывод: Read-after-write пробы превращают редкие stale reads после релиза из “иногда что-то не так” в расследуемый сигнал с понятным риском, стоимостью и SLA.