25. Практические задачи

«В теории нет никакой разницы между теорией и практикой. А на практике — есть».
— Ян ван де Снепшеут

1. Как реализовать LRU кэш?
2. Как реализовать rate limiter?
3. Как реализовать worker pool?
4. Как реализовать потокобезопасную очередь?
5. Как реализовать механизм повторных попыток (retry mechanism)?
6. Как реализовать конвейер (pipeline)?
7. Как реализовать паттерн «издатель-подписчик» (pub/sub)?
8. Как реализовать барьер (barrier)?
9. Как реализовать семафор?
10. Как реализовать ленивую инициализацию (singleton)?
11. Как реализовать шаблон «строитель» (builder)?
12. Как реализовать шаблон «фабрика» (factory)?
13. Как реализовать шаблон «декоратор»?
14. Как реализовать шаблон «команда» (command)?
15. Как реализовать шаблон «стратегия» (strategy)?
16. Как реализовать шаблон «адаптер» (adapter)?
17. Как реализовать graceful shutdown?
18. Как реализовать health check?
19. Как реализовать circuit breaker?
20. Как реализовать bulkhead?
21. Как реализовать feature flag?
22. Как реализовать graceful degradation?
23. Как реализовать дедупликацию сообщений?
24. Как реализовать saga компенсацию?
25. Как реализовать двухфазный коммит (2PC)?
26. Как реализовать распределенный таймер (distributed timer)?
27. Как реализовать систему отложенных задач (delayed queue)?
28. Как реализовать поиск по префиксу (prefix search)?
29. Как реализовать топ-К элементов?
30. Как реализовать согласованное хеширование (consistent hashing)?
31. Как реализовать gossiping протокол для обнаружения узлов кластера?
32. Как реализовать singleflight (x/sync/singleflight)?
33. Как реализовать журналирование изменений (audit log)?
34. Как реализовать параллельный обход дерева?
35. Как реализовать конкурентный map-filter-reduce?
36. Как реализовать merge sort слиянием из нескольких файлов?
37. Как реализовать потоковую обработку большого CSV/JSON файла?
38. Как реализовать идемпотентный REST API эндпоинт?
39. Как реализовать систему a/b тестирования на уровне API?
40. Как реализовать «пессимистичную» и «оптимистичную» блокировку в распределенной системе?
41. Как реализовать throttling на основе приоритетов запросов?
42. Как реализовать "sharding" на уровне приложения для распределенного кэша?
43. Как реализовать "lease" механизм для распределенной блокировки?
44. Как реализовать "geo-redundant" high availability?
45. Как реализовать "graceful restart" для HTTP сервера без потери соединений?
46. Как реализовать "dynamic configuration" без перезагрузки приложения?
47. Как реализовать "eventual consistency" в распределенном key-value хранилище?

flowchart TD
    classDef entry   fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef process fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef accent  fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    classDef warning fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef success fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc

    Task["Типология практических задач на Go-собеседовании"]:::entry

    Task --> C1["1. Concurrency & Синхронизация"]:::accent
    C1 --> E1["Worker Pool, Rate Limiter, Fan-in/Fan-out, Pipeline, Singleflight"]:::process

    Task --> C2["2. Структуры данных и In-Memory"]:::accent
    C2 --> E2["LRU Cache, Thread-safe Queue, Prefix Tree, Priority Throttling"]:::process

    Task --> C3["3. Паттерны надёжности (Reliability)"]:::warning
    C3 --> E3["Graceful Shutdown, Circuit Breaker, Retry с экспоненциальным backoff"]:::process

    Task --> C4["4. Потоковый I/O и REST API"]:::success
    C4 --> E4["Обработка огромных CSV/JSON, Idempotency-Key, Batching"]:::process
  

flowchart LR
    classDef entry   fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef process fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef accent  fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    classDef warning fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef success fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc

    T1["00-05 мин: Декомпозиция и вопросы"]:::entry --> T2["05-15 мин: Базовый каркас и типы"]:::process
    T2 --> T3["15-30 мин: Основная логика"]:::accent
    T3 --> T4["30-40 мин: Граничные кейсы и тесты"]:::warning
    T4 --> T5["40-45 мин: Оценка Big-O и выводы"]:::success
  

Как реализовать LRU кэш?

Краткий ответ (30–60 секунд)

LRU-кэш вытесняет самый давно неиспользуемый элемент. Реализуется через двусвязный список (очередь использования) и хеш-таблицу для O(1) доступа по ключу. При Get перемещаем узел в голову списка; при Put добавляем в голову и, если ёмкость превышена, удаляем хвост. В Go используем container/list и map, с обязательной защитой мьютексом, либо специализированные библиотеки вроде hashicorp/golang-lru.

Развёрнутый ответ

LRU (Least Recently Used) — политика вытеснения, оптимальная для многих рабочих нагрузок с временной локальностью. Необходимо обеспечить:

• O(1) доступ по ключу — даёт map[K]*list.Element.
• O(1) обновление порядка использования — двусвязный список позволяет вырезать узел и вставить в голову без обхода.
• Атомарность операций — в многопоточном окружении весь кэш защищается sync.Mutex или sync.RWMutex (если операций чтения значительно больше).

Пример каркаса:

type LRU[K comparable, V any] struct {
    cap   int
    mu    sync.Mutex
    list  *list.List
    items map[K]*list.Element
}

type entry[K comparable, V any] struct {
    key K
    val V
}

func (l *LRU[K, V]) Get(key K) (V, bool) {
    l.mu.Lock()
    defer l.mu.Unlock()
    if el, ok := l.items[key]; ok {
        l.list.MoveToFront(el)
        return el.Value.(*entry[K, V]).val, true
    }
    var zero V
    return zero, false
}

func (l *LRU[K, V]) Put(key K, val V) {
    l.mu.Lock()
    defer l.mu.Unlock()
    if el, ok := l.items[key]; ok {
        el.Value.(*entry[K, V]).val = val
        l.list.MoveToFront(el)
        return
    }
    if l.list.Len() >= l.cap {
        oldest := l.list.Back()
        if oldest != nil {
            l.list.Remove(oldest)
            delete(l.items, oldest.Value.(*entry[K, V]).key)
        }
    }
    e := &entry[K, V]{key, val}
    el := l.list.PushFront(e)
    l.items[key] = el
}

Использование дженериков (Go 1.18+) устраняет дублирование кода под типы. При высоких требованиях к производительности можно встроить список прямо в структуру элемента, чтобы избежать аллокаций list.Element и интерфейсного преобразования, но это усложняет код.

Под капотом (internals)

• container/list в Go — классический двусвязный список, каждый элемент выделен отдельно. При частых вытеснениях возникает мусор, но GC Go 1.22+ с оптимизациями справляется за счёт быстрой утилизации маленьких объектов.
• При блокировке всего кэша мьютексом на высоконагруженных системах можно использовать шардирование: например, 256 отдельных LRU-сегментов, хешируя ключ в сегмент. Это снижает контенцию, жертвуя строгим глобальным LRU (получается приближённый LRU).
• Альтернатива: ring buffer с временными метками и бинарной кучей — O(log N), но меньше аллокаций. Однако идиоматичный Go-подход — именно map+list.

Типичные ошибки кандидатов

1. Забывают удалять ключ из map при вытеснении: утечка памяти — map бесконечно растёт, хотя элементы из списка удалены.
   Почему неправильно: удаляя list.Remove, узел освобождается, но ссылка в map остаётся, и сборщик мусора не может его убрать, плюс нарушается инвариант размера кэша.
   Исправление: явно вызвать delete(l.items, key) сразу после получения ключа из удаляемого элемента.

2. Не обновляют позицию при повторном Put существующего ключа: логика «обновили значение, но не переместили в голову» ломает LRU — элемент становится «старым», хотя только что использован.
   Почему неправильно: нарушается гарантия порядка вытеснения, горячие ключи могут быть удалены раньше холодных.
   Исправление: для существующего ключа всегда вызывать MoveToFront.

3. Используют sync.Map без списка: пытаются хранить порядок в слайсе или через таймстемпы, теряя O(1). sync.Map сам по себе не поддерживает упорядоченность.
   Почему неправильно: при вытеснении нужно найти наименее свежий элемент — без двусвязного списка это линейное сканирование.
   Исправление: всегда сочетать map и двусвязный список, синхронизацию реализовывать явно.

Возможные дополнительные вопросы интервьюера

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

Что если нужно хранить не частоту, а время последнего доступа с точным TTL?
Это уже Time-aware LRU (TLRU) или использование очереди с приоритетами по времени истечения. Можно совместить с LRU-списком: при Get проверять время жизни, при необходимости удалять протухшие элементы лениво или отдельной горутиной-сборщиком.

Как протестировать корректность политики вытеснения?
Заранее подготовить последовательность операций, моделирующую известные сценарии (например, эталонный след обращений), и сравнивать состояние кэша с эталонной реализацией на Python или на бумаге.

Как реализовать rate limiter?

Краткий ответ (30–60 секунд)

Rate limiter ограничивает количество запросов за промежуток времени. Базовые алгоритмы: Token Bucket (наполняется с постоянной скоростью, запросы потребляют токены) и Leaky Bucket (запросы в очереди, обрабатываются с фиксированной скоростью). В Go удобно использовать time.Ticker и атомарные счётчики либо канал-счётчик. Для распределённых систем токен-бакет реализуют поверх Redis с Lua-скриптами.

Развёрнутый ответ

На практике чаще всего применяют Token Bucket из-за способности пропускать кратковременные всплески. Реализация в памяти:

type TokenBucket struct {
    rate       float64 // токенов в секунду
    burst      int     // максимальный размер ведра
    tokens     float64
    lastUpdate time.Time
    mu         sync.Mutex
}

func (tb *TokenBucket) Allow() bool {
    tb.mu.Lock()
    defer tb.mu.Unlock()
    now := time.Now()
    elapsed := now.Sub(tb.lastUpdate).Seconds()
    tb.tokens += elapsed * tb.rate
    if tb.tokens > float64(tb.burst) {
        tb.tokens = float64(tb.burst)
    }
    tb.lastUpdate = now
    if tb.tokens >= 1 {
        tb.tokens--
        return true
    }
    return false
}

Для высоконагруженных систем важно минимизировать блокировку: атомарный подход с atomic.Int64 и циклом CAS для обновления состояния. Пакет golang.org/x/time/rate реализует именно Token Bucket с возможностью ожидания (Reserve), что удобно для вставки ожидания в середину цепочки обработки.

В распределённом варианте состояние хранится в Redis (SET с NX/PX для фиксации окна или Lua-скрипт для атомарного обновления токенов). Ключ обычно привязывается к идентификатору клиента или IP.

Под капотом (internals)

• Стандартный x/time/rate.Limiter использует внутренние счётчики и виртуальное время (time.Now), синхронизацию через sync.Mutex. Метод Reserve() возвращает объект Reservation, который можно отменить; под капотом происходит вычитание токенов из будущего.
• При использовании канала как ведра (фиксированный размер канала = burst, горутина-наполнитель кладёт токен каждые 1/rate секунд) — это Leaky Bucket. Планировщик Go переключает горутины, поэтому возможна погрешность, но решение крайне простое.
• Для точных интервалов подходит time.Ticker; его фаза может немного дрейфовать, но для рейт-лимитеров это некритично. Важно не накапливать ticker'ы: остановить их при неиспользовании.

Типичные ошибки кандидатов

1. Сброс состояния при каждом запросе (реализация через один time.Ticker на весь сервис): создание нового тикера на каждый запрос — утечка горутин и ресурсов.
   Почему неправильно: time.NewTicker создаёт горутину, бесконечно шлющую в канал; если не остановить, горутины множатся.
   Исправление: использовать глобальный тикер с циклом for range ticker.C либо вычислять интервал дельты времени, как в Token Bucket выше.

2. Гонка при проверке и инкременте в наивном счётчике: if counter < limit { counter++ } без атомарности или мьютекса.
   Почему неправильно: между проверкой и инкрементом другой горутин может войти — результат — превышение лимита.
   Исправление: либо sync.Mutex, либо atomic.CompareAndSwapInt64.

3. Использование time.Sleep для ограничения скорости внутри обработчика: это блокирует всю горутину обработки запроса, снижая пропускную способность.
   Почему неправильно: не расходует ресурсы правильно, при большом количестве запросов лимит не соблюдается точно из-за накопления ожидающих горутин.
   Исправление: явное моделирование токенов или очереди.

Возможные дополнительные вопросы интервьюера

Как реализовать rate limiter с неравномерным распределением нагрузки — например, 1000 запросов в час, но не более 10 в секунду?
Это два вложенных ограничителя: внешний на час с большим burst, внутренний на секунду. Применяются последовательно.

Что делать с синхронизацией времени в распределённом Redis rate limiter?
Использовать монотонное время сервера (Redis использует TIME, но Lua-скрипт получает время Redis). Для точности можно применять строго серверное время, чтобы избежать рассинхрона часов.

Как реализовать честный rate limiter с отдельными корзинами на каждого пользователя, но с общим лимитом?
Разделить глобальный пул токенов; при нехватке добавить очередь с приоритетом или справедливую пропускную способность (max-min fairness). Обычно на практике просто шардируют глобальный лимит равномерно, а для изоляции используют отдельные лимитеры.

Как реализовать worker pool?

Краткий ответ (30–60 секунд)

Worker pool — фиксированное количество горутин-обработчиков, читающих задачи из общего канала. При запуске создаётся N воркеров, слушающих канал chan Task. Отправитель кладёт задания, воркеры конкурентно их разбирают. Завершение — закрытие канала и ожидание через sync.WaitGroup. Это ограничивает параллелизм и позволяет контролировать нагрузку на CPU/IO.

Развёрнутый ответ

Идиоматичная реализация:

type Task struct { ID int; Data string }

func workerPool(numWorkers int, tasks <-chan Task) {
    var wg sync.WaitGroup
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go func(workerID int) {
            defer wg.Done()
            for task := range tasks {
                process(task)
            }
        }(i)
    }
    wg.Wait()
}

Главный принцип — канал объединяет пул и ограничивает очередь. При необходимости ограничить и размер очереди используют буферизированный канал: tasks := make(chan Task, queueSize). Тогда при заполненном буфере отправитель блокируется, реализуя backpressure.

Для пулов с динамическим масштабированием применяют паттерн «semaphore + goroutine»: sem := make(chan struct{}, maxConcurrency) — каждое задание забирает место в семафоре, после обработки освобождает; горутины создаются по необходимости, но число одновременно работающих ограничено.

Стандартный errgroup.Group из golang.org/x/sync/errgroup позволяет управлять группой горутин с ограничением параллелизма через SetLimit(n) (введено в Go 1.22 в x/sync) и пробрасывать первую ошибку.

Под капотом (internals)

• При make(chan Task, N) Go выделяет буфер в куче размером N * sizeof(Task). Канал — структура hchan (runtime/chan.go), содержащая мьютекс, указатели на очередь горутин-отправителей и получателей. Когда воркер читает из канала, он забирает элемент из буфера, если есть, иначе паркуется в очередь ожидания. Аналогично отправитель при заполненном буфере блокируется.
• При закрытии канала все ожидающие горутины пробуждаются и получают zero value + ok=false, что позволяет корректно завершить range.
• sync.WaitGroup внутри использует атомарный счётчик и sema-подобную синхронизацию через futex (на Linux). Wait вызывает остановку горутины до обнуления счётчика.
• При использовании errgroup.SetLimit внутренне создаётся семафор из буферизированного канала структур token{}.

Типичные ошибки кандидатов

1. Забывают закрыть канал задач, и воркеры никогда не завершаются: утечка горутин при выходе из pool-менеджера.
   Почему неправильно: range tasks в воркерах вечно ждёт, wg.Wait() блокируется навсегда.
   Исправление: гарантировать закрытие канала после того, как все отправители закончат, например, выделенный закрывающий код.

2. Не используют WaitGroup и завершают программу до окончания работы воркеров: теряются результаты.
   Почему неправильно: горутины могут не успеть обработать оставшиеся в буфере задачи.
   Исправление: всегда wg.Wait() после закрытия канала; структурировать код так, чтобы main ждал.

3. Передача sync.WaitGroup по значению: копирует счётчик, оригинал не меняется, Wait может проскочить или deadlock.
   Почему неправильно: WaitGroup содержит внутреннее состояние, копирование нарушает семантику.
   Исправление: передавать по указателю или использовать замыкание.

4. Создание пула с горутинами, которые сами себе шлют задачи, вызывая дедлок на заполненном канале: отправитель (воркер) ждёт свободного места в канале, но никто не читает.
   Почему неправильно: все воркеры заблокированы на отправке, очередь не опустошается.
   Исправление: отделение генераторов задач и обработчиков; если необходимо порождать подзадачи, использовать неблокирующую отправку с select и default, либо увеличивать буфер.

Возможные дополнительные вопросы интервьюера

Как динамически изменять количество воркеров в рантайме?
Запускать менеджер, который по сигналу (канал, ticker) изменяет счётчик активных горутин: при уменьшении посылает специальные маркеры остановки через дополнительный канал quit, при увеличении запускает новые горутины.

Какая стратегия лучше — фиксированный пул или неограниченные горутины с семафором?
Фиксированный пул эффективнее по памяти и накладным расходам на создание горутин, если задачи короткоживущие. Семафор с динамическим созданием горутин подходит для разнородных задач, где число одновременно работающих невелико, но общая нагрузка варьируется.

Как обрабатывать панику в воркере, чтобы не обрушить весь пул?
В теле обработчика добавить defer recover(), логировать и возможно перезапускать воркер.

Как реализовать потокобезопасную очередь?

Краткий ответ (30–60 секунд)

Потокобезопасная очередь обеспечивает безопасное добавление и извлечение из нескольких горутин. В Go проще всего использовать канал chan, который по своей природе конкурентен. Если нужна неограниченная очередь, оборачивают двусвязный список или слайс с sync.Mutex. Для lock-free вариантов применяют atomic и структуры из concurrent-queue библиотек, но идиоматично — канал либо мьютекс + контейнер.

Развёрнутый ответ

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

Пример неограниченной очереди с sync.Mutex и связным списком:

type Queue[T any] struct {
    mu    sync.Mutex
    list  list.List
    cond  *sync.Cond
}

func NewQueue[T any]() *Queue[T] {
    q := &Queue[T]{}
    q.cond = sync.NewCond(&q.mu)
    return q
}

func (q *Queue[T]) Push(v T) {
    q.mu.Lock()
    q.list.PushBack(v)
    q.mu.Unlock()
    q.cond.Signal()
}

func (q *Queue[T]) Pop() T {
    q.mu.Lock()
    defer q.mu.Unlock()
    for q.list.Len() == 0 {
        q.cond.Wait()
    }
    el := q.list.Front()
    q.list.Remove(el)
    return el.Value.(T)
}

Использование sync.Cond позволяет эффективно ждать появления элементов без холостого опроса. Альтернатива — канал chan struct{} для уведомлений, но sync.Cond даёт более чистый код.

Для случая, когда один производитель и много потребителей, достаточно канала. Если же много производителей и потребителей, и скорость важна, применяют lock-free очереди на атомарных операциях (например, имплементация на основе алгоритма Michael-Scott), но в Go вручную писать их редко оправдано — стандартные примитивы дают приемлемую производительность.

Под капотом (internals)

• chan реализован как структура hchan с блокировкой (быстрый мьютекс), буфером и указателями. Это уже потокобезопасная очередь.
• sync.Mutex в Linux базируется на futex, в неконкурентном случае захват почти бесплатен. При высокой конкуренции добавляет оверхед.
• sync.Cond использует список ожидающих горутин, сигнал пробуждает одну. Wait атомарно освобождает мьютекс и встаёт в очередь.
• Для lock-free структуры в Go нужно осторожно работать с unsafe.Pointer и атомарными CAS (как в sync.Pool). Рантайм гарантирует garbage collection только через сильные ссылки, поэтому lock-free контейнеры должны использовать atomic.Pointer или atomic.Value.

Типичные ошибки кандидатов

1. Использование слайса без синхронизации при конкурентных Push/Pop: гонка данных и паника при обращении к неинициализированным элементам или выход за границы.
   Почему неправильно: слайс — не потокобезопасная структура, одновременная модификация приводит к повреждению слайса.
   Исправление: защищать мьютексом все операции, либо использовать канал.

2. Ожидание на sync.Cond без цикла проверки условия: spurious wakeup или потерянный сигнал могут привести к извлечению из пустой очереди.
   Почему неправильно: документация sync.Cond явно требует проверку условия в цикле, иначе поведение не определено при ложных пробуждениях.
   Исправление: всегда for queue.Empty() { cond.Wait() }.

3. Блокировка с удержанием мьютекса при отправке уведомлений (Signal внутри Lock/Unlock): можно не успеть разбудить до освобождения, но это допустимо; однако часто забывают, что Signal/Broadcast можно вызывать без удержания блокировки для повышения производительности. Ошибка — вызов Signal без мьютекса, если логика гарантирует, что соперничество невозможно; но в целом допустимо. Более типичная ошибка: сигнализировать до анлока мьютекса, что может заставить разбуженную горутину сразу же встать в очередь на мьютекс, снижая производительность.
   Исправление: вызывать cond.Signal() после mu.Unlock() (если логика позволяет), чтобы разбуженная горутина могла сразу захватить мьютекс без ожидания.

Возможные дополнительные вопросы интервьюера

Как реализовать приоритетную очередь, конкурентную?
Обернуть кучу (container/heap) с мьютексом, Push и Pop работают как обычно; или использовать несколько каналов с разными приоритетами и select с приоритетным чтением.

Чем плох бесконечный рост очереди в памяти?
Может привести к OOM. Нужно добавить backpressure: либо блокировать отправителей при достижении лимита, либо сбрасывать старые сообщения (drop oldest).

Можно ли сделать Wait-free очередь в Go?
Wait-free алгоритмы сложны и требуют атомарных примитивов. В Go предпочтительней lock-free с ограниченным числом ретраев (как в sync.Pool), но для большинства задач мьютекс или канал достаточно быстры.

Как реализовать механизм повторных попыток (retry mechanism)?

Краткий ответ (30–60 секунд)

Retry-механизм повторяет операцию при временных ошибках с заданными стратегиями: фиксированная задержка, экспоненциальный backoff с jitter (дрожанием), ограничение числа попыток и общего времени. В Go это оформляется циклом с time.Sleep, обёрнутым в утилиту. Широко применяется библиотека cenkalti/backoff или простой цикл с контекстом для отмены.

Развёрнутый ответ

Базовая сигнатура:

func Retry(ctx context.Context, maxAttempts int, base time.Duration, fn func() error) error

Внутри цикл for i := 0; i < maxAttempts; i++ с вызовом, проверкой ошибки (если nil — выход), иначе ожиданием по формуле: backoff = base * 2^i + randomJitter. Jitter (случайная добавка 0..backoff) предотвращает синхронизацию повторных попыток многих клиентов и снижает лавину запросов.

Контекст позволяет прервать retry при истечении таймаута или отмене:

select {
case <-ctx.Done():
    return ctx.Err()
case <-time.After(backoff):
}

Важно различать временные ошибки (network timeout, 503) и постоянные (неверный запрос 400). Обычно в retry включают только временные. Можно возвращать специальную ошибку-маркер, которую retry-обёртка распознает.

Под капотом (internals)

• time.After создаёт таймер, который добавляется в кучу планировщика; горутина паркуется на канале таймера. При частых вызовах лучше переиспользовать time.Timer с Reset, чтобы избежать аллокаций.
• ctx.Done() — канал, закрывающийся при отмене. select пробуждается при любом из событий.
• Экспоненциальный backoff без jitter вызывает классический «thundering herd» при массовых отказах, поэтому jitter критичен.

Типичные ошибки кандидатов

1. Бесконечный retry без ограничения по времени/попыткам: при перманентной ошибке программа зависает.
   Почему неправильно: исчерпание ресурсов и невозможность восстановления, отсутствие таймаута для клиента.
   Исправление: всегда задавать maxAttempts и/или дедлайн через контекст.

2. Не используют контекст, retry не реагирует на отмену родительского запроса: при отмене HTTP-запроса сервер продолжает попытки, тратя CPU.
   Почему неправильно: нарушение принципа вежливости к вызывающей стороне, потенциальная утечка горутин.
   Исправление: передавать context.Context и проверять ctx.Err() на каждой итерации.

3. Создание нового таймера в каждой итерации через time.After без его остановки: если цикл завершился досрочно, таймер остаётся в памяти до срабатывания, создавая мусор.
   Почему неправильно: множество таймеров нагружает планировщик и GC.
   Исправление: использовать timer := time.NewTimer(d); defer timer.Stop() и сбрасывать.

4. Применение retry к неидемпотентным операциям (например, создание заказа с побочным эффектом): повтор может создать дубликат.
   Почему неправильно: двойная отправка денег или двойное создание сущности.
   Исправление: гарантировать идемпотентность (передавать уникальный idempotency key) или применять retry только к операциям чтения/идемпотентным.

Возможные дополнительные вопросы интервьюера

Как реализовать circuit breaker на основе retry?
Добавить счётчик ошибок и при превышении порога переходить в состояние «open», игнорируя вызовы или сразу возвращая ошибку, периодически пробуя «half-open». Это улучшенный retry, чтобы не нагружать отказавший сервис.

Как сделать кэширование успешного результата между retry, чтобы избежать повторной работы?
Использовать singleflight для подавления дублирующих запросов к одному ключу, либо сохранить успешный ответ и при следующем запросе возвращать его, пока не истечёт время.

Как тестировать retry с экспоненциальным backoff, не замедляя тесты?
Передать таймер как зависимость (интерфейс), в тестах использовать фиктивный таймер, который не ждёт.

Как реализовать конвейер (pipeline)?

Краткий ответ (30–60 секунд)

Pipeline в Go — цепочка горутин, соединённых каналами, где каждая стадия преобразует поток данных. Стадия читает из входного канала, обрабатывает и передаёт результат в выходной. Завершение координируется закрытием каналов и sync.WaitGroup. Это позволяет параллельно выполнять этапы обработки, подобно конвейеру на заводе.

Развёрнутый ответ

Пример трёхстадийного пайплайна: генерация чисел, возведение в квадрат, печать.

func gen(ctx context.Context, nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for _, n := range nums {
            select {
            case out <- n:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}

func sq(ctx context.Context, in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for n := range in {
            select {
            case out <- n * n:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}

Конвейер легко масштабируется: на медленных стадиях запускают несколько горутин, читающих один входной канал — тогда выходные каналы объединяют мультиплексором (fan-in). Для завершения с ошибкой используют errgroup и дополнительный канал ошибок.

Важно: закрытие каналов только передающей стороной; при досрочной отмене через контекст стадии должны корректно освободить ресурсы. Шаблон гарантирует, что после завершения всех стадий не останется утечек.

Под капотом (internals)

• Каналы используют общую структуру hchan. Чтение из закрытого канала даёт zero values, и range завершается. Это естественное средство сигнализации об окончании потока.
• Когда несколько горутин читают один канал, hchan распределяет элементы по очереди получателей, обеспечивая балансировку.
• Контекст передаёт сигнал отмены через закрытие канала ctx.Done(), что резко контрастирует с посылкой данных — это широковещательное уведомление без гонки.

Типичные ошибки кандидатов

1. Не закрывают выходной канал при завершении стадии, что вызывает deadlock на следующей стадии: следующая стадия висит на range вечно.
   Почему неправильно: range над открытым каналом без данных блокирует горутину, пайплайн никогда не завершится.
   Исправление: всегда defer close(out) в горутине-отправителе после того, как все данные отправлены.

2. Запуск многих горутин-обработчиков без координации завершения: кто закроет выходной канал? Может быть закрыт раньше времени, пока другие горутины ещё пишут — panic.
   Почему неправильно: запись в закрытый канал вызывает панику.
   Исправление: использовать sync.WaitGroup и закрывать канал после того, как все горутины закончат.

3. Не пробрасывают контекст, стадии не останавливаются при отмене: ресурсы не освобождаются.
   Почему неправильно: вызывает утечки горутин и блокировки при завершении программы.
   Исправление: каждую стадию реализовывать с поддержкой ctx.Done().

Возможные дополнительные вопросы интервьюера

Как лимитировать параллелизм на конкретной стадии, не создавая безразмерный пул горутин?
Использовать семафор или ограниченный канал, через который подаются задачи. Можно применить worker pool внутри стадии.

Как объединить результаты нескольких параллельных стадий (fan-in)?
Создать мультиплексор: горутина, которая через select читает из нескольких каналов и отправляет в один, закрывая его при завершении всех (WaitGroup для отслеживания).

Что делать, если одна стадия намного медленнее других?
Увеличить количество параллельных горутин на этой стадии, а также буферизировать канал перед ней, чтобы сгладить неравномерность.

Как реализовать паттерн «издатель-подписчик» (pub/sub)?

Краткий ответ (30–60 секунд)

Pub/sub реализуется посредством централизованного брокера (in-memory), который хранит список подписчиков по темам. При публикации брокер рассылает сообщение всем подписчикам либо напрямую вызывая обработчик, либо через каналы. Для thread-safety добавляют sync.RWMutex на карту подписчиков. Удобно использовать каналы и горутину-обработчик.

Развёрнутый ответ

Простая структура:

type Broker struct {
    mu          sync.RWMutex
    subscribers map[string][]chan interface{}
}

func (b *Broker) Subscribe(topic string) <-chan interface{} {
    b.mu.Lock()
    defer b.mu.Unlock()
    ch := make(chan interface{}, 16)
    b.subscribers[topic] = append(b.subscribers[topic], ch)
    return ch
}

func (b *Broker) Unsubscribe(topic string, ch <-chan interface{}) {
    b.mu.Lock()
    defer b.mu.Unlock()
    subs := b.subscribers[topic]
    for i, sub := range subs {
        if sub == ch {
            b.subscribers[topic] = append(subs[:i], subs[i+1:]...)
            break
        }
    }
}

func (b *Broker) Publish(topic string, msg interface{}) {
    b.mu.RLock()
    subs := b.subscribers[topic] // копия слайса, безопасно? Нужно копировать, т.к. мутабельно
    b.mu.RUnlock()
    for _, ch := range subs {
        select {
        case ch <- msg:
        default:
            // drop or block
        }
    }
}

Необходимо копировать слайс подписчиков под RLock, чтобы избежать гонки при параллельном Unsubscribe. Рассылка через небуферизированный канал может блокировать публикацию; обычно используют буфер или select с default для сброса.

Более мощные варианты: отправка сообщений через общий канал и горутину-диспетчер, которая маршрутизирует, но это добавляет оверхед. Для распределённого pub/sub применяют Redis Pub/Sub, NATS, Kafka, но в рамках одного процесса in-memory брокер — отличное решение.

Под капотом (internals)

• Каналы при публикации делают копию сообщения при отправке в буфер. Для больших структур лучше использовать указатели, чтобы избежать копирования.
• sync.RWMutex позволяет нескольким публикаторам одновременно удерживать RLock, повышая конкуренцию. Но при этом модификация subscribers требует полной блокировки, поэтому частые подписки/отписки могут снизить выгоду.
• Возможна lock-free реализация с sync.Map для тем, но список подписчиков потребует дополнительной синхронизации.

Типичные ошибки кандидатов

1. Прямой доступ к слайсу подписчиков под RLock и параллельное изменение подписок (гонка): итерация по слайсу при удалении вызывает панику или пропуск.
   Почему неправильно: если во время публикации (Rlock) другой горутиной делается Unsubscribe (Lock), то изменение слайса во время итерации — гонка данных.
   Исправление: под RLock скопировать слайс в локальную переменную и итерироваться по копии.

2. Блокирующая отправка в каналы подписчиков без select: если подписчик не читает, публикация зависает, блокируется весь брокер (если мьютекс не отпущен) или удерживает RLock, мешая отписке.
   Почему неправильно: deadlock или замедление системы, отсутствие изоляции.
   Исправление: использовать select { case ch <- msg: default: } или неблокирующую отправку с пропуском медленных потребителей; либо выделить очередь.

3. Утечка горутин подписчиков: отписались, но забыли закрыть канал, читающая горутина висит.
   Почему неправильно: потеря контроля, утечка памяти.
   Исправление: закрывать канал при отписке (с осторожностью, т.к. запись в закрытый канал — паника) или передавать сигнал через другой канал завершения.

Возможные дополнительные вопросы интервьюера

Как избежать потери сообщений при медленном подписчике?
Дать каждому подписчику ограниченную очередь, при переполнении принять политику (drop oldest/drop latest/block). Можно использовать кольцевой буфер.

Как масштабировать broker на несколько узлов?
Публиковать в распределённый лог (Kafka), каждый экземпляр подписывается как consumer group. In-memory broker только для локальной оптимизации.

Как протестировать конкурентный pub/sub?
Посылать сообщения из N горутин, в M подписчиках проверять, что получено ожидаемое число. Использовать sync.WaitGroup для ожидания завершения всех подписчиков.

Как реализовать барьер (barrier)?

Краткий ответ (30–60 секунд)

Барьер синхронизирует группу горутин: все должны достичь барьера, прежде чем какая-либо продолжит выполнение. В Go это делается через sync.WaitGroup с обратным отсчётом и последующим ожиданием, либо каналом и счётчиком достигнутых. Простейший способ: sync.WaitGroup с Add(N), каждая горутина вызывает Done(), а основная ждёт Wait(). Для повторного использования нужен циклический барьер на основе канала и счётчика под мьютексом.

Развёрнутый ответ

Одноразовый барьер:

var wg sync.WaitGroup
for i := 0; i < numWorkers; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        // работа до барьера
    }()
}
wg.Wait() // барьер
// работа после

Циклический барьер (как CyclicBarrier в Java) можно реализовать структурой с каналом «gate»:

type CyclicBarrier struct {
    n        int
    count    int
    mu       sync.Mutex
    gate     chan struct{}
    nextGate chan struct{}
}

func NewCyclicBarrier(n int) *CyclicBarrier {
    b := &CyclicBarrier{n: n}
    b.gate = make(chan struct{})
    b.nextGate = make(chan struct{})
    return b
}

func (b *CyclicBarrier) Await() {
    b.mu.Lock()
    b.count++
    if b.count == b.n {
        // все пришли, открываем текущий гейт и сбрасываем для следующего цикла
        close(b.gate)
        b.count = 0
        b.gate, b.nextGate = b.nextGate, make(chan struct{})
        b.mu.Unlock()
    } else {
        gate := b.gate
        b.mu.Unlock()
        <-gate // ожидание открытия
    }
}

Каждый вызов Await блокируется до тех пор, пока N-й участник не закроет gate. После этого все разблокируются и готовятся к новому циклу с новым каналом.

Под капотом (internals)

• sync.WaitGroup внутри содержит счётчик и семафор. Add/Done атомарны, Wait паркует горутину на семафоре до обнуления.
• В циклической реализации используются мьютекс и закрытие канала. Закрытие канала транслируется всем ожидающим читателям. Так как в Go нельзя перезакрыть канал, приходится создавать новый.
• При высоком числе участников дешёвая блокировка на канале эффективнее, чем постоянный опрос.

Типичные ошибки кандидатов

1. Использовать Add внутри горутин, а не до их запуска: wg.Add(1) в горутине может случиться после того, как Wait уже пройдёт (если горутина не успела запуститься), и ожидание будет пропущено, что приведёт к Wait до выполнения всех.
   Почему неправильно: гонка между вызовом Add и Wait, стандартная практика — Add вне горутины.
   Исправление: считать количество заранее и вызвать wg.Add(N) до запуска цикла, а в горутинах только Done().

2. Забывчивость про Done(): барьер никогда не будет достигнут, deadlock.
   Почему неправильно: Wait() висит вечно.
   Исправление: обязательно вызывать Done (через defer).

3. Разделяемая переменная-флаг без синхронизации для эмуляции барьера: несколько горутин ждут изменения флага без атомарности — либо гонка, либо ожидание без гарантии что все дошли.
   Почему неправильно: нет happens-before, компилятор/процессор могут переупорядочить.
   Исправление: применять каналы или sync примитивы.

Возможные дополнительные вопросы интервьюера

Как реализовать барьер с таймаутом — если кто-то не дошёл за время, продолжить?
Модифицировать ожидание select'ом: case <-gate: case <-time.After(timeout):, но при нарушении нужно корректно обработать состояние (перевести барьер в broken). В Go стандартного нет.

Чем барьер отличается от WaitGroup?
WaitGroup — это одноразовый барьер «все закончили работу». Барьер (особенно циклический) синхронизирует фазы: все завершили фазу, потом вместе переходят к следующей.

Как реализовать двухфазный барьер (вход и выход)?
Добавить два gate: после прохода первого все продолжают, потом попадают во второй. Или использовать основной барьер дважды.

Как реализовать семафор?

Краткий ответ (30–60 секунд)

Семафор ограничивает число горутин, одновременно выполняющих ресурс. В Go это делается буферизированным каналом: sem := make(chan struct{}, maxConcurrency). Захват — отправка в канал, освобождение — чтение из канала. Такой семафор весит мало и не требует дополнительных библиотек.

Развёрнутый ответ

Применение:

sem := make(chan struct{}, 10) // семафор на 10 разрешений
for i := 0; i < 100; i++ {
    go func(task int) {
        sem <- struct{}{}        // захват
        defer func() { <-sem }() // освобождение
        doWork(task)
    }(i)
}

Если нужен неблокирующий захват, используем select с default:

select {
case sem <- struct{}{}:
    // захвачено
    defer func() { <-sem }()
default:
    // не захвачено, отказ или ожидание
}

Канал-семафор прост, но лишён некоторых возможностей «взвешенного» семафора (acquire с весом >1). Расширенный семафор можно построить с использованием sync.Mutex и счётчика, плюс sync.Cond, чтобы гасить ожидающих. Пакет golang.org/x/sync/semaphore предоставляет именно такой взвешенный семафор, где Acquire(ctx, n) поддерживает контекст и отмену.

Под капотом (internals)

• Буферизированный канал make(chan struct{}, N) внутри: массив структур на N элементов. Отправка занимает слот, при заполнении горутина блокируется на очереди отправителей. Чтение освобождает слот.
• Семафор на основе sync.Mutex + счётчик + sync.Cond при вызове Acquire если счётчик < n, горутина добавляется в список ожидающих (FIFO). Cond.Signal пробуждает одну. В x/sync/semaphore используется дополнительная очередь ожидающих с весами и возможность отмены (контекст).
• Реализация в x/sync также поддерживает уведомление об отмене контекста: при отмене горутина просыпается и удаляется из очереди.

Типичные ошибки кандидатов

1. Забывают освободить семафор (defer <-sem), что приводит к утечке разрешений и полной блокировке последующих горутин.
   Почему неправильно: семафор «иссякает» и никто не может захватить ресурс.
   Исправление: обязательно освобождать через defer, но с осторожностью в циклах; правильно структурировать.

2. Использование небуферизированного канала как семафора: при попытке захвата двумя горутинами одна блокируется сразу, порядок захвата не гарантирует одновременного доступа. Это не семафор, а просто блокировка.
   Почему неправильно: пропускная способность = 1, не позволяет задать N параллельных исполнений.
   Исправление: использовать буферизированный канал ёмкостью N.

3. Обратный порядок захвата/освобождения: <-sem для захвата, sem <- struct{}{} для освобождения. Ломает семантику и может сразу дедлочить.
   Почему неправильно: канал полон с самого начала? При создании make(chan struct{}, N) в нём ничего нет, захват через чтение будет невозможен.
   Исправление: захват — запись в канал, освобождение — чтение.

Возможные дополнительные вопросы интервьюера

Как сделать семафор с приоритетом для определённых горутин?
Использовать свой список ожидания и эвристику выбора следующего разблокируемого; канал не даёт такой гибкости. Придётся реализовать на Cond и ручном управлении очередью.

В чём разница между семафором и worker pool?
Worker pool явно содержит долгоживущие горутины, а семафор лишь ограничивает количество одновременно работающих горутин, которые могут создаваться динамически.

Как можно отменить ожидание семафора при отмене контекста?
Использовать x/sync/semaphore.Weighted.Acquire(ctx, n) или построить своё решение с каналом отмены: select { case sem <- struct{}{}: case <-ctx.Done(): return }.

Как реализовать ленивую инициализацию (singleton)?

Краткий ответ (30–60 секунд)

Ленивый синглтон создаётся один раз при первом обращении. В Go идиоматично использовать sync.Once. Он гарантирует, что функция инициализации выполнится ровно один раз, даже при конкурентных вызовах. Пакет sync.Once атомарен и быстр; альтернатива — блокировка с двойной проверкой, но sync.Once предпочтительнее.

Развёрнутый ответ

var (
    instance *MyService
    once     sync.Once
)

func GetService() *MyService {
    once.Do(func() {
        instance = &MyService{data: loadConfig()}
    })
    return instance
}

Do блокирует вызывающую горутину до завершения инициализации, остальные ждут. В отличие от двойной проверки (double-checked locking), sync.Once гарантирует, что даже при гонке instance не будет использован частично инициализированным.

Также можно использовать sync.Mutex и флаг, но это ручной подход, подверженный ошибкам. Ещё есть инициализация на уровне пакета: глобальные переменные инициализируются при загрузке пакета (до main), это eager, а не lazy.

Под капотом (internals)

• sync.Once состоит из атомарного флага (uint32 done) и мьютекса (Mutex). При Do сначала быстро атомарно проверяется флаг, если уже 1 — выход. Если 0, захватывается мьютекс, и после повторной проверки выполняется функция, флаг атомарно ставится в 1. Мьютекс гарантирует, что только одна горутина выполняет f, остальные ждут на мьютексе, после его освобождения они видят done=1 и быстро выходят.
• Памятная модель Go гарантирует, что все записи, сделанные внутри f, становятся видимыми всем горутинам, которые после Do увидят done=1, благодаря атомарному store и load с acquire/release семантикой.

Типичные ошибки кандидатов

1. Использование двойной проверки без sync.Once: if instance == nil { mu.Lock(); if instance == nil { instance = ... } }. В Go это небезопасно из-за модели памяти (до Go 1.19 были проблемы с переупорядочиванием).
   Почему неправильно: другая горутина может увидеть не-nil указатель до полного конструирования объекта, если компилятор/процессор переупорядочат операции; даже с atomic нужно аккуратно.
   Исправление: просто возьмите sync.Once.

2. Забывают, что sync.Once.Do не возвращает ошибку; если инициализация может упасть, паника или deadlock при следующем вызове: once.Do вызывается повторно, но функция не выполнится (done=1), значит повторный вызов никогда не переинициализирует.
   Почему неправильно: если первый раз упала паника, once всё равно помечается выполненным? Нет, паника откатывается, если не recover. Если внутри f случилась паника, sync.Once считает, что выполнение не завершено и Do больше не вызовет f никогда? На самом деле документация говорит: если f паникует, Do считает выполненным (done=1? нет, при выходе с паникой done не ставится! Проверим: реализация sync.Once внутри doSlow вызывает f(), а затем атомарно atomic.StoreUint32(&o.done, 1) после возврата f. Если f паникует, done не ставится, и последующие Do будут снова пытаться выполнить f, что может повторять панику. Но проблема: если f наполовину инициализировала объект, состояние некорректно. Лучше return error через sync.Once не прокинуть.
   Исправление: внутри Do перехватывать панику и сохранять ошибку, либо использовать sync.Once вместе с флагом готовности.

3. Создание sync.Once как поле структуры, которая копируется: копия имеет независимый done, что ломает однократность.
   Почему неправильно: копирование sync.Once после его использования запрещено (документация).
   Исправление: хранить по указателю или не копировать.

Возможные дополнительные вопросы интервьюера

Как реализовать ленивую инициализацию с параметрами?
Использовать sync.Once и функцию, которая сохраняет параметры при первом вызове. Альтернативно, sync.Map с LoadOrStore.

Можно ли сбросить sync.Once?
Нет, нельзя. Для повторной инициализации нужно создать новый Once или использовать замену на основе атомарного флага и мьютекса.

Чем sync.Once принципиально отличается от статической инициализации пакета?
Пакет init выполняется при импорте, до main, это eager. sync.Once выполняет код при первом вызове, позволяет ленивость.

Как реализовать шаблон «строитель» (builder)?

Краткий ответ (30–60 секунд)

Строитель разделяет конструирование сложного объекта и его представление. В Go обычно создают структуру-строитель с методами-мутаторами, возвращающими указатель на неё для цепочного вызова (fluent интерфейс). Финальный метод Build() создаёт целевой объект, возможно проводя валидацию.

Развёрнутый ответ

Пример:

type ServerConfig struct {
    Host string
    Port int
    TLS  bool
}

type ServerBuilder struct {
    config ServerConfig
    err    error
}

func NewServerBuilder() *ServerBuilder {
    return &ServerBuilder{config: ServerConfig{Port: 8080}} // значения по умолчанию
}

func (b *ServerBuilder) WithHost(host string) *ServerBuilder {
    if b.err != nil { return b }
    if host == "" { b.err = errors.New("host empty") }
    b.config.Host = host
    return b
}

func (b *ServerBuilder) WithTLS() *ServerBuilder {
    b.config.TLS = true
    return b
}

func (b *ServerBuilder) Build() (*ServerConfig, error) {
    if b.err != nil { return nil, b.err }
    // доп. валидация
    return &b.config, nil
}

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

Под капотом (internals)

• Методы возвращают указатель на тот же объект, избегая лишних аллокаций на каждом шаге.
• Накопление ошибки в поле err позволяет строить цепочку без постоянной проверки, но в продакшне лучше немедленно возвращать ошибку в Build.
• Структура-конфигурация может быть неизменяемой после Build — возвращать копию, а не указатель на внутренние данные строителя.

Типичные ошибки кандидатов

1. Возврат значения строителя, а не указателя: при цепочечном вызове каждый раз создаётся копия, изменения теряются.
   Почему неправильно: func (b ServerBuilder) WithHost(...) ServerBuilder — после вызова изменения применяются к копии, исходный объект не модифицируется.
   Исправление: методы на указателе и возвращать указатель.

2. Не проверяют ошибки и возвращают частично сконфигурированный объект: Build не делает валидацию, и приложение падает позже.
   Почему неправильно: нарушение инвариантов, сложно отлаживать.
   Исправление: в Build агрессивная проверка, возвращать ошибку при некорректном состоянии.

3. Переопределение методов без возврата строителя (не fluent): используют void-методы и потом вызывают Build. Теряется преимущество читаемости.
   Почему неправильно: теряется идиоматический fluent-стиль, который и делает строителя удобным.
   Исправление: проектировать API с возвратом *Builder.

Возможные дополнительные вопросы интервьюера

Как реализовать строитель для иммутабельных объектов с большим числом полей (без копирования на каждом шаге)?
Использовать функциональные опции: type Option func(*ServerConfig). Строитель — просто собиратель опций, применяемых в Build. Пример: func WithHost(h string) Option { return func(c *ServerConfig) { c.Host = h } }.

Что делать, если нужна обязательная инициализация некоторых полей?
Сделать конструктор строителя, принимающий обязательные параметры, а остальные опциональные через методы.

Можно ли использовать строитель для создания конкурентных объектов?
Да, если строитель хранит состояние, защищённое мьютексом, но обычно строитель используется в одном потоке.

Как реализовать шаблон «фабрика» (factory)?

Краткий ответ (30–60 секунд)

Фабрика — порождающий паттерн, скрывающий логику создания объектов за функцией. В Go это простая функция New..., возвращающая интерфейс или конкретный тип, в зависимости от параметров. Может включать выбор реализации на основе конфигурации. Преимущество — централизация логики создания и легкая подмена в тестах.

Развёрнутый ответ

Классический пример: фабрика хранилищ.

type Store interface {
    Get(key string) (string, error)
}

func NewStore(kind string) (Store, error) {
    switch kind {
    case "memory":
        return &MemoryStore{}, nil
    case "redis":
        return &RedisStore{addr: "localhost:6379"}, nil
    default:
        return nil, errors.New("unknown store")
    }
}

Более идиоматичный вариант — фабрика возвращает функцию-конструктор или конкретный тип, а не интерфейс (принцип «возвращай структуры, принимай интерфейсы»). Но если фабрика скрывает тип, она возвращает интерфейс. Фабричный метод может быть статической функцией.

Под капотом (internals)

• Возврат интерфейса из фабрики создаёт замыкание над типом; интерфейсное значение содержит указатель на динамический тип и данные. Это небольшая аллокация, но не критично.
• Фабрика часто инкапсулирует сложную инициализацию (например, подключение к БД, создание пула соединений).

Типичные ошибки кандидатов

1. Фабрика возвращает конкретный тип, когда нужна гибкость подмены: вызывающий код жёстко привязывается к типу, что мешает тестированию.
   Почему неправильно: нарушается DIP (dependency inversion), клиенты не могут использовать mock.
   Исправление: возвращать интерфейс, если планируется полиморфизм.

2. Смешение логики выбора внутрь клиентского кода вместо фабрики: везде разбросаны switch-case — трудно добавлять новые типы.
   Почему неправильно: дублирование, нарушение Open/Closed.
   Исправление: вынести в единую фабричную функцию.

3. Паника внутри фабрики при неизвестном типе: аварийное завершение.
   Почему неправильно: фабрика должна возвращать ошибку, чтобы вызывающий мог её обработать.
   Исправление: возвращать (Store, error).

Возможные дополнительные вопросы интервьюера

Как сделать фабрику расширяемой без изменения кода?
Использовать реестр: map[string]func() Store, куда можно регистрировать новые конструкторы извне (plugin-паттерн). Но в Go это обычно делается через явную регистрацию в init() других пакетов.

В чём разница между фабрикой и абстрактной фабрикой?
Фабрика создаёт один продукт, абстрактная фабрика — семейство связанных продуктов. В Go абстрактная фабрика — интерфейс с методами-фабриками.

Как протестировать код, использующий фабрику?
Передать фабрику как зависимость (функциональный тип), в тестах подменить на заглушку.

Как реализовать шаблон «декоратор»?

Краткий ответ (30–60 секунд)

Декоратор динамически добавляет поведение объекту, оборачивая его. В Go это функция, принимающая интерфейс и возвращающая тот же интерфейс, добавляя действия до/после вызова оригинального метода. Часто применяется для middleware (HTTP), логирования, метрик.

Развёрнутый ответ

Пример декоратора Reader:

type Reader interface { Read(p []byte) (n int, err error) }

type LoggingReader struct {
    r Reader
}
func (l *LoggingReader) Read(p []byte) (int, error) {
    n, err := l.r.Read(p)
    log.Printf("read %d bytes, err=%v", n, err)
    return n, err
}

Для HTTP middleware:

func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        log.Println(r.URL)
        next.ServeHTTP(w, r)
    })
}

Декораторы легко комбинируются: final := DecorateB(DecorateA(base)).

Под капотом (internals)

• Декоратор в Go — это просто структура, содержащая интерфейс. Никакой магии; рантайм динамически вызывает метод оригинального объекта через интерфейсный диспетч.
• Композиция декораторов создаёт цепочку вызовов; каждый уровень добавляет немного накладных расходов на вызов метода.

Типичные ошибки кандидатов

1. Декоратор изменяет сигнатуру (возвращает не тот же интерфейс): нарушает совместимость, нельзя подставить вместо оригинального объекта.
   Почему неправильно: клиентский код ожидает интерфейс, а получает нечто другое.
   Исправление: жёстко соблюдать тот же интерфейс.

2. Декоратор не вызывает оригинальный метод, забыв про next.ServeHTTP, полностью подменяя поведение.
   Почему неправильно: это уже не декоратор, а полная замена, что может сломать цепочку.
   Исправление: всегда вызывать метод вложенного объекта, если это не намеренное переопределение.

3. Зацикливание декораторов при неправильном создании: один декоратор оборачивает другой, а тот — первый.
   Почему неправильно: переполнение стека или бесконечная рекурсия.
   Исправление: строить цепочку линейно, без обратных ссылок.

Возможные дополнительные вопросы интервьюера

Как декоратор может модифицировать возвращаемые значения?
Перехватить результат, изменить и вернуть новое значение. Например, кэширующий декоратор возвращает сохранённое значение.

Как убрать декоратор динамически?
Оборачивать в декоратор, который может включать/выключать функциональность по условию (прозрачный прокси).

Как применить декоратор ко всем методам большого интерфейса без boilerplate?
Использовать встраивание (embedding) и переопределить только нужные методы, остальные транслируются автоматически.

Как реализовать шаблон «команда» (command)?

Краткий ответ (30–60 секунд)

Команда инкапсулирует запрос как объект, позволяя ставить их в очередь, логировать, отменять. В Go это интерфейс Command с методом Execute(). Реализации команд содержат получателя и параметры. Дополнительно можно добавить Undo. Используется для отложенных действий, очередей задач.

Развёрнутый ответ

type Command interface {
    Execute() error
}

type SaveCommand struct {
    db  *Database
    doc Document
}
func (c *SaveCommand) Execute() error { return c.db.Save(c.doc) }

type Scheduler struct {
    queue []Command
}
func (s *Scheduler) Run() {
    for _, cmd := range s.queue {
        cmd.Execute()
    }
}

Для отмены добавляют Undo(). Команды сериализуемы, их можно передавать по сети, сохранять в лог для повторного воспроизведения (Event Sourcing).

Под капотом (internals)

• Интерфейс с одним методом — это всего лишь указатель на таблицу методов и данные. Минимальный оверхед.
• При сериализации команд (например, в JSON) нужно регистрировать типы, использовать фабрику для восстановления.

Типичные ошибки кандидатов

1. Команда хранит изменяемое состояние, которое между Execute изменяется извне: нарушается инкапсуляция.
   Почему неправильно: поведение команды становится непредсказуемым.
   Исправление: передавать все параметры в конструкторе, делать команду неизменяемой.

2. Забывают про обработку ошибок в Execute, и планировщик не знает, что делать: тихо глотают ошибку.
   Почему неправильно: система не может корректно реагировать на сбои (повтор, компенсация).
   Исправление: возвращать ошибки, планировщик должен определять стратегию (retry, dead-letter).

3. Использование одной команды для разных получателей с switch по типу: нарушение принципа open/closed, команда знает обо всех.
   Почему неправильно: добавляя нового получателя, придётся менять команду.
   Исправление: на каждый получатель своя команда, либо параметризация через интерфейс получателя.

Возможные дополнительные вопросы интервьюера

Как реализовать составную команду (макрокоманду), выполняющую несколько команд атомарно?
Создать CompositeCommand, хранящую список и выполняющую последовательно, или с транзакционностью (все или ничего).

Как добавить асинхронное выполнение команд?
Поместить команду в канал, отдельный воркер достаёт и выполняет.

Как логировать команды для возможности повторного воспроизведения состояния?
Хранить последовательность команд в append-only логе; состояние восстанавливается применением всех команд с начала. Паттерн Event Sourcing.

Как реализовать шаблон «стратегия» (strategy)?

Краткий ответ (30–60 секунд)

Стратегия определяет семейство алгоритмов, инкапсулирует каждый и делает их взаимозаменяемыми. В Go это интерфейс с одним методом (например, SortStrategy), и клиент хранит ссылку на этот интерфейс, позволяя подменять реализацию на лету. Это базовый приём внедрения зависимости.

Развёрнутый ответ

type SortStrategy interface {
    Sort([]int)
}

type QuickSort struct{}
func (QuickSort) Sort(data []int) { sort.Ints(data) } // placeholder

type BogoSort struct{}
func (BogoSort) Sort(data []int) { /* ... */ }

type Sorter struct {
    strategy SortStrategy
}
func (s *Sorter) SetStrategy(strategy SortStrategy) { s.strategy = strategy }
func (s *Sorter) DoSort(data []int) { s.strategy.Sort(data) }

Выбор стратегии может зависеть от входных данных (адаптивный подход). В Go интерфейс — идеальный инструмент для стратегии.

Под капотом (internals)

• Интерфейсное значение занимает два слова: указатель на тип и указатель на данные. Вызов метода через интерфейс происходит через диспетчер (itable), что немного дороже прямого вызова, но в высоконагруженных алгоритмах накладные расходы минимальны.

Типичные ошибки кандидатов

1. Передача стратегии по значению и невозможность сохранить состояние внутри стратегии: стратегии без состояния работают, но если нужен stateful алгоритм (с кэшем), нужно быть уверенным в мутабельности.
   Почему неправильно: значение копируется, потеря состояния.
   Исправление: использовать указатели на стратегии или быть уверенным, что состояние хранится вне стратегии.

2. Смешивание стратегии с контекстом: клиентский код сам выбирает алгоритм через switch, а не через интерфейс.
   Почему неправильно: добавление нового алгоритма требует модификации клиента.
   Исправление: клиент зависит только от интерфейса, стратегия внедряется извне (dependency injection).

3. Создание интерфейса с кучей методов, где нужна стратегия только одного действия: интерфейс с 5 методами, а нужен один.
   Почему неправильно: интерфейс слишком жирный, сложно реализовывать моки.
   Исправление: принцип разделения интерфейсов: выделить узкоспециализированный интерфейс под конкретную задачу.

Возможные дополнительные вопросы интервьюера

Чем стратегия отличается от декоратора?
Стратегия меняет ядро алгоритма (объект сам делегирует работу), декоратор добавляет поведение вокруг неизменного ядра, обычно сохраняя интерфейс.

Как протестировать смену стратегии без модификации продакшн-кода?
Использовать внедрение интерфейса, в тестах подставлять mock-реализацию.

Может ли стратегия быть функциональным типом вместо интерфейса?
Да, type SortFunc func([]int). В Go это часто удобнее, если стратегия — одна функция.

Как реализовать шаблон «адаптер» (adapter)?

Краткий ответ (30–60 секунд)

Адаптер преобразует интерфейс одного типа в интерфейс, ожидаемый клиентом. В Go это структура, оборачивающая адаптируемый объект и реализующая целевой интерфейс, делегируя вызовы с преобразованиями параметров. Часто используется для интеграции внешних библиотек или legacy кода.

Развёрнутый ответ

Пример: клиент ожидает ModernPrinter, а есть LegacyPrinter с другим методом.

type ModernPrinter interface { Print(s string) }
type LegacyPrinter struct{}
func (l *LegacyPrinter) PrintDocument(doc string) { fmt.Println(doc) }

type LegacyAdapter struct {
    legacy *LegacyPrinter
}
func (a *LegacyAdapter) Print(s string) { a.legacy.PrintDocument(s) }

Адаптер также может преобразовывать форматы данных, например, адаптер из io.Reader в io.ReadCloser с фиктивным Close. В стандартной библиотеке io.NopCloser — пример адаптера.

Под капотом (internals)

• Адаптер обычно — тонкая обёртка, встраиваемая (embedded) для минимизации кода. Но если методы имеют разные сигнатуры, требуется ручное преобразование.
• Адаптер не должен добавлять бизнес-логику — только трансляцию.

Типичные ошибки кандидатов

1. Адаптер добавляет сложную логику, становясь фактически декоратором или прокси: размытие ответственности.
   Почему неправильно: усложняет поддержку, теряется ясность.
   Исправление: держать адаптер прозрачным, только преобразование сигнатур/типов.

2. Неправильная обработка ошибок: адаптер игнорирует ошибки адаптируемого объекта и возвращает ok всегда.
   Почему неправильно: клиент не узнает о сбоях.
   Исправление: честно пробрасывать ошибки, возможно оборачивая в свои типы.

3. Циклические зависимости из-за адаптера в пакете: адаптер импортирует и целевой пакет, и адаптируемый, может создать цикл.
   Почему неправильно: модульность нарушается, код не компилируется.
   Исправление: размещать адаптер в отдельном пакете или там, где он используется.

Возможные дополнительные вопросы интервьюера

Чем адаптер отличается от фасада?
Адаптер меняет интерфейс существующего класса, фасад предоставляет упрощённый интерфейс к сложной системе.

Может ли адаптер работать с несколькими адаптируемыми объектами?
Да, если требуется объединить несколько, но тогда это ближе к фасаду.

Как протестировать адаптер?
Замокать адаптируемый объект и проверить вызовы с преобразованными аргументами.

Как реализовать graceful shutdown?

Краткий ответ (30–60 секунд)

Graceful shutdown — вежливое завершение приложения: перестаём принимать новые запросы, завершаем текущие, закрываем ресурсы. В Go ловим сигналы ОС (SIGINT, SIGTERM) через канал signal.Notify, отменяем корневой контекст, HTTP-сервер выключаем через Shutdown(ctx). Все горутины должны следить за ctx.Done().

Развёрнутый ответ

Типичный шаблон:

func main() {
    srv := &http.Server{Addr: ":8080", Handler: mux}
    go func() {
        if err := srv.ListenAndServe(); err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("shutdown error: %v", err)
    }
    // закрытие БД, очередей и т.д.
}

Важно: srv.Shutdown дожидается завершения активных соединений, но не бесконечно (ограничено таймаутом контекста). Горутины-обработчики должны уважать Request.Context(), который будет отменён при shutdown, чтобы прервать длительные операции.

Kubernetes при отправке SIGTERM даёт terminationGracePeriodSeconds, поэтому приложение должно уложиться.

Под капотом (internals)

• http.Server.Shutdown закрывает слушающий сокет, а затем ожидает завершения всех активных соединений, проверяя счётчик. Соединения, которые «зависли», будут принудительно закрыты через таймаут контекста.
• signal.Notify работает через runtime: когда приходит сигнал, рантайм записывает его в буферизированный канал, горутина, слушающая канал, просыпается.
• Корневой контекст context.Background() не отменяем; WithTimeout создаёт таймер, который отменяет контекст.

Типичные ошибки кандидатов

1. Использование os.Exit сразу при сигнале без ожидания активных запросов: обрыв соединений, потеря данных.
   Почему неправильно: жестокое завершение, пользователи получают ошибки.
   Исправление: сначала вежливо выключать сервер и воркеров, затем уже выходить.

2. Блокировка в ListenAndServe без горутины, и сигнал никогда не будет обработан: main висит на ListenAndServe, код после не выполняется.
   Почему неправильно: ListenAndServe блокирует, канал quit не достигнется.
   Исправление: запускать сервер в горутине, а main должен слушать сигнал и shutdown.

3. Игнорирование Request.Context() в долгих обработчиках: Shutdown не может их прервать, сервер ждёт до таймаута.
   Почему неправильно: бесполезное ожидание, затягивание завершения.
   Исправление: в долгих операциях передавать ctx и проверять ctx.Err().

Возможные дополнительные вопросы интервьюера

Как корректно завершить worker pool при shutdown?
Отменить контекст, передаваемый в пул; горутины проверяют ctx.Done(), закрыть канал задач, дождаться WaitGroup.

Как обрабатывать Health Check во время shutdown?
Вести флаг готовности; при старте shutdown сразу перевести readiness endpoint в «не готов», чтобы балансировщик перестал слать трафик. Liveness пусть ещё живёт.

Как реализовать принудительное завершение после таймаута graceful?
После Shutdown(ctx) можно выполнить os.Exit(1), если контекст истёк с ошибкой DeadlineExceeded.

Как реализовать health check?

Краткий ответ (30–60 секунд)

Health check — HTTP эндпоинты /health и /ready, сообщающие о состоянии сервиса. Liveness показывает, жив ли процесс; Readiness — может ли обрабатывать запросы (подключения к БД, заполненный кэш). В Go это простой обработчик, возвращающий 200/503 на основе проверок зависимостей. Для Kubernetes используют именно эти пробы.

Развёрнутый ответ

Пример:

type HealthChecker struct {
    mu      sync.RWMutex
    ready   bool
    dbPing  func() error
}

func (h *HealthChecker) ReadinessHandler(w http.ResponseWriter, r *http.Request) {
    h.mu.RLock()
    ready := h.ready
    h.mu.RUnlock()
    if !ready {
        http.Error(w, "not ready", http.StatusServiceUnavailable)
        return
    }
    if err := h.dbPing(); err != nil {
        http.Error(w, "db unreachable", http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
}

При старте сервис не ready, пока не инициализируется (warm-up). После сигнала shutdown readiness убирается. Liveness обычно всегда OK, если процесс жив, но можно проверять критические deadlock (специальные горутины-сердцебиения).

Под капотом (internals)

• HTTP-обработчики — обычные функции, могут паниковать; net/http ловит панику и отвечает 500. Лучше самим перехватывать.
• Проверка БД каждым запросом readiness может нагружать; лучше кэшировать результат на N секунд фоновой горутиной.

Типичные ошибки кандидатов

1. Readiness делает тяжёлые синхронные проверки (например, полный healthcheck всех зависимостей) на каждый запрос, создавая задержки и нагрузку.
   Почему неправильно: кластер Kubernetes дёргает readiness часто, система деградирует.
   Исправление: асинхронно обновлять статус проверок и возвращать кэшированное значение.

2. Не делают различия между liveness и readiness: liveness возвращает 503 при временной недоступности БД — Kubernetes перезапускает под, усугубляя ситуацию.
   Почему неправильно: перезапуск не решит проблему с БД, приведёт к циклам перезапуска.
   Исправление: liveness должен быть минималистичным (процесс жив), readiness — проверять внешние зависимости.

3. Забывают про graceful shutdown: readiness продолжает отдавать 200 после начала остановки: балансировщик шлёт трафик, который будет обрублен.
   Почему неправильно: ошибки пользователей.
   Исправление: при получении сигнала shutdown сразу выставить ready = false.

Возможные дополнительные вопросы интервьюера

Как проверить взаимоблокировку горутин в liveness?
Запустить горутину, которая периодически обновляет атомарный таймстемп; liveness проверяет, что разница не превышает порог.

Что делать, если health check должен проверять состояние внешнего API с авторизацией?
Не вставлять реальную проверку в каждый HTTP-запрос, лучше фоново, иначе подставим под угрозу безопасность.

Как обрабатывать health check в gRPC?
Реализовать стандартный gRPC Health Checking протокол, сервер реализует Check с тем же принципом.

Как реализовать circuit breaker?

Краткий ответ (30–60 секунд)

Circuit Breaker предотвращает каскадные отказы, разрывая цепь вызовов к неисправному сервису. Имеет три состояния: Closed (норма), Open (быстрый отказ), Half-Open (пробный запрос). В Go реализуется счётчиком ошибок и таймером. Популярные библиотеки: sony/gobreaker, go-kit/circuitbreaker.

Развёрнутый ответ

Основные параметры: порог ошибок, интервал сброса, таймаут Open. Простая реализация:

type State int
const (Closed State = iota; Open; HalfOpen)

type CB struct {
    mu               sync.Mutex
    state            State
    failureCount     int
    threshold        int
    openTimeout      time.Duration
    openTime         time.Time
}
func (cb *CB) Call(fn func() error) error {
    cb.mu.Lock()
    if cb.state == Open {
        if time.Since(cb.openTime) > cb.openTimeout {
            cb.state = HalfOpen
            cb.mu.Unlock()
            goto halfOpen
        }
        cb.mu.Unlock()
        return ErrCircuitOpen
    }
    cb.mu.Unlock()
halfOpen:
    err := fn()
    cb.mu.Lock()
    if err != nil {
        cb.failureCount++
        if cb.failureCount >= cb.threshold || cb.state == HalfOpen {
            cb.state = Open
            cb.openTime = time.Now()
        }
    } else {
        cb.failureCount = 0
        cb.state = Closed
    }
    cb.mu.Unlock()
    return err
}

В реальных системах нужен учёт медленных ответов, частичных сбоев, изоляция по downstream-сервисам.

Под капотом (internals)

• Мьютекс защищает переходы состояний. При высокой частоте вызовов можно использовать атомарный счётчик и CAS, чтобы избежать блокировок.
• Обработка Half-Open: разрешается только один пробный запрос за раз, для этого используют дополнительный семафор.

Типичные ошибки кандидатов

1. Нет состояния Half-Open; после таймаута сразу переходят в Closed: если проблема осталась, происходит лавина повторных отказов.
   Почему неправильно: каждая волна запросов при переходе в Closed снова нагружает падающий сервис.
   Исправление: реализовать Half-Open с пробными запросами, при успехе переходить в Closed.

2. Общий circuit breaker на все сервисы: отказ одного downstream блокирует вызовы ко всем.
   Почему неправильно: излишняя блокировка здоровых сервисов.
   Исправление: отдельный экземпляр CB на каждый сервис/эндпоинт.

3. Игнорирование ошибок, которые не должны приводить к размыканию (например, 400 Bad Request): клиентская ошибка ложится в счётчик и размыкает цепь.
   Почему неправильно: ошибки клиента не индикатор неисправности сервиса, блокировка неоправдана.
   Исправление: классифицировать ошибки, считать только серверные (5xx) и таймауты.

Возможные дополнительные вопросы интервьюера

Как интегрировать circuit breaker с retry?
Retry внутри CB в Closed, при Open не пытаться, сразу ошибка. Обычно они используются совместно: retry с backoff, CB как предохранитель.

Чем CB отличается от bulkhead?
CB предотвращает вызовы при обнаружении отказа, bulkhead изолирует ресурсы (пулы потоков/соединений) для разных клиентов, чтобы один не занял всё.

Как протестировать переходы состояний?
Имитировать ошибки и успешные ответы, проверять изменение состояния после заданного числа.

Как реализовать bulkhead?

Краткий ответ (30–60 секунд)

Bulkhead изолирует ресурсы, чтобы отказ одной части не истощил все. В Go это раздельные пулы горутин/соединений на каждый downstream или клиент. Реализуется через семафоры (каналы) и отдельные worker pool'ы. Например, для каждого внешнего сервиса свой лимитера конкурентных запросов.

Развёрнутый ответ

Идея: ограничение числа одновременных вызовов к сервису A не влияет на вызовы к B. Пример:

type Bulkhead struct {
    sem chan struct{}
}

func NewBulkhead(concurrency int) *Bulkhead {
    return &Bulkhead{make(chan struct{}, concurrency)}
}

func (b *Bulkhead) Do(fn func() error) error {
    select {
    case b.sem <- struct{}{}:
        defer func() { <-b.sem }()
        return fn()
    default:
        return errors.New("bulkhead full")
    }
}

Для HTTP-клиентов можно настроить http.Transport с MaxConnsPerHost. Для входящих запросов — раздельные лимитеры на роуты. Библиотеки вроде go-resiliency/bulkhead.

Под капотом (internals)

• Буферизированный канал — эффективный семафор, быстрый.
• При использовании http.Transport.MaxConnsPerHost транспорт сам внутри управляет соединениями, не давая занять все сокеты.

Типичные ошибки кандидатов

1. Нет изоляции: все запросы проходят через один неограниченный пул горутин, и один медленный сервис заполняет все горутины, блокируя других.
   Почему неправильно: каскадный отказ из-за нехватки ресурсов.
   Исправление: установить лимиты на каждый клиент (bulkhead).

2. Слишком маленький лимит, вызывающий частые отказы даже при нормальной нагрузке: false positive.
   Почему неправильно: снижение доступности.
   Исправление: рассчитать лимит на основе метрик (latency, throughput) и тестировать.

3. Использование одного семафора для разных по природе операций (CPU-bound и IO-bound): неверный расчёт ресурсов.
   Почему неправильно: эффективная степень конкурентности для CPU и IO отличается.
   Исправление: разделять пулы, а ещё лучше — использовать асинхронные/неблокирующие подходы.

Возможные дополнительные вопросы интервьюера

Как реализовать bulkhead в асинхронной очереди (Kafka consumers)?
Ограничить число горутин-обработчиков на партицию; разные топики обрабатываются раздельными consumer группами, каждая со своим пулом.

Как сочетать bulkhead и circuit breaker?
Сначала bulkhead ограничивает параллелизм, затем внутри вызова может сработать circuit breaker. Это слои защиты.

Как динамически менять лимит в рантайме?
Можно использовать канал, но ёмкость канала фиксирована. Поэтому переходят на примитивы типа x/sync/semaphore.Weighted или управляемый счётчик с Cond.

Как реализовать feature flag?

Краткий ответ (30–60 секунд)

Feature flag (фича-флаг) — переключатель, позволяющий включать/выключать функциональность без выкатки кода. В Go это проверка булевого флага из конфигурации перед исполнением блока кода. Флаги могут быть глобальными, на пользователя, на процент. Используют библиотеки вроде launchdarkly, ff, или самописную конфигурацию с горячей перезагрузкой.

Развёрнутый ответ

Простой вариант:

if config.IsEnabled("new_search") {
    return newSearch(ctx, query)
}
return oldSearch(ctx, query)

Для A/B-тестирования к userID применяют хеш: hash(userID) % 100 < percent, что даёт консистентность. Флаги часто хранятся в конфигурационном файле или конфиг-сервере. Чтобы менять на лету, используют periodic poll или подписку на события (например, fsnotify для файлов, либо gRPC-стрим из config-сервиса).

Под капотом (internals)

• Логика проверки флага — быстрый доступ к map, защищённой sync.RWMutex или атомарный указатель на иммутабельную структуру конфига, обновляемую целиком (copy-on-write).
• Для процентного распределения используют некриптографический хеш (murmur3) для равномерности.

Типичные ошибки кандидатов

1. Проверка флага в middleware и зависимость от него на каждый запрос без кэширования: если чтение из файла каждый раз — огромный оверхед.
   Почему неправильно: ухудшение производительности.
   Исправление: загрузить конфиг в память и обновлять периодически.

2. Неудаляемые флаги, захламляющие код: после полного раската функциональность становится постоянной, а флаг остаётся мёртвым кодом.
   Почему неправильно: технический долг, усложнение понимания.
   Исправление: планировать очистку флагов после стабилизации, возможно автоматизировать.

3. Небезопасное изменение флага в рантайме без синхронизации: гонка при чтении-записи map.
   Почему неправильно: паника или некорректные значения.
   Исправление: использовать atomic.Value для всего конфига или sync.RWMutex.

Возможные дополнительные вопросы интервьюера

Как реализовать feature flag с таргетингом на конкретных пользователей (whitelist)?
Хранить список ID в конфиге; проверять наличие. Для больших списков применять bloom-фильтр.

Как обрабатывать ситуацию, когда фича-флаг отключён, а пользователь уже использовал новую функциональность и имеет данные нового формата?
Защита обратной совместимостью: код должен уметь читать и старый, и новый формат, в зависимости от флага.

Как протестировать обе ветки?
Параметризованные тесты, передавая флаг как аргумент.

Как реализовать graceful degradation?

Краткий ответ (30–60 секунд)

Graceful degradation — способность системы продолжать работу с уменьшенной функциональностью при сбоях зависимостей. В Go это означает: если недоступен сервис рекомендаций, показываем дефолтный список; если кэш упал, идём напрямую в БД. Реализуется через fallback-стратегии, дефолтные ответы, обёртки типа «попробовать, при ошибке вернуть заглушку».

Развёрнутый ответ

Пример:

func GetRecommendations(userID string) ([]Item, error) {
    recs, err := recService.Get(userID)
    if err != nil {
        log.Warn("recs unavailable, fallback to default")
        return defaultRecs, nil // деградация
    }
    return recs, nil
}

Более системно: паттерн «декоратор с fallback». Можно использовать circuit breaker, который при Open сразу возвращает fallback без попытки вызова. Важно явно определить, какие функции критичны, а какие можно деградировать.

Под капотом (internals)

• Fallback может быть статическим значением, кэшированным результатом из локального хранилища или упрощённым алгоритмом.
• Важно мониторить факты деградации метриками, чтобы знать, что часть функционала хромает.

Типичные ошибки кандидатов

1. Слишком широкий fallback, скрывающий серьёзные проблемы: постоянная тихая деградация, никто не замечает сбоя, пока всё не рухнет.
   Почему неправильно: отсутствие алертов, система может полностью отказать без предупреждения.
   Исправление: логировать, повышать alert при переходе на fallback выше порога.

2. Fallback возвращает ошибку вместо дефолтного значения: тогда это не деградация, а проброс ошибки выше.
   Почему неправильно: клиент получает отказ, предназначение деградации не достигнуто.
   Исправление: возвращать приемлемое значение, возможно с флагом «degraded», чтобы UI показал предупреждение.

3. Fallback приводит к каскадному отказу, например, возвращает пустой список, на который верхний сервис делает что-то затратное: всегда думать о последствиях.
   Почему неправильно: пустой список может инициировать полный пересчёт.
   Исправление: fallback должен быть безопасным (например, кэшированный результат).

Возможные дополнительные вопросы интервьюера

Как комбинировать graceful degradation с retry?
Retry на попытку получить нормальный ответ, после исчерпания попыток — fallback.

Как деградировать при превышении лимитов rate limit?
Вернуть урезанный ответ (например, без персонализации) или рекомендовать кэшированное.

Как тестировать graceful degradation?
Fault injection: подменяем зависимости на заглушки, возвращающие ошибки, и проверяем ответы.

Как реализовать дедупликацию сообщений?

Краткий ответ (30–60 секунд)

Дедупликация гарантирует, что одинаковое сообщение обрабатывается один раз. Обычно требует уникального идентификатора (idempotency key) на каждое сообщение. В Go сохраняем обработанные ID в in-memory map (с TTL) или во внешнее хранилище (Redis). При получении проверяем наличие ключа: если есть — игнорируем, иначе обрабатываем и добавляем ключ.

Развёрнутый ответ

Для очередей (Kafka, RabbitMQ) дедупликация может быть на уровне producer’а (гарантия exactly-once) или consumer’а. Реализация на стороне потребителя:

type Deduplicator struct {
    seen sync.Map
}
func (d *Deduplicator) IsDuplicate(id string) bool {
    _, loaded := d.seen.LoadOrStore(id, struct{}{})
    return loaded
}

Но sync.Map не решает проблему неограниченного роста и TTL. Продвинутый подход: хранить ключи в Redis с SET NX EX <ttl>. При этом важно атомарно проверить и записать, что SET NX и делает.

Для идемпотентности REST API клиент генерирует Idempotency-Key, сервер сохраняет пару ключ-ответ.

Под капотом (internals)

• sync.Map внутри использует два слоя: read-only map с быстрым доступом и dirty map, обновляемый под мьютексом. Подходит для ключей, которые редко меняются после записи. Для большого объёма лучше избегать, т.к. нет удаления старых ключей автоматически — память будет расти.
• Решение на Redis с TTL автоматически удаляет старые ключи, ограничивая память.

Типичные ошибки кандидатов

1. Отсутствие TTL у хранилища ключей, неограниченный рост памяти: в конце концов OOM.
   Почему неправильно: для долгоживущих сервисов объём уникальных ID растёт бесконечно.
   Исправление: использовать TTL равный максимальному времени жизни дубликатов (например, 24 часа), после которого дубликат не страшен.

2. Использование неидемпотентной операции после дедупликации без атомарности: ключ записан после обработки, а обработка может упасть, и при повторе сообщение не обработается, потому что ключ уже есть.
   Почему неправильно: потеря данных.
   Исправление: либо писать ключ до обработки (at-least-once), а обработку делать идемпотентной, либо использовать транзакцию «ключ + результат».

3. Игнорирование коллизий ID (использование некачественного источника уникальности): дубликаты по ошибке.
   Почему неправильно: ложная дедупликация.
   Исправление: ID должен быть достаточно длинным и случайным (UUID v4) или детерминированным от содержимого.

Возможные дополнительные вопросы интервьюера

Как дедуплицировать сообщения в распределённой системе без общей базы?
Использовать детерминированные ID на основе хеша содержимого, и тогда дубликаты подавляются естественным образом на любом экземпляре.

Что делать, если TTL истёк, а дубликат пришёл позже?
Это означает, что время возможного дублирования выбрано неверно; увеличить TTL или вообще пересмотреть гарантии.

Как реализовать дедупликацию в Kafka Streams?
Kafka Streams имеет встроенный механизм exactly-once семантики с транзакционными продюсерами и идемпотентными консьюмерами.

Как реализовать saga компенсацию?

Краткий ответ (30–60 секунд)

Saga — распределённая транзакция, состоящая из последовательности локальных транзакций с компенсационными действиями. В Go управление реализуется оркестратором, который вызывает сервисы и при сбое запускает обратные компенсационные шаги. Координация может быть хореографической (события) или оркестрованной (центральный координатор). Компенсации должны быть идемпотентными.

Развёрнутый ответ

Пример оркестратора:

type Saga struct {
    steps []Step
}
type Step struct {
    Action      func() error
    Compensate  func() error
}

func (s *Saga) Execute() error {
    executed := 0
    for i, step := range s.steps {
        if err := step.Action(); err != nil {
            // rollback выполненные шаги
            for j := i - 1; j >= 0; j-- {
                if compErr := s.steps[j].Compensate(); compErr != nil {
                    // log, критическая ошибка — ручное вмешательство
                }
            }
            return err
        }
        executed++
    }
    return nil
}

Компенсационные операции должны быть идемпотентными, так как их могут повторять при сбоях оркестратора. Часто используют асинхронные сообщения (Kafka) для надёжности: оркестратор публикует команды, слушает ответы.

Под капотом (internals)

• Оркестратор может хранить состояние саги в БД, чтобы восстановиться после сбоя. В Go это может быть объект, сериализованный в JSON, с текущим шагом.
• При событийной хореографии каждый сервис подписывается на события и публикует свои, компенсационные события обрабатываются другими сервисами.

Типичные ошибки кандидатов

1. Компенсация не идемпотентна, и при повторном вызове ухудшает состояние: например, возврат денег дважды.
   Почему неправильно: финансовые потери, нарушение консистентности.
   Исправление: проектировать компенсацию на основе уникального ID операции (idempotency key) и проверять, не была ли уже применена.

2. Отсутствие обработки ошибок компенсации: оркестратор просто логирует и идёт дальше — данные остаются в несогласованном состоянии.
   Почему неправильно: система в подвешенном состоянии.
   Исправление: повторять компенсацию с backoff, в крайнем случае уведомлять администратора, сохранять в dead-letter.

3. Сага без сохранения состояния оркестратора: при падении процесса теряется прогресс, и неизвестно, какие шаги выполнены.
   Почему неправильно: невозможность корректно завершить или откатить.
   Исправление: персистентное хранение состояния саги, возможно в базе данных.

Возможные дополнительные вопросы интервьюера

Как гарантировать, что компенсация будет выполнена ровно один раз в асинхронной среде?
Использовать очереди с гарантией доставки и идемпотентностью обработчиков; outbox-паттерн для публикации событий компенсации.

Чем хореография лучше оркестрации?
Уменьшает связанность, нет единой точки отказа оркестратора. Но усложняет отслеживание общего процесса.

Как тестировать саги?
Модульно тестировать шаги и компенсации; интеграционно — имитировать сбои в разных точках и проверять восстановление.

Как реализовать двухфазный коммит (2PC)?

Краткий ответ (30–60 секунд)

Двухфазный коммит — протокол распределённых транзакций с координатором и участниками. Фаза 1 (prepare): координатор просит участников подготовиться (заблокировать ресурс) и голосовать yes/no. Фаза 2 (commit/rollback): если все согласны, координатор рассылает commit; иначе — rollback. В Go реализуем координатора с временными таблицами/логами, участников с методами Prepare/Commit/Rollback. Обычно используют глобальные транзакции через XA или специализированные БД.

Развёрнутый ответ

Упрощённая реализация координатора в памяти:

type Coordinator struct {
    participants []Participant
}
type Participant interface {
    Prepare() error
    Commit() error
    Rollback() error
}

func (c *Coordinator) Execute() error {
    for _, p := range c.participants {
        if err := p.Prepare(); err != nil {
            // rollback all previously prepared
            for _, prev := range c.participants[:?] { prev.Rollback() }
            return err
        }
    }
    for _, p := range c.participants {
        if err := p.Commit(); err != nil {
            // после Prepare commit не должен фейлиться, но если да — тяжелый случай
        }
    }
    return nil
}

В реальных системах координатор пишет журнал решений (write-ahead log) и может восстановиться после отказа. Участники после prepare обязаны быть готовыми как commit, так и rollback. 2PC редко применяется из-за блокировок и проблем с доступностью; чаще предпочитают саги.

Под капотом (internals)

• Участники, реализующие Prepare, обычно блокируют ресурсы (например, строки в БД) до завершения транзакции.
• В Go координатор может быть внешним сервисом с хранением лога транзакций в etcd или собственной БД.

Типичные ошибки кандидатов

1. Игнорирование того, что после Prepare участник должен гарантировать возможность commit: если Prepare прошёл, а commit падает из-за ошибки, восстановление сложное.
   Почему неправильно: нарушение протокола, данные остаются неконсистентными.
   Исправление: проектировать так, чтобы Commit был гарантированно успешен после успешного Prepare (сохранив всё необходимое на диск).

2. Отсутствие журнала координатора: при отказе координатора в фазе 2 участники остаются в подвешенном состоянии, блокировки не снимаются.
   Почему неправильно: ресурсы заблокированы, пока администратор не вмешается.
   Исправление: координатор должен писать лог решений, при восстановлении продолжать транзакцию.

3. Использование 2PC для длительных операций с участием человека: длительные блокировки недопустимы.
   Почему неправильно: конкуренция и время удержания блокировок убивают производительность.
   Исправление: применять Sagas с компенсациями.

Возможные дополнительные вопросы интервьюера

Как 2PC связан с XA-транзакциями?
XA — стандарт, реализующий 2PC для распределённых транзакций между менеджерами ресурсов (БД, очереди). В Go через драйверы, поддерживающие XA (например, некоторые БД).

Почему в микросервисах избегают 2PC?
Из-за сильной связанности, блокировок и снижения доступности (CAP — выбираем availability, а не consistency).

Можно ли реализовать 2PC асинхронно?
Да, через асинхронную отправку сообщений, но протокол остаётся блокирующим по сути.

Как реализовать распределенный таймер (distributed timer)?

Краткий ответ (30–60 секунд)

Распределённый таймер позволяет отложить выполнение задачи на заданное время в системе из нескольких узлов, без привязки к конкретному экземпляру. Реализуется через внешнее хранилище с поддержкой отложенных заданий: Redis (ZSET с score = время исполнения, периодическая выборка), БД с ScheduledAt, или специализированные решения вроде Quartz. В Go пишут планировщик, который конкурентно забирает готовые задачи и выполняет.

Развёрнутый ответ

Redis-подход:

• Добавление: ZADD delayed_tasks <timestamp> <taskPayload>.
• Планировщик: горутина крутится в цикле, вызывает ZRANGEBYSCORE delayed_tasks 0 <now> LIMIT 0 N, получив задачи, атомарно удаляет (например, через Lua-скрипт с проверкой). Выполняет задачу.
• Для гарантии доставки используют надёжные очереди (Kafka) с задержкой.

Другой вариант — БД с полем execute_at, и конкурентный SELECT ... FOR UPDATE SKIP LOCKED для выборки задач (с ограничением). Это надёжнее.

Под капотом (internals)

• Redis ZSET — skiplist + hash, score — double. ZRANGEBYSCORE по времени — O(log N + M).
• Lua-скрипт ZPOPMIN атомарно извлекает и удаляет первые элементы.
• При использовании БД, SELECT ... FOR UPDATE SKIP LOCKED позволяет нескольким воркерам параллельно забирать задачи без блокировок. В Go pgx/database/sql поддерживают.

Типичные ошибки кандидатов

1. Гонка при выборке и удалении без атомарности: два воркера забирают одну задачу, дублируется выполнение.
   Почему неправильно: дублирование отправки уведомлений/платежей.
   Исправление: использовать атомарную операцию (Redis Lua-скрипт ZPOPMIN или SELECT ... FOR UPDATE SKIP LOCKED с последующим удалением).

2. Отсутствие перезахоронения (requeue) при ошибке выполнения: задача теряется.
   Почему неправильно: потеря данных.
   Исправление: при ошибке возвращать задачу в таймер с увеличенной задержкой или в dead-letter, но не удалять.

3. Часы узлов рассинхронизированы, таймер срабатывает не вовремя: используется локальное время.
   Почему неправильно: задачи могут выполниться раньше или позже расчётного.
   Исправление: ориентироваться на монотонное время сервера (Redis/Broker), либо использовать NTP для синхронизации.

Возможные дополнительные вопросы интервьюера

Как масштабировать обработку отложенных задач?
Увеличивать количество воркеров, забирающих задачи пачками; шардировать ключи заданий по хешу для распределения нагрузки на Redis.

Как реализовать точный таймер с миллисекундной точностью?
Для точных задержек используют time.Timer на одном узле, но распределённо сложно; можно использовать иерархические Timing Wheels, но в Go обычно достаточно Redis.

Как отменить отложенную задачу?
Удалить ключ из ZSET; если уже выполняется, то через механизм отмены (context) в самом обработчике.

Как реализовать систему отложенных задач (delayed queue)?

Краткий ответ (30–60 секунд)

Отложенная очередь позволяет отложить обработку сообщения на заданное время. В Go часто используют Redis с sorted set (как распределённый таймер) или готовые очереди с поддержкой задержки (RabbitMQ delayed message exchange, Amazon SQS delay). Самописно реализуется горутиной, которая перекладывает созревшие задачи из отсортированного множества в рабочую очередь.

Развёрнутый ответ

Шаблон на Redis:

1. delayQ — ZSET с полем taskID и score = время выполнения.
2. Фоновый процесс раз в секунду вызывает Lua-скрипт: ZRANGEBYSCORE delayQ 0 NOW LIMIT 0 100 и для каждого перемещает в рабочий список LPUSH workQ и удаляет из ZSET.
3. Воркеры читают workQ (по сути обычный список) и обрабатывают.

Код Lua атомарно перемещает, гарантируя однократную доставку. Альтернатива — Kafka без встроенной задержки, где потребитель сам откладывает offset с помощью паузы или перекладывает в другой топик с таймером.

Под капотом (internals)

• Redis Lua выполняется атомарно, блокируя другие операции — для маленьких скриптов допустимо.
• Использование time.Timer в Go на каждом экземпляре привело бы к рассинхронизации; централизованное хранилище — основа.

Типичные ошибки кандидатов

1. Периодический опрос без учёта часового дрейфа: полагаются на time.Sleep и локальное время, что приводит к неравномерным интервалам и возможному запаздыванию.
   Почему неправильно: таймеры накапливают дрейф, задачи выполняются с ошибкой.
   Исправление: использовать единый источник времени (сервер Redis) и опрашивать на основе его времени.

2. Задачи застревают в ZSET из-за ошибки скрипта перемещения и не обрабатываются: нет мониторинга размера delayQ.
   Почему неправильно: потеря заданий.
   Исправление: метрики и алерты на размер delayQ старше определённого времени.

3. Нет перезапуска при падении воркера-планировщика: единственная горутина перемещения — SPOF.
   Почему неправильно: при падении задержанные задачи никто не двигает.
   Исправление: запускать несколько планировщиков с одинаковой логикой, но атомарное перемещение исключит дубли.

Возможные дополнительные вопросы интервьюера

В чём разница между delayed queue и планировщиком?
Очередь задержки — частный случай, задача выполняется однократно в будущем. Планировщик может поддерживать cron-выражения и повторяющиеся задачи.

Как сделать задержку с произвольной точностью (например, секунда)?
Использовать Redis с score в миллисекундах и опрашивать каждую секунду, но точность ограничена интервалом опроса.

Можно ли реализовать delayed queue без внешних зависимостей в одном процессе?
Да, с помощью container/heap и time.Timer, но при перезапуске задачи потеряются — только для некритичных сценариев (in-memory).

Как реализовать поиск по префиксу (prefix search)?

Краткий ответ (30–60 секунд)

Поиск по префиксу в Go реализуется через префиксное дерево (trie) или сортированный массив с бинарным поиском. Для in-memory применяют github.com/google/tink/go/tink? Нет, подойдёт структура trie: каждый узел содержит дочерние map[byte]*Node и флаг завершения. При поиске проходим по символам, собираем все слова в поддереве. Альтернатива — radix tree (сжатый trie) для экономии памяти.

Развёрнутый ответ

Простой trie:

type TrieNode struct {
    children map[byte]*TrieNode
    isEnd    bool
}

type Trie struct {
    root TrieNode
}

func (t *Trie) Insert(word string) {
    node := &t.root
    for i := 0; i < len(word); i++ {
        ch := word[i]
        if node.children[ch] == nil {
            node.children[ch] = &TrieNode{children: make(map[byte]*TrieNode)}
        }
        node = node.children[ch]
    }
    node.isEnd = true
}

func (t *Trie) SearchPrefix(prefix string) []string {
    node := &t.root
    for i := 0; i < len(prefix); i++ {
        if node.children[prefix[i]] == nil {
            return nil
        }
        node = node.children[prefix[i]]
    }
    return collectWords(node, prefix)
}

Для больших объёмов, не помещающихся в память, используют B-tree на диске или используют префиксный индекс в Elasticsearch/Postgres GIN.

Под капотом (internals)

• Trie требует много памяти на указатели. Radix tree объединяет узлы с одним потомком, снижая потребление.
• Go map для детей добавляет оверхед, но даёт O(1) переход. Альтернатива — массив на 26 символов для ASCII. При Unicode нужна обобщённая структура.

Типичные ошибки кандидатов

1. Использование слайса для детей и линейный поиск за O(alphabet) — для больших алфавитов медленно.
   Почему неправильно: при Unicode алфавит огромный, деградация.
   Исправление: использовать map или сбалансированное дерево.

2. Сбор всех слов в поддереве без учёта глубины, что может привести к огромному результату: OOM, если поддерево содержит миллионы слов.
   Почему неправильно: неограниченный ответ, клиент может повесить сервер.
   Исправление: лимитировать количество возвращаемых слов (например, top-K), использовать итератор.

3. Забывают, что prefix — это строка, и при итерации по байтам корректно работает только для ASCII, для UTF-8 нужен подход с рунами: обход по байтам для мультибайтных символов нарушит переходы.
   Почему неправильно: поиск по префиксу из Unicode-символов сломается, не найдет нужные.
   Исправление: работать с рунами или использовать byte для UTF-8 (но тогда префикс — набор байт, что тоже корректно, если trie хранит побайтово). Но стандартная практика — хранить байты, и поиск префикса работает byte-wise.

Возможные дополнительные вопросы интервьюера

Как реализовать автодополнение с учётом частотности?
В trie хранить топ-N популярных слов в каждом узле, и возвращать отсортированные по частоте.

Как обновлять trie конкурентно?
Использовать sync.RWMutex на весь trie, либо мелкогранулярные блокировки на узлах (сложно). Для read-heavy нагрузок подходит copy-on-write trie.

Как искать с опечатками?
Использовать нечёткий поиск, например, алгоритм расстояния Левенштейна, но это уже не просто prefix search.

Как реализовать топ-К элементов?

Краткий ответ (30–60 секунд)

Топ-K элементов извлекает K наибольших/наименьших из потока данных. Используется min-heap (для top-K максимумов) или max-heap (для минимумов) фиксированного размера K. В Go container/heap или сортировка срезов. Если данных много (стриминг), то heap размера K с O(N log K). Если N огромно, применяют приближённые алгоритмы (Count-Min Sketch + heap).

Развёрнутый ответ

Пример top-K максимальных чисел:

type MinHeap []int
func (h MinHeap) Len() int { return len(h) }
func (h MinHeap) Less(i,j int) bool { return h[i] < h[j] } // min-heap
func (h MinHeap) Swap(i,j int) { h[i], h[j] = h[j], h[i] }
func (h *MinHeap) Push(x interface{}) { *h = append(*h, x.(int)) }
func (h *MinHeap) Pop() interface{} { old:=*h; n:=len(old); x:=old[n-1]; *h=old[:n-1]; return x }

func topK(stream []int, k int) []int {
    h := &MinHeap{}
    heap.Init(h)
    for _, v := range stream {
        if h.Len() < k {
            heap.Push(h, v)
        } else if v > (*h)[0] {
            heap.Pop(h)
            heap.Push(h, v)
        }
    }
    // в куче теперь k наибольших
    return *h
}

Для частотного анализа (top-K частых слов) используют map + heap.

Под капотом (internals)

• container/heap работает поверх слайса, push/pop — O(log K).
• При очень большом K и потоке можно применять сортировку слиянием и выбирать K.

Типичные ошибки кандидатов

1. Сортировка всего массива и взятие первых K: O(N log N) вместо O(N log K), память O(N) вместо O(K).
   Почему неправильно: для миллиарда записей неэффективно.
   Исправление: использовать min-heap фиксированного размера.

2. Путаница с кучей для top-K максимальных: если использовать max-heap, то нужен будет max-heap размера N, что неправильно: нужно min-heap размера K, чтобы хранить K пока что наибольших: минимальный из них — порог.
   Почему неправильно: при использовании max-heap на К элементах мы будем вытеснять максимальный, оставляя маленькие.
   Исправление: для top-K максимумов использовать min-heap, для top-K минимумов max-heap.

3. Не учтены равные элементы, дубликаты: может исказить top-K, если требуется уникальные; алгоритм должен учитывать.
   Почему неправильно: бизнес-логика может требовать уникальность (топ пользователей).
   Исправление: предварительно агрегировать map, либо модифицировать условие входа в кучу.

Возможные дополнительные вопросы интервьюера

Как получить top-K в распределённой системе?
Каждый узел считает свои локальные top-K и отправляет координатору, который объединяет результаты, снова применяя кучу.

Как оптимизировать при очень большом K, но доступной памяти?
Использовать алгоритм Quickselect (среднее время O(N)), если K велико.

Что делать, если поток бесконечен и нужна оценка частот?
Применить Count-Min Sketch для приблизительных частот, затем heap для top-K.

Как реализовать согласованное хеширование (consistent hashing)?

Краткий ответ (30–60 секунд)

Согласованное хеширование минимизирует количество перемещаемых ключей при добавлении/удалении узлов. Ключи и узлы хешируются в одно кольцо (хеш-пространство). Ключ назначается ближайшему узлу по часовой стрелке. В Go реализуется сортированным слайсом хешей узлов (с виртуальными нодами) и бинарным поиском. Библиотеки: stathat/consistent, serialx/hashring.

Развёрнутый ответ

Основа:

type ConsistentHash struct {
    ring     []int          // отсортированные хеши виртуальных нод
    nodes    map[int]string // хеш -> имя реального узла
    replicas int
}

func (c *ConsistentHash) Add(node string) {
    for i := 0; i < c.replicas; i++ {
        hash := hashFunc(fmt.Sprintf("%s%d", node, i))
        c.ring = append(c.ring, hash)
        c.nodes[hash] = node
    }
    sort.Ints(c.ring)
}

func (c *ConsistentHash) Get(key string) string {
    hash := hashFunc(key)
    idx := sort.SearchInts(c.ring, hash)
    if idx >= len(c.ring) { idx = 0 }
    return c.nodes[c.ring[idx]]
}

Количество виртуальных реплик (replicas) сглаживает дисбаланс распределения (типично 100-200 на узел). Без виртуальных нод при малом числе узлов распределение неравномерно.

Под капотом (internals)

• Хеш-функция (например, CRC32, fnv, или Murmur3) даёт uint32/64. sort.SearchInts — бинарный поиск O(log N). Кольцо — массив.
• При добавлении узла перераспределяются только ключи, чей хеш меньше хеша нового узла на кольце.

Типичные ошибки кандидатов

1. Отсутствие виртуальных нод или их слишком мало: приводит к «горячим» точкам и неравномерной нагрузке.
   Почему неправильно: один узел может получить непропорционально много ключей.
   Исправление: добавлять виртуальные ноды (150-200) и оценивать распределение.

2. Использование слабой хеш-функции с плохим распределением: возникают коллизии, непредсказуемость.
   Почему неправильно: некоторые узлы могут вообще не получить ключей.
   Исправление: выбрать качественную хеш-функцию (murmur3) с равномерным распределением.

3. Не обновляют кольцо конкурентно-безопасно: map и слайс мутируют без блокировок под нагрузкой, паника.
   Почему неправильно: гонка данных.
   Исправление: защитить мьютексом или использовать atomic.Value с неизменяемым снэпшотом (copy-on-write), т.к. поиск происходит часто.

Возможные дополнительные вопросы интервьюера

Как обеспечить минимальную задержку при частых обновлениях кольца?
Использовать copy-on-write: создать новое кольцо и атомарно подменить указатель; поиск без блокировки.

Как согласованное хеширование работает с физической географией (гео-реплицированные кольца)?
Можно добавить веса узлов, учитывая задержку, но обычно используют отдельные кольца на регион.

Чем consistent hashing лучше обычного modulo N?
При изменении N перемещается только часть ключей (K/N в среднем) вместо всех.

Как реализовать gossiping протокол для обнаружения узлов кластера?

Краткий ответ (30–60 секунд)

Gossip-протокол распространяет информацию о состоянии узлов путём периодического обмена с случайными соседями (peer sampling). Каждый узел хранит membership list и увеличивает version при изменении. Периодически рассылает дайджест соседу, получает обновления, объединяет. Реализуется с помощью UDP/TCP, в Go — горутина-цикл с таймером и случайный выбор пира. Используют библиотеки вроде hashicorp/memberlist.

Развёрнутый ответ

Упрощённая модель:

type Gossiper struct {
    self    Node
    members map[string]Node // nodeID -> node info
    mu      sync.RWMutex
}
func (g *Gossiper) gossip() {
    ticker := time.NewTicker(1 * time.Second)
    for range ticker.C {
        peer := g.randomPeer()
        if peer != nil {
            g.pushPull(peer)
        }
    }
}
func (g *Gossiper) pushPull(peer Node) {
    // отправить свой members list (или его дайджест) peer'у; получить ответ и смержить
}

Для обнаружения новых узлов используют seed nodes. Для удаления мёртвых узлов применяют подозрение (suspicion mechanism) с таймаутами, затем объявляют dead и исключают.

Надёжная реализация — memberlist от HashiCorp: настраиваемый протокол с шифрованием, делегатами для событий join/leave.

Под капотом (internals)

• memberlist использует UDP для быстрых сообщений и TCP для синхронизации состояния. Внутри — SWIM-подобный протокол с piggybacking'ом обновлений.
• В Go можно писать свой велосипед, используя net и protobuf для сериализации.

Типичные ошибки кандидатов

1. Отсутствие механизма подозрения (suspicion) — сетевой сбой немедленно удаляет узел: ложные исключения при временной недоступности.
   Почему неправильно: добавление удаленного узла обратно требует дорогостоящих перестроек (перераспределение партиций).
   Исправление: ввести таймауты подтверждения косвенных пиков — suspicion timeout, dead timeout.

2. Лавина трафика при большом кластере: gossip каждый раз пересылает полный membership list: O(N^2) трафик.
   Почему неправильно: сеть перегружается.
   Исправление: отправлять только изменения (инкрементальные обновления) с версиями, периодически делать полную синхронизацию с одним пиром.

3. Не защищены от подделки: отсутствие проверки источника сообщений.
   Почему неправильно: злоумышленник может внедрить ложные узлы.
   Исправление: использовать подписанные сообщения или внутрикластерный ключ.

Возможные дополнительные вопросы интервьюера

Какую гарантию консистентности даёт gossip?
Eventual consistency; все узлы со временем сходятся к одному представлению.

Как быстро обнаруживается отказ узла?
Зависит от периода gossip, числа раундов до подозрения; типично ~несколько секунд.

Как gossip протокол помогает в leader election?
Может использоваться для распространения информации о текущем лидере; сам по себе не выбирает лидера, но является строительным блоком консенсуса.

Как реализовать singleflight (x/sync/singleflight)?

Краткий ответ (30–60 секунд)

Singleflight предотвращает множественные одновременные вызовы дорогой функции для одного и того же ключа: первый вызов запускает операцию, остальные ждут и получают тот же результат. В Go пакет golang.org/x/sync/singleflight предоставляет Group.Do(key, fn). Он дедуплицирует вызовы в пределах одного процесса.

Развёрнутый ответ

Использование:

var g singleflight.Group

func fetchURL(url string) ([]byte, error) {
    v, err, _ := g.Do(url, func() (interface{}, error) {
        return httpGet(url)
    })
    if err != nil {
        return nil, err
    }
    return v.([]byte), nil
}

Do блокирует все горутины с одинаковым ключом до завершения первого вызова, затем все получают один и тот же результат (и ошибку). Есть также DoChan для асинхронного ожидания через канал.

Это критично для предотвращения «thundering herd» при промахах кэша.

Под капотом (internals)

• singleflight.Group содержит map[string]*call и sync.Mutex. call содержит счётчик ожидающих, результат и канал для пробуждения, когда результат готов.
• При Do захватывается мьютекс: если ключ есть, инкрементируется число ожидающих, горутина отпускает мьютекс и ждёт на канале. Первый горутин вызывает функцию, после завершения сохраняет результат, закрывает канал, пробуждая всех.
• Важно: если fn паникует, singleflight считает call выполненным, и паника распространяется только на вызывавшую горутину? Нет: при панике внутри Do она случается внутри горутины, которая выполняет fn; остальные находятся в ожидании канала. Если паника не обработана, программа падает. Рекомендация — не паниковать.

Типичные ошибки кандидатов

1. Использование singleflight для операций, которые возвращают недетерминированный результат (текущее время): все вызовы получают одинаковое, возможно устаревшее, значение.
   Почему неправильно: потеря точности, клиенты ожидают актуальные данные.
   Исправление: применять только к идемпотентным и детерминированным (по ключу) операциям, либо сбрасывать кэш.

2. Забывают про таймаут: если выполнение fn зависает, все ждущие зависают навсегда.
   Почему неправильно: утечка горутин, деградация сервиса.
   Исправление: передавать контекст, использовать DoChan с select по ctx.Done().

3. Чрезмерное использование, превращение в неявный кэш: singleflight не имеет TTL, результат не удаляется, но последующие вызовы после завершения Do не кешируются. Однако если постоянно вызывают с одинаковым ключом, это вызывает только первый раз fn, последующие ждут — это правильно, но может создать контенцию на мьютексе.
   Почему неправильно: если ключ горячий и fn завершается быстро, мьютекс становится узким местом.
   Исправление: дополнить кэшем (например, std/sync.Pool или timed cache).

Возможные дополнительные вопросы интервьюера

Как реализовать singleflight с TTL?
Комбинировать с кэшем с истечением: в Do проверить кэш, если свежий — вернуть; иначе вызвать fn.

Как singleflight работает в распределённой среде?
Не работает, только в рамках одного процесса. Для распределённой дедубликации нужен внешний координатор (Redis/etcd).

Можно ли использовать singleflight для защиты БД от одинаковых запросов?
Да, идеальный сценарий: сотня горутин запрашивают один и тот же ключ из БД при промахе кэша, singleflight делает только один SQL-запрос.

Как реализовать журналирование изменений (audit log)?

Краткий ответ (30–60 секунд)

Аудит-лог фиксирует, кто, когда и что сделал. В Go реализуется middleware/перехватчиками, которые после выполнения действия пишут запись в хранилище (БД, файл, Elastic). Запись содержит субъект, действие, объект, временную метку, результат. Лог должен быть защищён от подделки (append-only, контрольные суммы). Оформляют как отдельный асинхронный сервис или горутину, чтобы не тормозить основной поток.

Развёрнутый ответ

Пример через интерфейс:

type AuditLogger interface {
    Log(ctx context.Context, entry AuditEntry) error
}

type AuditEntry struct {
    Timestamp time.Time
    UserID    string
    Action    string
    Resource  string
    Result    string
}

func AuditMiddleware(logger AuditLogger) func(next Handler) Handler {
    return func(next Handler) Handler {
        return func(ctx context.Context, req Request) Response {
            resp := next(ctx, req)
            go logger.Log(ctx, AuditEntry{
                Timestamp: time.Now(),
                UserID:    ctx.UserID(),
                Action:    "Update",
                Resource:  req.Resource,
                Result:    resp.Status,
            })
            return resp
        }
    }
}

Асинхронная запись через горутину может потеряться при падении. Надёжнее — отправлять в persistence очередь или писать синхронно в локальный файл с rotation.

Безопасность: логи должны быть неизменяемыми. Используют append-only структуры, блокчейн-подобные цепочки хешей или хранят в WORM-хранилище.

Под капотом (internals)

• При использовании go logger.Log(...) запускается новая горутина. При высокой нагрузке количество горутин может расти; лучше пул воркеров.
• Асинхронная запись в файл через буферизированный writer; при graceful shutdown необходимо дождаться сброса.

Типичные ошибки кандидатов

1. Логирование синхронно в hot path (на каждый запрос синхронная вставка в БД): убивает latency.
   Почему неправильно: блокирует обработку запросов, снижает RPS.
   Исправление: вынос в асинхронный сервис или пакетную запись.

2. Потеря логов при падении без финализации: горутина не успевает записать.
   Почему неправильно: аудит-следы исчезают, нарушение compliance.
   Исправление: использовать надёжную доставку (каналы с подтверждением, WAL на диске).

3. Не включают идентификатор запроса/трассировки в аудит-запись: невозможно связать события.
   Почему неправильно: усложнение расследования инцидентов.
   Исправление: всегда пробрасывать trace ID в контекст и сохранять.

Возможные дополнительные вопросы интервьюера

Как гарантировать неизменяемость аудит-логов?
Размещать в append-only файловой системе, подписывать записи цифровой подписью, хранить в blockchain или использовать сервисы вроде AWS CloudTrail.

Как обрабатывать огромный объём аудит-логов?
Использовать потоковую обработку (Kafka → consumer → агрегация в колоночное хранилище).

Как проверить целостность логов после инцидента?
Если включены цепочки хешей или подписи, пересчитать и сравнить.

Как реализовать параллельный обход дерева?

Краткий ответ (30–60 секунд)

Параллельный обход дерева может использовать пул горутин, обрабатывающих поддеревья независимо. Удобно применять паттерн fan-out: для каждого дочернего узла запускаем горутину (если дерево большое, семафор). Результаты собираются через канал или WaitGroup. Важно следить за балансировкой — для вырожденных деревьев параллелизм мал. Применяют рекурсивное разделение.

Развёрнутый ответ

Пример параллельного подсчёта суммы значений в бинарном дереве:

func parallelSum(root *Node, maxDepth int, depth int) int {
    if root == nil { return 0 }
    if depth >= maxDepth {
        return sequentialSum(root) // перестаём распараллеливать
    }
    var sum int
    var mu sync.Mutex
    var wg sync.WaitGroup
    traverse := func(node *Node, d int) {
        defer wg.Done()
        s := parallelSum(node, maxDepth, d)
        mu.Lock()
        sum += s
        mu.Unlock()
    }
    if root.Left != nil {
        wg.Add(1)
        go traverse(root.Left, depth+1)
    }
    if root.Right != nil {
        wg.Add(1)
        go traverse(root.Right, depth+1)
    }
    sum += root.Val
    wg.Wait()
    return sum
}

Используется ограничение глубины распараллеливания, чтобы избежать миллионов горутин для гигантских деревьев. Подход «divide and conquer» с порогом.

Под капотом (internals)

• Каждая горутина — лёгкая, но при сотнях тысяч они начинают давить на планировщик. Порог и семафор важны.
• Мьютекс в примере — простая защита общего счётчика; можно использовать atomic.Int64.

Типичные ошибки кандидатов

1. Неограниченное создание горутин на каждый узел: десятки тысяч горутин — перегрузка планировщика, большой стековый overhead.
   Почему неправильно: хотя горутины дёшевы, при миллионах узлов память закончится быстро.
   Исправление: ограничить глубину распараллеливания и число активных горутин семафором.

2. Нет балансировки нагрузки: один поток обрабатывает огромное поддерево, другой маленькое: неравномерное использование CPU.
   Почему неправильно: общее время сильно не уменьшится.
   Исправление: использовать work-stealing или разделение на подзадачи с пулом воркеров.

3. Рекурсивный вызов parallelSum в горутине, не копируя переменные цикла/параметры: захват изменяющихся переменных (если бы цикл) — классическая бага.
   Почему неправильно: в Go до 1.22 переменная цикла была общей, сейчас по-другому, но лучше передавать явно.
   Исправление: передавать параметры в функцию или использовать node := node при замыкании (до 1.22).

Возможные дополнительные вопросы интервьюера

Как параллельно обойти дерево и вернуть результаты в порядке in-order?
Собрать результаты и отсортировать по порядковым номерам; либо использовать каналы, но порядок усложняется.

Как обойти граф параллельно с учётом циклов?
Использовать visited map и синхронизацию, например, sync.Map или канал для дублирования запросов на обработку узла не более раза.

Как реализовать параллельный обход с ограниченным числом горутин?
Добавить семафор (make(chan struct{}, N)), захватывать перед запуском горутины и освобождать после завершения.

Как реализовать конкурентный map-filter-reduce?

Краткий ответ (30–60 секунд)

Map-filter-reduce — функциональные операции над коллекциями. В Go конкурентно: входной слайс разделяется на батчи, каждый обрабатывается горутиной. Результаты map собираются в один слайс (через канал или индексацию). Filter отбрасывает ненужные. Reduce агрегирует частичные результаты. Для координации используют sync.WaitGroup, каналы, семафоры.

Развёрнутый ответ

Пример конкурентного MapReduce:

func ConcurrentMapReduce[T, U, V any](input []T, mapper func(T) U, reducer func(U, U) U) U {
    n := runtime.NumCPU()
    chunkSize := (len(input) + n - 1) / n
    var wg sync.WaitGroup
    results := make([]U, n) // промежуточный результат по чанкам
    for i := 0; i < n; i++ {
        start := i * chunkSize
        end := start + chunkSize
        if end > len(input) { end = len(input) }
        if start >= end { continue }
        wg.Add(1)
        go func(idx, s, e int) {
            defer wg.Done()
            var acc U // zero value
            for j := s; j < e; j++ {
                mapped := mapper(input[j])
                if j == s {
                    acc = mapped
                } else {
                    acc = reducer(acc, mapped)
                }
            }
            results[idx] = acc
        }(i, start, end)
    }
    wg.Wait()
    // reduce комбинированных результатов
    var final U
    for i, r := range results {
        if i == 0 {
            final = r
        } else {
            final = reducer(final, r)
        }
    }
    return final
}

Для фильтрации можно добавить проверку внутри маппера (возвращать специальное значение) или создавать промежуточные слайсы.

Под капотом (internals)

• Копирование входных данных по чанкам не делаем, просто читаем из общего слайса — безопасно, т.к. только чтение.
• При асинхронном сборе через каналы горутины отправляют результаты, но тогда нужно следить за порядком. Индексация по позиции чанка проще.

Типичные ошибки кандидатов

1. Забывают, что reducer может быть неассоциативным: параллельный reduce даст разный результат в зависимости от порядка.
   Почему неправильно: математически нарушается ожидаемый результат (например, деление вместо сложения).
   Исправление: требовать ассоциативности reducer’а или применять детерминированный порядок.

2. Создание горутины на каждый элемент: огромные накладные расходы.
   Почему неправильно: для 1 млн элементов — 1 млн горутин, память и планировщик не справятся.
   Исправление: батчинг, число горутин ограничено (NumCPU или семафор).

3. Гонка при записи в общий слайс результатов без синхронизации: несколько горутин пишут в одну ячейку — не всегда проявляется, но потенциально.
   Почему неправильно: нет гарантий атомарности записи в слайс.
   Исправление: выделять уникальный индекс для каждой горутины, либо использовать канал или sync.Mutex.

Возможные дополнительные вопросы интервьюера

Как обработать ошибки внутри map?
Использовать errgroup; при первой ошибке отменять контекст и возвращать ошибку.

Как улучшить производительность для больших данных, не влезающих в память?
Использовать потоковую обработку (channel-based pipeline) с ограниченными буферами.

Как реализовать конкурентный map для интерфейсов?
Аналогично с дженериками или interface{}.

Как реализовать merge sort слиянием из нескольких файлов?

Краткий ответ (30–60 секунд)

Сортировка слиянием нескольких файлов (external merge sort) — алгоритм для данных, не влезающих в память. Файлы читаются последовательно, создаются отсортированные чанки (sorted runs). Затем многопутевое слияние с использованием min-heap для выбора наименьшего элемента из текущих позиций файлов. В Go — reader с буферизацией, heap из записей (элемент, индекс файла), сборка в выходной файл.

Развёрнутый ответ

Алгоритм:

1. Читаем большой файл по кускам, сортируем в памяти, пишем во временные файлы чанки.
2. Открываем все чанки для чтения; используем кучу:

type Item struct {
    value string
    fileIndex int
}

type PriorityQueue []Item
// heap.Interface

Инициализируем кучу первыми элементами каждого файла. В цикле Pop наименьший, записываем в выходной файл, читаем следующий элемент из того же файла и Push.
3. Когда файл исчерпан, куча уменьшается. Процесс продолжается до опустошения кучи.

Под капотом (internals)

• Используются bufio.Scanner или bufio.Reader для эффективного чтения.
• Многопутевое слияние с кучей O(N log K), где K — число чанков, N — общее кол-во записей.
• Для очень больших файлов может потребоваться двухпроходная сортировка (сначала чанки, потом слияние).

Типичные ошибки кандидатов

1. Загрузка всех данных в память: при большом файле OOM.
   Почему неправильно: именно для этого и нужен external merge sort.
   Исправление: обрабатывать чанками, которые помещаются в память.

2. Не учитывают, что файлы могут быть пустыми, или записи не сравнимы напрямую как строки: нужна правильная функция сравнения.
   Почему неправильно: нестабильный порядок или паника.
   Исправление: определить компаратор, обрабатывать пустые случаи.

3. Не закрывают файлы после использования: утечка дескрипторов.
   Почему неправильно: на больших слияниях закончатся файловые дескрипторы.
   Исправление: обязательно defer f.Close() или закрывать сразу после исчерпания.

Возможные дополнительные вопросы интервьюера

Как оптимизировать ввод-вывод при слиянии?
Использовать асинхронный ввод-вывод (aio) или буферизацию большого размера, mmap для чтения чанков.

Как сделать слияние параллельным?
Распараллелить фазу создания чанков; фаза слияния обычно однопоточна, но можно разбить на промежуточные слияния с последующим объединением.

Что делать с записями переменной длины?
Хранить длину или разделитель; построчно читать сканером.

Как реализовать потоковую обработку большого CSV/JSON файла?

Краткий ответ (30–60 секунд)

Потоковая обработка больших CSV/JSON файлов подразумевает чтение и обработку по частям без загрузки всего файла в память. Для CSV в Go используем encoding/csv.Reader в цикле, для JSON — json.Decoder с потоковым Decode(). Обработка может быть конкурентной: горутины-обработчики получают строки через канал. Важно контролировать backpressure и не создавать огромных очередей.

Развёрнутый ответ

Пример для CSV:

file, _ := os.Open("large.csv")
defer file.Close()
reader := csv.NewReader(file)
reader.ReuseRecord = true // переиспользуем слайс для экономии памяти
for {
    record, err := reader.Read()
    if err == io.EOF { break }
    // обработать record (возможно отправить в канал)
}

Для параллелизма:

rows := make(chan []string, 1000)
// горутина-читатель
go func() {
    // read and send to rows
    close(rows)
}()
// пул воркеров читает rows

Для JSON больших массивов:

dec := json.NewDecoder(file)
_, err := dec.Token() // открывающая скобка [
for dec.More() {
    var item MyStruct
    if err := dec.Decode(&item); err != nil { break }
    // process item
}
_, err = dec.Token() // ]

Потоковая обработка позволяет обрабатывать гигабайтные файлы с константной памятью.

Под капотом (internals)

• csv.Reader буферизирует ввод, ReuseRecord заставляет его переиспользовать выделенный слайс, минимизируя аллокации.
• json.Decoder использует буферизацию и сканирование; при Decode парсит только один элемент, не загружая весь документ.

Типичные ошибки кандидатов

1. Использование ioutil.ReadAll или json.Unmarshal для всего файла: загрузка в память.
   Почему неправильно: при большом файле нехватка памяти.
   Исправление: применять потоковые ридеры/декодеры.

2. Забывают про backpressure: небуферизированный канал и быстрый читатель могут заблокироваться, а медленный воркер не успевать.
   Почему неправильно: либо читатель блокируется, либо при большом буфере растёт память.
   Исправление: подобрать буфер разумного размера и ограничить максимальное количество необработанных записей.

3. Не обрабатывают ошибки в потоке, например, битые CSV строки, и цикл ломается без логгирования.
   Почему неправильно: потеря данных и отсутствие видимости.
   Исправление: логировать ошибки, возможно пропускать сбойную строку (если допустимо), или аварийно завершать.

Возможные дополнительные вопросы интервьюера

Как обработать JSON Lines (NDJSON)?
Просто читать построчно и декодировать каждую строку.

Как масштабировать обработку на несколько машин?
Разбить файл на сплиты по диапазонам байт и раздать узлам; каждый обрабатывает свою порцию.

Как гарантировать порядок вывода при параллельной обработке?
Присвоить порядковый номер и собирать в буфер с восстановлением порядка.

Как реализовать идемпотентный REST API эндпоинт?

Краткий ответ (30–60 секунд)

Идемпотентный эндпоинт гарантирует, что повторный вызов с одинаковым ключом идемпотентности не приведёт к другому результату. Реализуем через заголовок Idempotency-Key, который клиент генерирует. Сервер сохраняет пару ключ-результат (со статусом «in progress» или ответ и статус). При повторе возвращает сохранённый ответ без повторения операции.

Развёрнутый ответ

Типичная реализация:

1. Клиент добавляет Idempotency-Key: <UUID>.
2. Сервер middleware проверяет наличие ключа; если новый — выполняет операцию, сохраняет ответ (тело, статус) в кэш с TTL, и возвращает клиенту.
3. Если ключ уже есть: возвращает сохранённый ответ, не выполняя операцию.
   Важно атомарно проверить и создать ключ со статусом «pending», чтобы избежать гонки. Использовать SET NX в Redis или INSERT ... ON CONFLICT DO NOTHING в БД.

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

Idempotency key также помогает в retry.

Под капотом (internals)

• Redis: SET key <pending> NX EX 3600. Затем SET key <response> XX EX 3600.
• Middleware в Go обрабатывает это до обработчика, инкапсулируя логику.

Типичные ошибки кандидатов

1. Не обеспечивают атомарность при проверке и создании ключа, что при одновременных запросах вызывает двойное выполнение.
   Почему неправильно: два запроса могут оба проскочить проверку.
   Исправление: использовать атомарные операции хранилища (Redis SET NX или транзакцию БД).

2. Не сохраняют статус выполнения «pending», и при первом долгом выполнении повторный запрос также начинает обработку: тогда два выполнения.
   Почему неправильно: при длительной операции клиент может послать повтор, полагая, что он идемпотентен, но дублируется.
   Исправление: сразу же записывать "processing", повторный запрос ждёт или возвращает 202.

3. Хранение ключа идемпотентности без TTL: бесконечный рост.
   Почему неправильно: память/БД заполнится.
   Исправление: TTL достаточный, чтобы покрыть время повторов (например, 24 часа).

Возможные дополнительные вопросы интервьюера

Как обрабатывать частичные сбои в идемпотентном эндпоинте?
Сохранять состояние как "in progress", при завершении обновлять. Повторный запрос возвращает последний сохранённый результат либо ожидает.

Нужен ли идемпотентен-ключ для GET-запросов?
Нет, они и так идемпотентны. Для мутирующих (POST/PATCH) — да.

Как реализовать идемпотентность без внешнего хранилища?
Можно хранить в памяти, но нет гарантии при перезагрузке; только для некритичных случаев.

Как реализовать систему a/b тестирования на уровне API?

Краткий ответ (30–60 секунд)

A/B тестирование на уровне API означает, что для части пользователей возвращается разный ответ (например, новая версия алгоритма). Реализуется через feature flag с рандомизацией по userID (или сессии). В Go middleware разделяет пользователей на группы на основе хеша userID и процента. Группа определяет, какую версию эндпоинта вызвать. Результаты телеметрии собирают для анализа.

Развёрнутый ответ

Пример:

func ABTestMiddleware(nextA, nextB http.Handler, percentB int) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        userID := getUserID(r)
        h := hash(userID) % 100
        if h < percentB {
            nextB.ServeHTTP(w, r)
        } else {
            nextA.ServeHTTP(w, r)
        }
        // записать метрику (userID, группа) для позднего анализа
    })
}

Важно, чтобы пользователь постоянно получал одну группу (sticky). Для этого используют хеш, а не random каждый раз. Процент можно регулировать без перезагрузки.

Для сбора данных можно использовать логирование в Kafka/ClickHouse или отправку событий в аналитику.

Под капотом (internals)

• Хеш-функция должна быть детерминированной и равномерно распределять. Подойдёт murmur3.
• Если A/B тест должен меняться динамически, конфигурацию хранят в etcd/Redis и обновляют атомарно.

Типичные ошибки кандидатов

1. Случайное назначение группы при каждом запросе: пользователь видит обе версии, теряется консистентность.
   Почему неправильно: неприятный опыт, невозможно связать поведение с пользователем.
   Исправление: хешировать стабильный userID.

2. Не логируют принадлежность к группе: нет данных для анализа.
   Почему неправильно: A/B тест бесполезен без метрик.
   Исправление: обязательно записывать группу в логи и метрики.

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

Возможные дополнительные вопросы интервьюера

Как провести A/B тест на нескольких эндпоинтах с коррелированной группой?
Использовать единое назначение группы на основе userID, общее для всех сервисов.

Как обеспечить, чтобы группа B не влияла на производительность группы A?
Изоляция ресурсов (bulkhead), отдельные пулы.

Как откатить A/B тест при обнаружении проблем?
Выставить процент в 0 и выключить B-ветку.

Как реализовать «пессимистичную» и «оптимистичную» блокировку в распределенной системе?

Краткий ответ (30–60 секунд)

Пессимистичная блокировка блокирует ресурс до завершения операции (например, через SELECT ... FOR UPDATE в БД или распределённую блокировку на Redis). Оптимистичная не блокирует, но проверяет перед фиксацией, что данные не изменились (версия или временная метка). В Go пессимистичная — через транзакцию БД или Redlock; оптимистичная — через Version поле и UPDATE ... WHERE version = oldVersion.

Развёрнутый ответ

Пессимистичная:

tx, _ := db.Begin()
tx.Exec("SELECT balance FROM accounts WHERE id=$1 FOR UPDATE", id)
// если нужно, обновляем
tx.Exec("UPDATE accounts SET balance = balance - $1 WHERE id=$2", amount, id)
tx.Commit()

Оптимистичная:

var version int
row := db.QueryRow("SELECT balance, version FROM accounts WHERE id=$1", id)
// scan row
newBalance := balance - amount
res, err := db.Exec("UPDATE accounts SET balance=$1, version=version+1 WHERE id=$2 AND version=$3", newBalance, id, version)
if rowsAffected, _ := res.RowsAffected(); rowsAffected == 0 {
    // конфликт, повторить
}

В распределённой среде оптимистичная блокировка предпочтительнее из-за отсутствия блокировок, но в высококонкурентных сценариях может вызывать много retry. Пессимистичная лучше для высокой конкуренции, но требует распределённой блокировки (zookeeper, etcd, Redis Redlock).

Под капотом (internals)

• SELECT ... FOR UPDATE удерживает блокировку строки до коммита транзакции. База данных гарантирует изоляцию.
• Оптимистичная блокировка с версией: UPDATE затрагивает строку только если версия совпадает, иначе 0 строк — клиент должен повторить логику. Атомарность гарантируется БД.

Типичные ошибки кандидатов

1. Пессимистичная блокировка без таймаута: транзакция висит, другие ждут.
   Почему неправильно: deadlock, замедление системы.
   Исправление: всегда задавать таймаут транзакции (контекст с дедлайном).

2. Оптимистичная блокировка без retry с backoff: при конфликте сразу ошибка пользователю.
   Почему неправильно: пользователь получает ошибку при высокой конкуренции.
   Исправление: реализовать автоматический повтор несколько раз с задержкой.

3. Использование оптимистичной блокировки для данных, где конфликты вероятны, без запасного плана: бесполезные retry, нагрузка на БД.
   Почему неправильно: производительность падает из-за повторных попыток.
   Исправление: в таких случаях применить пессимистичную блокировку или смешанную стратегию.

Возможные дополнительные вопросы интервьюера

Как реализовать распределённую пессимистичную блокировку с гарантией?
Использовать Redlock (Redis) или консенсус (etcd, Zookeeper). В Go — redsync или etcd/clientv3/concurrency.

Чем опасна оптимистичная блокировка при длинных транзакциях?
Вероятность конфликта растёт, длительная ретрай-логика может перегрузить систему.

Может ли оптимистичная блокировка работать без версии, на основе полей?
Да, сравнивать старые значения всех полей, но версия экономнее и надёжнее.

Как реализовать throttling на основе приоритетов запросов?

Краткий ответ (30–60 секунд)

Throttling с приоритетами ограничивает пропускную способность, отдавая предпочтение высокоприоритетным запросам. Реализуется через раздельные очереди/семафоры для каждого уровня, либо взвешенное распределение. В Go используют golang.org/x/time/rate с несколькими лимитерами или приоритетный канал, где горутина-диспетчер выбирает из очередей.

Развёрнутый ответ

Подход с несколькими каналами:

type Throttler struct {
    high   chan struct{}
    low    chan struct{}
    dispatcher chan Request
}

Диспетчер крутится в цикле select с приоритетом high (через два select подряд: сначала неблокирующе high, потом low+high вместе). Либо используют семафор с разными весами: x/sync/semaphore.Weighted и несколько экземпляров с разными лимитами.

Более гибко: общий семафор с возможностью приоритетного захвата? Можно реализовать очередь ожидающих с приоритетами на container/heap и sync.Cond.

Под капотом (internals)

• Для эффективного выбора используют паттерн двух select:

select {
case <-high:
default:
    select {
    case <-high:
    case <-low:
    }
}

Это даёт приоритет high без голодания low (но low может голодать, если high бесконечно). Чтобы избежать голодания, добавляют счётчики и периодически гарантируют low.

Типичные ошибки кандидатов

1. Реализация через единую очередь FIFO без учёта приоритетов: высокоприоритетные запросы застревают за низкоприоритетными.
   Почему неправильно: нарушение требований приоритезации.
   Исправление: использовать приоритетную очередь или несколько очередей с взвешенным обслуживанием.

2. Использование select с простым case high, case low, что не даёт приоритета, т.к. Go выбирает равновероятно при готовности обоих.
   Почему неправильно: нельзя гарантировать приоритет.
   Исправление: применять каскадные select или приоритетную очередь.

3. Отсутствие предотвращения голодания низкоприоритетных: при огромном потоке high low никогда не обслуживаются.
   Почему неправильно: нарушение fairness, возможна потеря функциональности.
   Исправление: ввести минимальную гарантированную долю (weighted fair queuing).

Возможные дополнительные вопросы интервьюера

Как динамически изменять пропускную способность в зависимости от загрузки системы?
Использовать контроллер (PID) на основе метрик (CPU, latency) и менять лимит.

Как приоритизировать внутри одного уровня (например, золотой/серебряный)?
Можно внутри уровня использовать FIFO или другой механизм.

Как совместить приоритеты с circuit breaker?
CB может открываться отдельно для каждого priority класса или для всего сервиса.

Как реализовать "sharding" на уровне приложения для распределенного кэша?

Краткий ответ (30–60 секунд)

Шардирование на уровне приложения разделяет ключи кэша по узлам без центрального прокси. Используют клиентскую библиотеку, которая вычисляет хеш ключа и выбирает узел (например, consistent hashing или modulo). В Go можно применить hashring или самописный модуль, который отправляет запросы напрямую на экземпляр Redis/Memcached. После переконфигурации перераспределяются ключи.

Развёрнутый ответ

Например, используем consistent hashing:

type ShardedCache struct {
    ring   *consistent.Consistent
    clients map[string]*redis.Client
}

func (s *ShardedCache) Get(key string) (string, error) {
    node := s.ring.Get(key)
    return s.clients[node].Get(key).Result()
}

При добавлении/удалении узла обновляется ring. Ключи автоматически перераспределяются по новым узлам. Важно учитывать, что при изменении топологии часть ключей становится недоступной по старым запросам, пока не истечёт TTL или не произойдёт миграция. Для предотвращения потерь используют репликацию и постепенную миграцию.

Иногда используют модульное шардирование: shard = hash(key) % N. При изменении N приходится двигать много ключей, поэтому consistent hashing лучше.

Под капотом (internals)

• Consistent hashing минимизирует перемещение ключей.
• Клиентское шардирование уменьшает задержку на один hop (нет маршрутизатора), но приложение должно знать топологию.

Типичные ошибки кандидатов

1. Изменение количества шард без плана миграции, что приводит к потере данных или некорректному чтению: внезапно ключи ищутся на новых узлах, а старые данные остаются на старых.
   Почему неправильно: потеря данных или нарушение согласованности.
   Исправление: реализовать постепенную перебалансировку с дублированием записи на несколько копий, либо использовать прокси.

2. Отсутствие репликации: при отказе узла его шард полностью теряет данные.
   Почему неправильно: потеря данных, недоступность части кэша.
   Исправление: реплицировать данные на несколько узлов (например, consistent hashing с репликациями на следующих узлах в кольце).

3. Использование слабой хеш-функции, приводящей к неравномерному распределению.
   Почему неправильно: горячие шарды.
   Исправление: применять murmur3 и виртуальные ноды.

Возможные дополнительные вопросы интервьюера

Как обрабатывать ситуацию, когда один шард перегружен (hot key)?
Можно добавить in-memory локальный кэш внутри приложения для самых горячих ключей.

Как совместить шардирование с TTL?
TTL хранится на каждом экземпляре кэша; проблем нет, естественно истекает.

Чем отличается шардирование на клиенте от кластерного режима Redis?
В кластерном режиме Redis сервер управляет распределением слотов и сам перенаправляет клиентов, в клиентском — логика в приложении.

Как реализовать "lease" механизм для распределенной блокировки?

Краткий ответ (30–60 секунд)

Lease — аренда блокировки с таймаутом. Владелец получает блокировку на оговорённое время, после которого она автоматически освобождается, если не продлена. Реализуется через Redis (SET с EX/NX), etcd (Lease). В Go используем библиотеку redsync или etcd/concurrency. Периодически продлеваем lease фоновой горутиной, пока работаем с ресурсом.

Развёрнутый ответ

Пример с Redis:

// захват
ok, _ := redis.SetNX(ctx, "lock:resource", uuid, 10*time.Second)
if !ok {
    return ErrLocked
}
// продление
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
go func() {
    ticker := time.NewTicker(5 * time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            redis.Expire(ctx, "lock:resource", 10*time.Second)
        case <-ctx.Done():
            return
        }
    }
}()
// работа...
// освобождение: проверить, что всё ещё наш, и удалить (Lua script)

Важно использовать уникальный токен и Lua для безопасного освобождения, чтобы не удалить чужую блокировку. redsync делает это из коробки на нескольких экземплярах Redis.

Под капотом (internals)

• Redis SET NX EX гарантирует атомарность. Контекст с таймаутом при продлении должен быть отменён при завершении работы.
• etcd реализует lease через механизм грантов, периодические keep-alive.

Типичные ошибки кандидатов

1. Освобождение блокировки без проверки токена: удаление чужой блокировки.
   Почему неправильно: нарушение эксклюзивности, гонка.
   Исправление: использовать Lua-скрипт, проверяющий значение ключа перед удалением.

2. Блокировка без продления (lease) на долгую операцию: истекает, и другой процесс захватывает блокировку, нарушая гарантии.
   Почему неправильно: два процесса одновременно считают, что владеют блокировкой.
   Исправление: автоматическое продление на время операции.

3. Игнорирование проблем с надёжностью продления — если горутина продления упала, блокировка теряется молча.
   Почему неправильно: приложение продолжает работать без блокировки.
   Исправление: мониторить здоровье продления, возможно, при невозможности продлить останавливать критическую секцию.

Возможные дополнительные вопросы интервьюера

Как реализовать блокировку с честной очередью ожидающих?
Использовать Zookeeper/etcd последовательные эфемерные узлы.

В чём разница между lease и блокировкой без таймаута?
Без таймаута упавший владелец держит блокировку навсегда. Lease решает эту проблему.

Как тестировать lease с истечением?
Использовать имитацию времени или задавать короткий lease и проверять, что после истечения другой поток захватывает.

Как реализовать "geo-redundant" high availability?

Краткий ответ (30–60 секунд)

Geo-redundant HA гарантирует доступность при выходе из строя целого датацентра. Реализуется через репликацию данных между географически удалёнными регионами, глобальный балансировщик трафика (DNS, Anycast) и механизмы выбора лидера с учётом гео. В Go приложение должно поддерживать асинхронную репликацию (например, на базе Raft/etcd между регионами) и быстрый переход.

Развёрнутый ответ

Основные компоненты:

• Хранение: multi-region репликация БД (Cassandra, CockroachDB, Spanner) или асинхронная репликация с конфликтами (CRDT).
• Сеть: Global Load Balancer (GLB) направляет клиентов в ближайший живой регион.
• Приложение: stateless, сессии не хранятся локально; при failover запросы перенаправляются.
• Координация: distributed consensus (etcd) с зонами, где лидер находится в одном регионе, но фолловеры в другом. При отказе региона происходят выборы.

Иногда используют active-passive: один регион обслуживает, другой hot standby, с репликацией. Активный-активный сложнее из-за конфликтов данных.

Под капотом (internals)

• Для Raft между регионами задержка высока, что влияет на производительность записи. Используют multi-raft или partitioned consensus.
• Глобальный DNS регулирует гео-маршрутизацию (Route53, Cloudflare).

Типичные ошибки кандидатов

1. Репликация данных синхронная между регионами: высокая задержка, система недоступна при разделении.
   Почему неправильно: CAP теорема: при синхронной репликации теряется доступность или производительность.
   Исправление: асинхронная репликация с eventual consistency, принятие риска потери недавних записей.

2. Active-active без стратегии разрешения конфликтов: два региона меняют одни данные — расхождение.
   Почему неправильно: несогласованность данных без возможности слияния.
   Исправление: CRDT, last-write-wins, или принудительный active-passive.

3. Игнорирование сетевых отказов между регионами (split-brain): оба региона считают себя активными, двойные транзакции.
   Почему неправильно: финансовые дубли.
   Исправление: использовать распределённый консенсус с блокировкой или внешний арбитр.

Возможные дополнительные вопросы интервьюера

Как проверить geo-redundancy?
Проводить chaos engineering: имитировать отказ региона, проверять метрики доступности.

Какие метрики важны для geo-HA?
Recovery Time Objective (RTO), Recovery Point Objective (RPO) — сколько данных допустимо потерять.

Нужно ли приложению знать гео?
Обычно стараются делать его гео-agnostic, используя глобальные сервисы.

Как реализовать "graceful restart" для HTTP сервера без потери соединений?

Краткий ответ (30–60 секунд)

Graceful restart позволяет обновить серверный процесс без разрыва активных соединений. В Go можно реализовать через наследование файлового дескриптора слушающего сокета. Старый процесс передаёт слушатель новому через os.File и сигнал, новый принимает его, запускает сервер. Пакеты gracehttp, endless делают это. В Go 1.22+ есть net/http.Server.Serve с ручным управлением листенером, что упрощает.

Развёрнутый ответ

Идиоматичный подход (без внешних библиотек):

1. При старте проверяем, передан ли дескриптор через переменную окружения или аргумент. Если да, создаём net.Listener из os.File.
2. Если нет — создаём новый листенер.
3. При сигнале перезапуска (SIGUSR2) запускаем новый экземпляр процесса, передавая файл дескриптора листенера через os.StartProcess с ExtraFiles. Закрываем старый сервер Shutdown без выхода.
4. Новый процесс принимает соединения; старый завершает активные.

Библиотека gracehttp это автоматизирует. Также кубернетес делает rolling update, но там соединения между подами обрываются. Graceful restart внутри пода решает проблему длинных соединений (WebSocket, gRPC streams).

Под капотом (internals)

• os.File.Fd() возвращает файловый дескриптор. Через os.StartProcess и ExtraFiles потомок наследует дескриптор.
• net.FileListener создаёт listener из дескриптора.
• Важно убедиться, что старый процесс не принимает новых соединений после передачи (закрыть свой листенер).

Типичные ошибки кандидатов

1. Забывают закрыть старый слушатель после передачи дескриптора: старый процесс продолжает принимать соединения, конфликт.
   Почему неправильно: новые соединения могут попасть в старый процесс, который завершится, обрывая их.
   Исправление: после старта нового процесса закрыть старый слушатель или использовать SO_REUSEPORT осторожно.

2. Не ждут завершения активных запросов перед завершением старого процесса: при завершении обрываются.
   Почему неправильно: потеря данных.
   Исправление: использовать Server.Shutdown с контекстом.

3. Считают, что graceful restart работает без переписывания кода инициализации.
   Почему неправильно: нужно специальное управление процессом.
   Исправление: использовать готовые библиотеки или явно реализовать.

Возможные дополнительные вопросы интервьюера

Совместим ли graceful restart с systemd?
Да, systemd может управлять сокетами и передавать дескриптор, используя socket activation.

Как гарантировать, что новый процесс загрузил конфигурацию корректно, прежде чем принимать трафик?
Ввести readiness проверку между передачей листенера и началом приёма; старый процесс ждёт подтверждения.

Можно ли реализовать zero-downtime деплой с помощью Kubernetes rolling update без graceful restart в процессе?
Только если соединения короткие; для долгих соединений нужен connection draining, но graceful restart внутри пода помогает.

Как реализовать "dynamic configuration" без перезагрузки приложения?

Краткий ответ (30–60 секунд)

Динамическая конфигурация позволяет менять настройки приложения на лету. В Go это реализуется через периодический опрос источника конфигурации (файл, Consul, etcd) или подписку на события (watch). Полученные изменения атомарно применяются к in-memory представлению с помощью atomic.Value или sync.RWMutex. Сервисы перечитывают обновлённые параметры.

Развёрнутый ответ

Пример с файлом и fsnotify:

type Config struct { LogLevel string }

var globalConfig atomic.Value

func watchConfig(path string) {
    watcher, _ := fsnotify.NewWatcher()
    watcher.Add(path)
    for {
        select {
        case <-watcher.Events:
            data, _ := os.ReadFile(path)
            var cfg Config
            json.Unmarshal(data, &cfg)
            globalConfig.Store(cfg)
        }
    }
}

Альтернативно, использовать конфиг-сервер (Consul, etcd) с long polling или gRPC-стримом. Главное — не блокировать бизнес-логику на время получения конфигурации.

Под капотом (internals)

• atomic.Value под капотом использует атомарные операции загрузки/сохранения указателя; при Store создаёт копию данных.
• Для сложных иерархических конфигов применяют библиотеки вроде viper с поддержкой WatchConfig().

Типичные ошибки кандидатов

1. Запись в конфигурацию без синхронизации, прямое изменение полей: гонка данных при чтении из других горутин.
   Почему неправильно: неопределённое поведение, может привести к частично обновлённой конфигурации.
   Исправление: обновлять атомарно весь объект (immutable) или использовать мьютекс.

2. Чрезмерно частое обновление конфигурации при каждом изменении файла без дебаунса: лавина парсинга.
   Почему неправильно: трата ресурсов.
   Исправление: добавить небольшую задержку перед применением изменений.

3. Отсутствие валидации новой конфигурации перед применением: ошибочная конфигурация применяется и ломает приложение.
   Почему неправильно: приложение падает или ведёт себя некорректно.
   Исправление: проверять конфигурацию, при ошибке не применять и сохранять старую.

Возможные дополнительные вопросы интервьюера

Как откатить конфигурацию при ошибке?
Вести историю версий, при обнаружении проблем в метриках автоматически или вручную откатить на предыдущую.

Как совместить динамическую конфигурацию с feature flags?
Feature flags — частный случай динамической конфигурации; используют единый инфраструктурный слой.

Какой протокол выбрать для конфиг-сервера: polling или push?
Push (WebSocket/GRPC stream) быстрее, polling проще. Выбор зависит от требований к задержке.

Как реализовать "eventual consistency" в распределенном key-value хранилище?

Краткий ответ (30–60 секунд)

Eventual consistency гарантирует, что все реплики данных со временем сойдутся к одному значению, если новых обновлений нет. В распределённом KV-хранилище реализуется через асинхронную репликацию (gossip, anti-entropy), разрешение конфликтов (last-write-wins, CRDT, vector clocks) и read-repair. В Go можно построить систему на основе Raft для лидерской репликации, но eventual consistency даёт read-repair и hinted handoff.

Развёрнутый ответ

Типичная архитектура (как в Amazon Dynamo):

• Каждый ключ реплицирован на N узлов (preference list).
• Запись отправляется на первый доступный узел, который координирует запись на реплики (W из N). При достижении кворума запись считается успешной.
• Асинхронная anti-entropy: фоновый процесс сравнивает данные между репликами и исправляет расхождения (Merkle tree).
• При конфликтах (одновременные записи в разные реплики) используют векторные часы и либо LWW, либо возвращают клиенту конфликтующие версии для разрешения.

В Go можно реализовать такое хранилище, используя gRPC для внутренних коммуникаций, gossip для членства, и движок хранения (badger/bolt).

Под капотом (internals)

• Векторные часы: map[nodeID]counter — логическое время.
• Merkle tree: иерархия хешей для быстрой синхронизации диапазонов ключей.
• Hinted handoff: если реплика недоступна, координатор временно хранит обновление и передаёт, когда узел возвращается.

Типичные ошибки кандидатов

1. Нет конфликт-резолюции, просто перезаписывают последним пришедшим без учёта причинности: потеря обновлений.
   Почему неправильно: нарушение консистентности, потерянные записи.
   Исправление: использовать векторные часы и возвращать конфликт клиенту или разрешать по правилам.

2. Нарушение кворума записи/чтения (N=R+W > N): может привести к несогласованности при чтении.
   Почему неправильно: не выполняется условие strong consistency, возможна чтение устаревших данных без возможности восстановления.
   Исправление: настроить параметры репликации: W+R > N, и всегда читать с ремонтом.

3. Отсутствие read-repair: устаревшие данные никогда не обновляются, пока не случится запись.
   Почему неправильно: данные на репликах «гниют».
   Исправление: при чтении, если обнаружены расхождения, запустить фоновый ремонт.

Возможные дополнительные вопросы интервьюера

Как eventual consistency связана с CAP-теоремой?
Выбираем AP (доступность и устойчивость к разделению) в ущерб сильной консистентности.

Как измерять степень консистентности?
Метрики divergence time, inconsistency window.

Как реализовать transactional eventual consistency (causal consistency)?
Causal consistency гарантирует причинно-следственный порядок, используя векторные часы.