Формулировка «ретраим 5xx, не ретраим 4xx» закрывает только половину ответа, и на ней ловят. Вторая половина касается операции, а не ошибки. Ошибка говорит «может, повезёт со второй попытки», идемпотентность говорит «второй попыткой я ничего не сломаю». Без второго условия ретрай на таймауте списания превращается в двойное списание, и никакой backoff тут не поможет.

Ретраить можно

• Сетевые сбои до отправки запроса: ECONNREFUSED, EHOSTUNREACH, ошибка DNS, отказ на этапе dial. Исход здесь однозначный: сервер запрос точно не видел, так что повтор безопасен даже для неидемпотентной операции.
• Явные сигналы «попробуй позже»: HTTP 429, 503, 502, 504, gRPC UNAVAILABLE, RESOURCE_EXHAUSTED. Если пришёл Retry-After или RetryInfo - паузу назначает сервер, а не твой backoff.
• Транзиентные ошибки БД: в Postgres это класс 40xxx - 40001 serialization_failure и 40P01 deadlock_detected. Транзакция откатилась целиком, побочных эффектов нет, и для SERIALIZABLE и REPEATABLE READ повтор считается штатным сценарием.
• Гонка на выборе лидера / смена мастера: read-only transaction после failover, MOVED в Redis Cluster, NotLeader в Kafka. Повтор попадёт уже на нового лидера.
• Оптимистические конфликты: UPDATE ... WHERE version = ? вернул 0 строк. Здесь ретрай обязан перечитать данные и пересчитать, а не повторить тот же UPDATE.

Ретраить нельзя

• Детерминированные ошибки: 400, 401, 403, 404, 422, невалидный JSON, нарушение бизнес-правила. Повтор даст ровно тот же ответ и впустую потратит время пользователя и ресурсы зависимости.
• Неидемпотентная запись с неопределённым исходом. Таймаут на POST /payments без ключа идемпотентности: ты не знаешь, прошло списание или нет. Ретраить тут значит играть в лотерею деньгами клиента.
• Отменённый контекст. context.Canceled означает, что клиент ушёл и ответ уже некому получать; DeadlineExceeded - что бюджет исчерпан. Обе ошибки говорят: прекращай, а не повторяй.
• Открытый circuit breaker. Брейкер отказывает мгновенно, значит серия ретраев сгорит за микросекунды и вернёт ту же ошибку. Открытый брейкер означает одно: уходи в fallback.
• Ошибка после частичного эффекта. Типичный случай: batch-вставка, где половина строк прошла, а потом соединение отвалилось. Пока не сделаешь операцию атомарной или идемпотентной, ретраить нечего.

Серая зона: ambiguous outcome

Интереснее всего класс с неопределённым исходом: таймаут или разрыв соединения уже после отправки запроса. Клиент не знает, дошёл ли запрос, выполнился ли он и просто потерялся ответ. На собесе правильный разбор звучит так: «такая ошибка транзиентная, но ретраить её можно только при идемпотентной операции; если операция неидемпотентна - вариантов два: сделать её идемпотентной ключом идемпотентности либо не ретраить и вернуть пользователю честное статус неизвестен, проверьте позже».

// Классификатор - единственное место, где живёт знание «что ретраибельно».
// Разносить эти проверки по коду нельзя: они разъедутся в первый же месяц.
type Outcome int

const (
    Fatal      Outcome = iota // повтор бессмыслен
    Transient                 // запрос точно не выполнился - повтор безопасен всегда
    Ambiguous                 // исход неизвестен - повтор, только если операция идемпотентна
)

func classify(err error) Outcome {
    switch {
    case err == nil:
        return Fatal
    // Уход клиента и исчерпанный бюджет - это не сбой зависимости.
    case errors.Is(err, context.Canceled), errors.Is(err, context.DeadlineExceeded):
        return Fatal
    // Брейкер открыт: ретрай только сожжёт попытки.
    case errors.Is(err, ErrOpen), errors.Is(err, ErrOverloaded):
        return Fatal
    }

    // Не доехали до сервера - исход однозначный.
    var de *net.DNSError
    if errors.As(err, &de) || errors.Is(err, syscall.ECONNREFUSED) ||
        errors.Is(err, syscall.EHOSTUNREACH) {
        return Transient
    }

    var pg *pgconn.PgError
    if errors.As(err, &pg) {
        switch pg.Code {
        case "40001", "40P01":     // serialization_failure, deadlock_detected
            return Transient       // транзакция откатилась целиком
        case "23505":              // unique_violation - это уже дедупликация, а не сбой
            return Fatal
        }
        return Fatal
    }

    var he *HTTPError
    if errors.As(err, &he) {
        switch he.Code {
        case 408, 425, 429, 503:
            return Transient       // запрос не обработан - повтор безопасен
        case 500, 502, 504:
            return Ambiguous       // сервер мог успеть выполнить операцию
        }
        return Fatal               // 4xx - ошибка запроса, повтор не поможет
    }

    // Таймаут или обрыв на середине - самый опасный случай.
    var ne net.Error
    if errors.As(err, &ne) && ne.Timeout() {
        return Ambiguous
    }
    if errors.Is(err, syscall.ECONNRESET) || errors.Is(err, io.ErrUnexpectedEOF) {
        return Ambiguous
    }
    return Fatal                   // неизвестное по умолчанию не ретраим
}

// Решение зависит от пары «класс ошибки + свойство операции».
func shouldRetry(err error, idempotent bool) bool {
    switch classify(err) {
    case Transient:
        return true
    case Ambiguous:
        return idempotent
    default:
        return false
    }
}

Почему одного backoff мало

Зависимость упала или перегрузилась - значит, все клиенты получили ошибку почти одновременно. Дальше каждый честно ждёт base * 2^attempt. Формула детерминированная, стартовая точка у всех общая, поэтому вторая попытка у всей тысячи придётся на один и тот же момент. Получается thundering herd: ровно в секунду восстановления зависимость получает пиковый залп и падает снова. Такой цикл держится часами - это классический metastable failure: исходной причины давно нет, а система из ямы не выходит, потому что её держит собственный ретрай-трафик.

Jitter добавляет в паузу случайность и размазывает попытки по интервалу: вместо пика зависимость получает ровный поток, который способна переварить. Коротко: backoff уменьшает частоту повторов, jitter уменьшает их корреляцию. Нужны оба.

Retry с уважением к context

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

package retry

import (
    "context"
    "errors"
    "math/rand/v2"   // Go 1.22+: глобальный генератор без блокировок и без ручного Seed
    "time"
)

type Policy struct {
    MaxAttempts    int           // всего попыток, включая первую
    Base           time.Duration // 100ms
    Cap            time.Duration // 5s - потолок одной паузы
    PerAttempt     time.Duration // таймаут одной попытки; 0 - без своего таймаута
    Budget         time.Duration // потолок на всю серию; 0 - ограничивает только ctx
}

// Классификатор отвечает сразу на два вопроса: повторять ли,
// и не назвал ли сервер паузу сам (Retry-After, gRPC RetryInfo).
type Classifier func(err error) (retry bool, after time.Duration)

func Do(ctx context.Context, p Policy, cls Classifier, op func(context.Context) error) error {
    if p.MaxAttempts <= 0 { p.MaxAttempts = 3 }
    if p.Base <= 0        { p.Base = 100 * time.Millisecond }
    if p.Cap <= 0         { p.Cap = 5 * time.Second }

    if p.Budget > 0 {
        var cancel context.CancelFunc
        ctx, cancel = context.WithTimeout(ctx, p.Budget)
        defer cancel()   // обязателен: иначе течёт таймер до конца родительского ctx
    }

    var last error
    for attempt := 0; attempt < p.MaxAttempts; attempt++ {
        // Не ходим в сеть с уже истёкшим дедлайном: соединение зависимости
        // дороже, чем наша попытка «а вдруг успеем».
        if err := ctx.Err(); err != nil {
            return errors.Join(last, err)
        }

        last = attemptOnce(ctx, p.PerAttempt, op)
        if last == nil {
            return nil
        }

        // Отмена родительского контекста - не транзиентная ошибка: клиент ушёл.
        // Проверяем до классификатора, иначе таймаут попытки спутаем с отменой запроса.
        if ctx.Err() != nil {
            return errors.Join(last, ctx.Err())
        }

        retry, after := cls(last)
        if !retry || attempt == p.MaxAttempts-1 {
            return last
        }

        delay := after                                   // сервер назвал паузу - уважаем
        if delay <= 0 {
            delay = fullJitter(p.Base, p.Cap, attempt)
        }
        if err := sleepCtx(ctx, delay); err != nil {
            return errors.Join(last, err)
        }
    }
    return last
}

// Своя граница времени на каждую попытку. Без неё одна зависшая
// попытка съедает весь бюджет, и ретраев фактически не происходит.
func attemptOnce(ctx context.Context, per time.Duration, op func(context.Context) error) error {
    if per <= 0 {
        return op(ctx)
    }
    actx, cancel := context.WithTimeout(ctx, per)
    defer cancel()
    return op(actx)
}

func sleepCtx(ctx context.Context, d time.Duration) error {
    // Спать дольше, чем осталось до дедлайна, незачем: лучше вернуть ошибку
    // сразу, чем разбудить таймер в уже мёртвый запрос.
    if dl, ok := ctx.Deadline(); ok && time.Until(dl) <= d {
        return context.DeadlineExceeded
    }
    t := time.NewTimer(d)
    defer t.Stop()          // до Go 1.23 неостановленный таймер живёт до срабатывания
    select {
    case <-ctx.Done():
        return ctx.Err()
    case <-t.C:
        return nil
    }
}

func fullJitter(base, capD time.Duration, attempt int) time.Duration {
    backoff := base << attempt                  // base * 2^attempt
    if backoff > capD || backoff <= 0 {         // <=0 - защита от переполнения int64
        backoff = capD
    }
    return time.Duration(rand.Int64N(int64(backoff)) + 1)
}

Как это вызывается

policy := retry.Policy{
    MaxAttempts: 4,
    Base:        50 * time.Millisecond,
    Cap:         1 * time.Second,
    PerAttempt:  400 * time.Millisecond,   // одна попытка
    Budget:      2 * time.Second,          // вся серия
}

var receipt *Receipt
err := retry.Do(ctx, policy, HTTPClassifier, func(ctx context.Context) error {
    req = req.WithIdempotencyKey(key)      // ключ один на всю серию, а не на попытку
    r, err := client.Charge(ctx, req)
    receipt = r
    return err
})

От чего он спасает на самом деле

Упавшая зависимость опасна не столько ошибками, сколько ожиданием. Пока вызов висит на таймауте, он держит горутину, соединение из пула, слот в семафоре и кусок бюджета запроса. При 200 RPS и таймауте 30 секунд к моменту первого отказа у тебя уже 6000 горутин в ожидании и пустой пул HTTP-соединений. Дальше начинают отваливаться эндпоинты, которые к этой зависимости вообще не ходят. Так выглядит каскадный отказ. Брейкер разрывает цепочку: вместо 30 секунд ожидания вызов возвращает ошибку за микросекунды, ресурсы остаются свободными.

Второй эффект достаётся самой зависимости. Сервис, который лежит под нагрузкой, не встанет, пока в него продолжают долбить. Открытый брейкер снимает трафик, и у зависимости появляется окно на восстановление. Здесь «перестать пытаться» полезнее для обеих сторон.

Три состояния

// Ядро автомата - вход и отчёт. Полная реализация со счётчиками
// разбиралась выше; здесь важна логика переходов.
func (b *Breaker) allow() error {
    b.mu.Lock()
    defer b.mu.Unlock()

    switch b.state {
    case Closed:
        return nil
    case Open:
        if time.Since(b.openedAt) < b.cooldown {
            return ErrOpen                       // отказ за наносекунды, в сеть не идём
        }
        b.state, b.probes, b.successes = HalfOpen, 0, 0
        fallthrough
    case HalfOpen:
        if b.probes >= b.maxProbes {             // пробных - единицы, не весь трафик
            return ErrTooManyProbes
        }
        b.probes++
        return nil
    }
    return nil
}

// Обёртка вызова. Тонкое место - что считать отказом.
func (b *Breaker) Do(ctx context.Context, fn func(context.Context) error) error {
    if err := b.allow(); err != nil {
        return err                               // fallback решает вызывающий
    }
    err := fn(ctx)
    b.report(err, isSuccess(err))
    return err
}

func isSuccess(err error) bool {
    if err == nil {
        return true
    }
    // Уход клиента - не вина зависимости, иначе массовая отмена запросов
    // сама откроет брейкер.
    if errors.Is(err, context.Canceled) {
        return true
    }
    // 4xx - ошибка запроса, а не сбой зависимости.
    var he *HTTPError
    if errors.As(err, &he) && he.Code < 500 && he.Code != 429 {
        return true
    }
    return false
}

Сценарий: внешний платёжный API лёг

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

Почему нельзя без таймаута

TCP сам по себе не заметит зависшего собеседника: если сервер принял соединение и молчит, клиент будет ждать бесконечно - не «долго», а именно бесконечно. Каждый такой вызов держит горутину (2 КБ стека на старте, обычно больше), соединение из пула, слот в семафоре и открытый файловый дескриптор. При 200 RPS и часовой недоступности набегают сотни тысяч горутин: сервис умирает не от ошибок зависимости, а от собственной памяти. Таймаут превращает неопределённое ожидание в предсказуемую ошибку, а предсказуемую ошибку уже можно обработать: ретраем, брейкером, деградацией.

Бюджет запроса и каскад

Таймаут на вызов необходим, но его недостаточно. Если каждый слой ставит свой таймаут «на глаз», арифметика ломается. У запроса бюджет 3 секунды, а внутри вызов с таймаутом 5 секунд и тремя ретраями: его таймаут не сработает ни разу, раньше всегда успеет внешний дедлайн, и внутренние настройки ничего не значат. Правильная модель называется бюджет: верхнюю границу задаёт вход (ingress, gateway), а дальше каждый слой берёт строго меньше, чем ему осталось, и оставляет резерв на обработку результата и запись ответа.

// В Go бюджет уже встроен в context: WithTimeout не добавляет времени,
// если дедлайн родителя ближе - побеждает родитель. Глубокий вызов
// физически не может пережить запрос.
func childCtx(ctx context.Context, want, reserve time.Duration) (context.Context, context.CancelFunc) {
    dl, ok := ctx.Deadline()
    if !ok {
        return context.WithTimeout(ctx, want)     // бюджета сверху нет - берём свой
    }
    left := time.Until(dl) - reserve
    if left <= 0 {
        // Времени не осталось: идти в сеть бессмысленно - только займём
        // соединение у зависимости, которой и так тяжело. Отказываем сразу.
        c, cancel := context.WithDeadline(ctx, time.Now())
        return c, cancel
    }
    if left < want {
        want = left
    }
    return context.WithTimeout(ctx, want)
}

// Пример арифметики: ingress даёт 3 с.
//   auth      200 мс
//   профиль   400 мс
//   платёж  3 попытки по 600 мс + backoff ~200 мс = 2000 мс
//   резерв    100 мс на сериализацию и запись ответа
//   итого    2700 мс < 3000 мс - влезает
func Handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()      // дедлайн сюда приносит http.TimeoutHandler или клиент

    aCtx, cancel := childCtx(ctx, 200*time.Millisecond, 0)
    defer cancel()
    user, err := auth.Verify(aCtx, r.Header.Get("Authorization"))
    if err != nil { writeErr(w, err); return }

    pCtx, cancel2 := childCtx(ctx, 2*time.Second, 100*time.Millisecond)
    defer cancel2()
    receipt, err := billing.Charge(pCtx, user.ID)   // внутри ретраи и брейкер
    if err != nil { writeErr(w, err); return }

    writeJSON(w, receipt)
}

Лестница деградации

Вопрос не сводится к «есть fallback или нет»: уровней несколько, и выбирают их осознанно. На собесе полезно перечислить уровни по убыванию качества ответа.

1. Протухший кэш - отдаём последнее известное значение и помечаем его stale (stale-while-revalidate). Годится для медленно меняющихся данных: каталог, курсы, настройки, фичефлаги.
2. Дефолт, то есть заранее посчитанная константа или неперсональный вариант. В рекомендациях, баннерах, ранжировании «топ популярного» лучше пустого блока.
3. Урезанный ответ: 200 без части полей плюс признак partial: true. Карточка товара без блока «с этим покупают» вполне годится, а 500 нет.
4. Можно отложить работу: положить в очередь или outbox и ответить 202 Accepted. Так делают там, где операция допускает асинхронность: письма, бонусы, индексация.
5. Read-only режим - запись отключена, чтение идёт с реплики. При отказе мастера это заметно лучше полного 503.
6. И последний уровень, честный отказ: явная ошибка с понятным текстом и Retry-After. Для денег, прав доступа и целостности данных это единственный корректный вариант: выдуманный ответ там означает соврать.

// Второй результат говорит вызывающему, что ответ деградировал.
// Возвращать «как будто всё хорошо» - это тихая поломка.
func (s *Service) Recommendations(ctx context.Context, userID int64) (Recs, bool) {
    // У некритичной зависимости - свой короткий таймаут, чтобы она
    // не съедала бюджет основного ответа.
    ctx, cancel := childCtx(ctx, 150*time.Millisecond, 20*time.Millisecond)
    defer cancel()

    recs, err := s.mlCB.Do(ctx, func(ctx context.Context) (Recs, error) {
        return s.ml.Get(ctx, userID)
    })
    if err == nil {
        s.cache.Set(userID, recs, 10*time.Minute)
        return recs, false
    }

    // Каждая деградация обязана быть видна. Без метрики сервис будет
    // месяцами отдавать дефолты, и никто об этом не узнает.
    degraded.WithLabelValues("recs", reasonOf(err)).Inc()
    s.log.WarnContext(ctx, "recommendations degraded", "err", err, "user", userID)

    if stale, ok := s.cache.GetStale(userID); ok {   // допускаем просроченное
        return stale, true
    }
    return s.topPopular(), true                      // последний рубеж
}

// В HTTP-слое деградация становится видимой снаружи.
func (h *Handler) Feed(w http.ResponseWriter, r *http.Request) {
    recs, degraded := h.svc.Recommendations(r.Context(), userID(r))
    if degraded {
        w.Header().Set("X-Degraded", "recommendations")
        w.Header().Set("Cache-Control", "no-store")   // не кэшируем ухудшенный ответ
    }
    writeJSON(w, FeedResponse{Recs: recs, Partial: degraded})
}

Композитный ответ: параллельные источники с разной критичностью

func (s *Service) ProductPage(ctx context.Context, id int64) (Page, error) {
    var page Page
    g, gctx := errgroup.WithContext(ctx)

    // Критичный источник: его отказ - отказ всей ручки.
    g.Go(func() error {
        p, err := s.catalog.Get(gctx, id)
        page.Product = p
        return err                     // вернётся из g.Wait; блоки на ctx её не заметят
    })

    // Некритичные: ошибку не возвращаем в группу, иначе один упавший
    // блок отменит контекст и убьёт весь ответ.
    // Флаги деградации - у каждого свой: общий page.Partial из двух горутин -
    // это гонка.
    var recsDeg, reviewsDeg bool
    g.Go(func() error {
        recs, deg := s.Recommendations(ctx, id)   // именно ctx, не gctx
        page.Recs, recsDeg = recs, deg
        return nil
    })
    g.Go(func() error {
        rv, err := s.reviews.Top(ctx, id)
        if err != nil {
            degraded.WithLabelValues("reviews", reasonOf(err)).Inc()
            reviewsDeg = true
            return nil                 // блок отзывов просто не покажем
        }
        page.Reviews = rv
        return nil
    })

    if err := g.Wait(); err != nil {
        return Page{}, err             // упал критичный источник
    }
    page.Partial = recsDeg || reviewsDeg
    return page, nil
}

Почему они не противоречат друг другу

Медленный отказ собирает худшее из обоих миров: пользователь всё равно не получит ответа, но ресурсы будут заняты до конца таймаута, а ретраи придут уже на исчерпанный пул. Fault-tolerance строится ровно из быстрых отказов: брейкер даёт мгновенный ErrOpen, и только поэтому у вызывающего остаются время и ресурсы уйти в fallback. Если внизу «терпеливо ждём», наверху терпеть уже нечем.

Fail-fast как защита от перегрузки

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

// Приёмный контроль: три быстрых проверки до любой полезной работы.
func (s *Server) admit(ctx context.Context) error {
    // 1. Клиент уже не ждёт - работать не для кого.
    if err := ctx.Err(); err != nil {
        return err
    }
    // 2. Бюджета не хватит даже на нормальный путь - лучше отказать сразу.
    if dl, ok := ctx.Deadline(); ok && time.Until(dl) < s.minWorkTime {
        sheddedTotal.WithLabelValues("no_budget").Inc()
        return ErrNoTimeBudget          // 503 + Retry-After
    }
    // 3. Перегрузка: очередь длиннее, чем мы разгребём за отведённое время.
    if s.inflight.Load() > s.maxInflight {
        sheddedTotal.WithLabelValues("overload").Inc()
        return ErrOverloaded            // 429 или 503
    }
    return nil
}

// Bulkhead: ограничить параллелизм на каждую зависимость отдельно,
// чтобы одна медленная не съела все горутины и соединения.
type Bulkhead struct{ sem chan struct{} }

func (b *Bulkhead) Do(ctx context.Context, fn func(context.Context) error) error {
    select {
    case b.sem <- struct{}{}:
    case <-ctx.Done():
        return ctx.Err()
    default:
        // Очередь не растим: ожидание слота - это отложенный отказ.
        return ErrOverloaded
    }
    defer func() { <-b.sem }()
    return fn(ctx)
}

Почему без неё ретрай опасен

Сеть не даёт узнать, что произошло на другой стороне. Таймаут на POST /payments означает одно из трёх: запрос не дошёл; запрос выполнился, а ответ потерялся; запрос выполняется прямо сейчас. Различить эти случаи снаружи нельзя в принципе - это и есть ambiguous outcome. С идемпотентностью различать их и не нужно: повтор либо выполнит операцию (если первая не прошла), либо вернёт результат первой, ничего не выполняя.

Отсюда же следует, что «ровно один раз» в распределённой системе недостижим на уровне доставки. Достижимо другое: at-least-once доставка плюс идемпотентный обработчик дают ровно один эффект. Это стандартный ответ и по ретраям, и по Kafka с RabbitMQ.

Пять способов сделать операцию идемпотентной

-- Дедупликация вставки: повтор не создаёт вторую запись и не падает.
INSERT INTO payments (order_id, amount, status)
VALUES ($1, $2, 'pending')
ON CONFLICT (order_id) DO NOTHING
RETURNING id;
-- Пустой результат = запись уже была. Это не ошибка, а штатная ветка:
-- читаем существующую строку и возвращаем её как результат.

-- Inbox: факт обработки и бизнес-эффект фиксируются одной транзакцией.
BEGIN;
  INSERT INTO processed_messages (message_id) VALUES ($1);  -- PK, повтор упадёт 23505
  UPDATE accounts SET balance = balance - $2 WHERE id = $3;
COMMIT;
-- Если вторая команда упала - откатится и первая, сообщение приедет снова.
-- Если сообщение дубль - упадёт первая, транзакция откатится, эффекта нет.

// Обработчик с ключом идемпотентности. Порядок шагов важен:
// сначала атомарно занимаем ключ, только потом делаем работу.
func (s *Service) CreatePayment(ctx context.Context, key string, req Request) (Response, error) {
    if key == "" {
        return Response{}, ErrIdempotencyKeyRequired    // 400
    }
    hash := sha256.Sum256(req.Canonical())

    // 1. Гонку решает сама БД: выигрывает ровно один INSERT.
    claimed, err := s.repo.ClaimKey(ctx, key, "POST /payments", hash[:])
    if err != nil {
        return Response{}, err
    }
    if !claimed {
        rec, err := s.repo.LoadKey(ctx, key)
        if err != nil {
            return Response{}, err
        }
        // 2. Тот же ключ с другим телом - баг клиента, а не повтор.
        if !bytes.Equal(rec.RequestHash, hash[:]) {
            return Response{}, ErrIdempotencyKeyReuse   // 422
        }
        // 3. Первый запрос ещё в работе - параллельно не выполняем.
        if rec.State == StateInProgress {
            return Response{}, ErrInProgress            // 409 + Retry-After: 1
        }
        return rec.Response, nil                        // 4. Отдаём сохранённый ответ
    }

    resp, err := s.charge(ctx, req)
    if err != nil {
        // Деньги точно не списаны - отпускаем ключ, и повтор пройдёт заново:
        // иначе ключ навсегда залипнет в in_progress. Исход неизвестен
        // (таймаут после отправки) - не отпускаем: повтор может списать
        // второй раз, такой ключ ждёт сверки с платёжкой.
        if !errors.Is(err, ErrOutcomeUnknown) {
            _ = s.repo.ReleaseKey(ctx, key)
        }
        return Response{}, err
    }

    // 5. Сохраняем ответ под ключом: повтор получит его, а не второе списание.
    if err := s.repo.CompleteKey(ctx, key, resp); err != nil {
        return Response{}, err
    }
    return resp, nil
}