«System Design — как темный лес. Go — вроде бы знаю, но знания поверхностные. А собеседование снова провавил на задаче по concurrency»

Знакомо?

Даже у разработчиков с 2-5 годами опыта остаются такие пробелы, которые мешают чувствовать уверенность:
– знаю много паттернов и приемов, но не знаю где и когда их применять;
– на System Design интервью не получается спроектировать систему за час;
– кажется, что понимаю Go, но только до тех пор, пока не столкнусь с задачами на собеседованиях.

🎓 В телеграм-канале Балун Владимир есть материалы, которые помогают прокачать Go и подготовиться к собеседованиям — без воды и пересказов статей из интернета.

1️⃣Технические разборы:
– Итераторы в Golang
– Паттерны использования каналов в Go
– Внутреннее устройство аллокатора Go
– Внутреннее устройство мьютексов в Go и Linux

2️⃣Подготовка к собеседованиям:
– Concurrency задачи с Go собеседований
– Решение сложных задач с Go собеседований
– Как подготовиться к System Design интервью

3️⃣Карьера и опыт:
– Особенности Golang
– Карьера программиста в BigTech
– Путь от джуна до тимлида Яндекса

Если хочется разобраться в Go глубже, научиться объяснять сложные вещи и уверенно проходить собеседования — канал точно пригодится.

Автор канала - Владимир Балун. Разрабатывал высоконагруженные сервисы на С++ и Go в Тинькофф, Mail.ru и Ozon. Руководил командой распределенной трассировки запросов в Яндексе (11GB/s трафик) и провел больше ста технических интервью в разных компаниях. Сейчас создает образовательные проекты и делится опытом в телеграме.

Канал открыт. Без флуда. Только польза.

➡️Подписаться

Реклама. ИП Балун Владимир Николаевич. ИНН: 610111147548. Erid: 2VtzqwXyRqs

Команда Ozon Tech готовит мощнейший трек по бэкенду в рамках своей конференции E-CODE 💙

И это только одна из причин, почему стоит быть там 13-14 сентября. А ещё: качественный нетворк, 1х1 с топовыми IT-экспертами и HR, эксклюзивный мерч и интерактивы, вечеринки с участием НТР, Заточки, ILWT и Нейромонаха Феофана.

Успейте зарегистрироваться. Это обязательно ⬅

🎯 Задача (Go, продвинутая конкуррентность; версия: Go 1.21+)

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

🟠Требования:
- Сигнатура:
Process[T any, R any](ctx context.Context, in []T, worker func(context.Context, T) (R, error), parallelism int) ([]R, error)
- Параллельная обработка не более parallelism задач одновременно.
- Результаты возвращаются в том же порядке, что и входной срез, даже если отдельные задачи завершаются вразнобой.
- При первой ошибке:
- немедленно отменить все ещё выполняющиеся задачи,
- вернуть первую ошибку,
- не оставить «утекших» горутин.
- Учитывать ctx.Done() и корректно завершаться по таймауту/отмене.
- Без внешних зависимостей; только стандартная библиотека.

🟠Подсказка:
- Используй context.WithCancelCause для распространения причины отмены.
- Организуй пул рабочих через буферизованный канал с задачами.
- Результаты складывай по индексу, чтобы сохранить порядок.
- Для потокозащищённой фиксации первой ошибки используй sync.Once.

Ниже — эталонная реализация и пример использования.

Код (Go 1.21+):

package main

import (
 "context"
 "errors"
 "fmt"
 "math/rand"
 "sync"
 "time"
)

type job[T any] struct {
 i   int
 val T
}

func Process[T any, R any](
 parent context.Context,
 in []T,
 worker func(context.Context, T) (R, error),
 parallelism int,
) ([]R, error) {
 if parallelism <= 0 {
  return nil, errors.New("parallelism must be > 0")
 }
 ctx, cancel := context.WithCancelCause(parent)
 defer cancel(nil)

 jobs := make(chan job[T], parallelism) // лёгкая обратная давление
 out := make([]R, len(in))

 var wg sync.WaitGroup
 var once sync.Once
 var firstErr error

 // Рабочие
 workerFn := func() {
  defer wg.Done()
  for {
   select {
   case <-ctx.Done():
    return
   case j, ok := <-jobs:
    if !ok {
     return
    }
    res, err := worker(ctx, j.val)
    if err != nil {
     once.Do(func() {
      firstErr = err
      cancel(err) // прерываем остальных
     })
     return
    }
    // Сохраняем порядок
    out[j.i] = res
   }
  }
 }

 // Старт пула
 wg.Add(parallelism)
 for k := 0; k < parallelism; k++ {
  go workerFn()
 }

 // Диспетчер задач
sendLoop:
 for i, v := range in {
  select {
  case <-ctx.Done():
   break sendLoop
  case jobs <- job[T]{i: i, val: v}:
  }
 }
 close(jobs)

 // Ждём завершения
 wg.Wait()

 // Если была отмена по ошибке — вернём её
 if firstErr != nil {
  return nil, firstErr
 }
 // Если отменил родительский контекст — вернём его причину
 if err := context.Cause(ctx); err != nil && !errors.Is(err, context.Canceled) && !errors.Is(err, context.DeadlineExceeded) {
  // это cause из cancel(err), уже обработали выше
 } else if err := context.Cause(parent); err != nil {
  return nil, err
 }

 return out, nil
}

// Демонстрация: умножаем числа с случайной задержкой; каждое третье число — ошибка.
// Видно, что вывод упорядочен по входу, а отмена срабатывает на первой ошибке.
func main() {
 rand.New(rand.NewSource(time.Now().UnixNano()))
 ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
 defer cancel()

 input := []int{1, 2, 3, 4, 5, 6, 7}
 parallelism := 3

 worker := func(ctx context.Context, x int) (int, error) {
  // эмуляция непредсказуемого времени работы
  time.Sleep(time.Duration(rand.Intn(120)) * time.Millisecond)
  if x%7 == 0 { // попробуй поменять условие на (x%3==0), чтобы увидеть раннюю отмену
   return 0, fmt.Errorf("bad luck on %d", x)
  }
  select {
  case <-ctx.Done():
   return 0, ctx.Err()
  default:
   return x * x, nil
  }
 }

 res, err := Process[int, int](ctx, input, worker, parallelism)
 if err != nil {
  fmt.Println("error:", err)
  return
 }
 fmt.Println("results:", res)
}

🟠Как проверить:
- go run . — запусти несколько раз, чтобы увидеть разные порядки завершения, но стабильный порядок результатов.
- Поменяй порог ошибки в worker (например, x%3==0), чтобы убедиться, что отмена срабатывает мгновенно и горутины не висят.
- Проверь на гонки: go run -race .

🧩 Хитрая задача по Go — «Пул, который не течёт, не зависает и сохраняет порядок»

Задача:
Реализуй обобщённую функцию MapOrdered — ограниченный по параллелизму пул воркеров, который применяет функцию fn к входным элементам и отдаёт результаты строго в порядке входа, при этом:
- не теряет отмену context.Context,
- не допускает утечек горутин и зависаний,
- корректно обрабатывает panic внутри fn,
- поддерживает «раннее завершение» (как только достаточно результатов),
- обеспечивает backpressure (не раздувает буферы).

Сигнатуры:

type Result[R any] struct {
    Value R
    Err   error
}

type Options struct {
    Workers       int           // >0, число воркеров
    MaxInFlight   int           // ≥ Workers, ограничение внутренних буферов
    EarlyStopN    int           // если >0, остановиться после N успешных результатов
    PanicAsError  bool          // если true, паники маппятся в error
    TaskTimeout   time.Duration // если >0, дедлайн на одну задачу
}

func MapOrdered[T any, R any](
    ctx context.Context,
    input <-chan T,
    fn func(context.Context, T) (R, error),
    opt Options,
) <-chan Result[R]

Требования и тонкости

- Строгий порядок.
Выходные элементы должны соответствовать порядку поступления во input. Параллелизм допустим, но публикация результата — строго по индексу.
- Отмена и завершение.
- При отмене ctx функция должна без утечек завершить все горутины и закрыть выходной канал.
- Если EarlyStopN > 0, как только выдали N успешных результатов — корректно останавливаем обработку оставшихся задач (не зависаем, не «подвешиваем» воркеров).

🟠Backpressure.
Никаких неограниченных буферов. Учитывай MaxInFlight, чтобы не переполнять память при медленном fn.

🟠Panic-handling.
Если PanicAsError=true, паники из fn перехватываются и превращаются в error. Если false — паника должна «пробить» наружу (но без гонок и утечек).

🟠Timeout на задачу.
При TaskTimeout>0 каждая задача исполняется с отдельным контекстом-дедлайном; таймаут — это ошибка задачи, а не общий стоп пула.

🟠Гарантия отсутствия утечек.
После закрытия input и/или отмены контекста пул завершает все свои горутины. Проверь runtime.NumGoroutine() до/после и убедись в стабильном числе.

🟠Без гонок.
Решение обязано проходить -race.

🟠Zero-copy по возможности.
Не копируй большие данные лишний раз; не «складывай» всё в память — обрабатывай потоково. Допустимы минимальные накладные структуры (индексы, слоты).

Подсказки (но не решение)

- Для сохранения порядка пригодится «кольцо результатов» или слайс «слотов» с публикацией по индексу и «ползунком» выдачи.
- Отдельно продумай: кто закрывает выходной канал и когда (все задачи обработаны, или ранний стоп).
- Аккуратно обращайся с контекстами: каждому fn — свой дочерний ctx (для таймаутов), общий ctx — для остановки пула.
- Не забудь про range-variable capture в горутинах.
- Паники оборачивай через recover, если включён PanicAsError.