Архитектура бэкенда
Идемпотентность и retry: тест на воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт восстанови полный ответ по памяти, прежде чем открыть модельный — именно усилие вытащить механизм обратно делает так, что он держится под давлением инцидента.
Восстанови хребет юнита, не подглядывая: почему exactly-once — иллюзия, машина ключа из четырёх состояний, full jitter и retry budget, композиция outbox + inbox, фикс конкурентности и наблюдаемость, которая превращает веру в доказательство.
- 01Почему exactly-once доставка — иллюзия и как юнит вместо этого даёт effectively-once?
- 02Пройди четыре состояния, в которые сервер разрешает Idempotency-Key, с кодом статуса для каждого.
- 03Почему request fingerprint важен наряду с ключом и что молча ломается без него?
- 04Дай формулу full-jitter backoff, объясни, почему jitter не подлежит обсуждению, и скажи, почему пер-запросного cap на retry недостаточно.
- 05Почему любой дизайн «записать БД, потом опубликовать в broker» ломается и как outbox + inbox это чинят?
- 06Два конкурентных запроса с одним idempotency key. Почему SELECT-потом-INSERT небезопасен и что за production-хранилище?
Если ты восстановил каждый ответ — ты держишь хребет юнита: exactly-once это иллюзия, поэтому ты строишь effectively-once из at-least-once плюс dedup; один ключ на операцию разрешается в new / 409 / replay / 422, а fingerprint защищает от тихой потери; retry используют full jitter, уважают Retry-After, делают retry только на 5xx и живут под общим retry budget; dual-write закрывается атомарностью outbox плюс at-least-once relay плюс идемпотентным inbox; конкурентное создание ключа становится атомарным через ON CONFLICT DO NOTHING RETURNING; а durable-хранилище должно пережить сбой, потому что потерянный ключ — это двойное списание.