golang-interview-questions

KO | EN

gitlite — search

#javascript #hacktoberfest #react #ai #llm #golang #rust #deep-learning #macos #awesome #cli #pytorch #ios #mcp

golang-interview-questions

(★ 10)

Most popular Golang interview questions and answers -> https://www.devlovers.net

golang-interview-questions 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

**Read in other languages: [English 🇺🇸](README.en.md),
[Polska 🇵🇱](README.pl.md), [German 🇩🇪](README.de.md), [French 🇫🇷](README.fr.md),
[Spanish 🇪🇸](README.es.md), [Українська 🇺🇦](README.md).**

<details>
<summary>1. Що таке Go і для яких задач його було створено?</summary>

#### Go

Go (або Golang) — це компільована, статично типізована мова програмування,
створена в Google Робертом Ґріземером, Робом Пайком і Кеном Томпсоном. Її
спроєктовано з акцентом на простоту, передбачуваність, швидку компіляцію та
високу продуктивність у продакшн-системах.

#### Для яких задач Go було створено:

1. **Мережеві та серверні системи:** HTTP/API-сервіси, проксі, шлюзи, бекенд
   для високонавантажених застосунків.

2. **Хмарна інфраструктура:** інструменти оркестрації, CI/CD, observability,
   DevOps-утиліти (саме тому чимало cloud-native проєктів написано на Go).

3. **Конкурентні обчислення:** задачі, де важливі паралельна обробка даних,
   контроль latency та ефективне використання ресурсів.

4. **Системне програмування прикладного рівня:** CLI-інструменти, демони,
   фонові воркери, інтеграційні сервіси.

#### Чому саме Go:

- Лаконічний синтаксис і низька когнітивна складність коду.
- Вбудована модель конкурентності (`goroutine`, `channel`).
- Швидка компіляція та простий цикл розробки.
- Зручний стандартний інструментарій (`go test`, `go vet`, `pprof`, модулі).

Отже, Go створено як практичну інженерну мову для масштабованих,
підтримуваних і продуктивних сервісів, де важливі надійність, швидкість
розробки та експлуатаційна простота.

</details>

<details>
<summary>2. Які основні принципи дизайну мови Go?</summary>

#### Go

Дизайн Go ґрунтується не на максимальній «виразності» за будь-яку ціну, а на
інженерній доцільності: код має бути простим для читання, легким для супроводу
та надійним у довгому життєвому циклі системи.

#### Основні принципи дизайну Go:

1. **Простота понад складність:** мова свідомо уникає надмірно складних
   конструкцій, аби зменшити кількість помилок і поріг входу в кодову базу.

2. **Читабельність і однозначність:** перевага надається ясному коду, який
   швидко розуміє будь-який інженер команди, а не лише автор.

3. **Швидка компіляція та продуктивна розробка:** цикл «написав → зібрав →
   перевірив» має бути коротким, що пришвидшує ітерації в реальних проєктах.

4. **Вбудована конкурентність:** `goroutine` та `channel` є органічною частиною
   мови, а не зовнішнім патчем, тож паралельні обчислення підтримуються
   природно.

5. **Композиція замість важкої ієрархії:** у Go переважає підхід «складати
   поведінку з простих частин», а не будувати глибокі ланцюги наслідування.

6. **Мінімалізм у фічах, максималізм у практичності:** менше «магії», більше
   передбачуваної поведінки під час виконання й відлагодження.

7. **Єдиний інструментальний стандарт:** `go fmt`, `go test`, `go mod`, `go
   vet` формують спільну культуру розробки без фрагментації тулінгу.

#### Узагальнення:

Go спроєктовано як мову для командної розробки й промислового програмування:
вона дисциплінує стиль, заохочує ясність думки в коді та забезпечує добрий
баланс між простотою й ефективністю.

</details>

<details>
<summary>3. Які ключові особливості Go порівняно з іншими мовами?</summary>

#### Go

Go вирізняється тим, що поєднує лаконічність синтаксису з дуже практичною
інженерною моделлю виконання: мова не перевантажує розробника зайвою
складністю, але дає інструменти для побудови швидких і надійних систем.

#### Ключові особливості Go:

1. **Простий і строгий синтаксис:** код легко читати, а стилістична
   однорідність підтримується автоматично через `go fmt`.

2. **Компіляція у нативний бінарний файл:** застосунок зазвичай збирається в
   один виконуваний файл без важких зовнішніх залежностей під час запуску.

3. **Статична типізація з високою передбачуваністю:** значна частина помилок
   виявляється на етапі компіляції, що підвищує надійність у продакшні.

4. **Вбудована конкурентність:** `goroutine` і `channel` роблять паралельне
   програмування природним, а не допоміжним механізмом.

5. **Швидкий цикл розробки:** порівняно швидка компіляція та стандартні
   інструменти прискорюють тестування і доставку змін.

6. **Сильна стандартна бібліотека:** мережа, HTTP, криптографія, робота з
   файлами, профілювання й тестування доступні «з коробки».

7. **Зрозуміла модель помилок:** у Go помилки обробляють явно через `error`,
   що робить контроль станів прозорим і контрольованим.

8. **GC і керована пам'ять:** мова спрощує розробку системного бекенду, не
   змушуючи вручну керувати життєвим циклом більшості об'єктів.

9. **Практичний модульний підхід:** `go mod` стандартизує керування
   залежностями та відтворюваність збірок.

#### Висновок:

На відміну від багатьох мов, що тяжіють або до максимальної абстрактності, або
до низькорівневої керованості, Go цілеспрямовано тримає інженерний баланс:
простота, продуктивність, масштабованість і зручність командної розробки.

</details>

<details>
<summary>4. У чому різниця між імперативною і декларативною парадигмою програмування? Наведіть приклади мов.</summary>

#### Go

Імперативна й декларативна парадигми відрізняються передусім фокусом опису:
перша пояснює **як** виконати задачу покроково, друга — **що саме** має бути
отримано як результат.

#### Імперативна парадигма:

1. **Сутність:** програміст явно задає послідовність інструкцій, зміну стану,
   цикли, гілки та порядок виконання.

2. **Фокус:** контроль алгоритму та керування потоком виконання.

3. **Типові риси:** змінні, присвоєння, `for`, `if`, мутація даних.

4. **Приклади мов:** Go, C, C++, Rust (у значній частині практик), Java.

#### Декларативна парадигма:

1. **Сутність:** описується бажаний результат або властивості системи без
   детального припису кроків виконання.

2. **Фокус:** модель даних, правила та обмеження, а не алгоритмічна механіка.

3. **Типові риси:** вирази вищого рівня, мінімізація явної мутації,
   абстрагування від порядку виконання.

4. **Приклади мов/підходів:** SQL, HCL (Terraform), HTML/CSS, функціональні
   стилі в Haskell та частково в Elixir.

#### Практичний висновок:

- У реальних системах парадигми часто поєднуються.
- Go здебільшого імперативний за природою, однак окремі елементи
  декларативності з'являються в конфігураціях, описах схем, DSL і запитах до
  даних.
- Для співбесіди важливо підкреслити: вибір парадигми — це не питання «краще чи
  гірше», а питання відповідності задачі, команді та вимогам до підтримки коду.

</details>

<details>
<summary>5. Чому Go добре підходить для написання Cloud Native сервісів?</summary>

#### Go

Go вважають однією з найприродніших мов для Cloud Native не випадково: її
архітектурні властивості добре збігаються з вимогами до сучасних розподілених
систем — масштабованість, спостережуваність, надійність і операційна простота.

#### Чому Go ефективний у Cloud Native середовищі:

1. **Легковагові конкурентні обчислення:** `goroutine` та `channel` спрощують
   побудову сервісів, які одночасно обробляють велику кількість запитів.

2. **Висока продуктивність і передбачуваний runtime:** Go-компілятор та
   оптимізований планувальник добре працюють у навантажених мережевих сценаріях.

3. **Швидкий старт і деплой:** зазвичай результат збірки — один бінарний файл,
   який легко пакувати в контейнер і розгортати в Kubernetes або інших
   оркестраторах.

4. **Невеликі операційні витрати:** прості Docker-образи, швидка збірка, менше
   проблем із залежностями під час запуску.

5. **Потужна стандартна бібліотека:** `net/http`, `context`, `crypto`, `encoding`
   та інші пакети дозволяють будувати продакшн-рішення без надмірної залежності
   від сторонніх фреймворків.

6. **Зручність observability-практик:** у Go просто інтегрувати метрики, трейсінг
   і профілювання, що критично для експлуатації в хмарі.

7. **Стійка екосистема інфраструктурних інструментів:** значна частина Cloud
   Native стеку написана саме на Go (наприклад, Kubernetes, Prometheus, Helm,
   Terraform), що спрощує інтеграції та командний контекст.

8. **Ясність коду в командній розробці:** Go заохочує прямолінійні рішення, а це
   зменшує когнітивне навантаження при підтримці мікросервісної архітектури.

#### Підсумок:

Go добре підходить для Cloud Native сервісів, бо поєднує інженерну
передбачуваність із продуктивністю та практичною зручністю: від написання коду
до його деплою, моніторингу й довгострокового супроводу.

</details>

<details>
<summary>6. Що таке `shadowing` змінних і як він може призвести до помилок у бізнес-логіці?</summary>

#### Go

`Shadowing` (затінення) — це ситуація, коли у внутрішній області видимості
оголошується нова змінна з тим самим іменем, що й у зовнішній. У підсумку код
працює не з «очікуваною» змінною, а з її локальною копією за назвою.

#### Як це виникає найчастіше:

1. **Коротке оголошення `:=` у вкладеному блоці:** розробник очікує присвоєння,
   а фактично створюється нова змінна.

2. **Обробка помилок (`err`) у `if`/`for`/`switch`:** локальна `err` затіняє
   зовнішню, через що подальша перевірка стану стає хибною.

3. **Робота зі станом у довгих функціях:** затінення проміжних змінних ускладнює
   читання і підвищує ризик логічних дефектів.

#### Чому це небезпечно для бізнес-логіки:

1. **Хибні перевірки умов:** система може перейти в неправильну гілку виконання,
   бо перевіряється «не та» змінна.

2. **Втрачений або некоректний стан:** наприклад, результат обчислення лишився в
   локальному блоці, а зовнішній стан не оновився.

3. **Складний дебагінг:** візуально ім'я те саме, але семантично це різні
   об'єкти; помилка проявляється неочевидно і часто лише на бойових кейсах.

4. **Тихі дефекти без паніки:** програма може компілюватися і працювати, однак
   повертати бізнесово некоректний результат.

#### Як запобігати `shadowing`:

- Свідомо розрізняти `=` і `:=` в усіх вкладених блоках.
- Тримати коротку видимість змінних і уникати надмірно довгих функцій.
- Використовувати зрозумілі, семантично точні назви, особливо для станів і
  помилок.
- Підключати статичний аналіз (`go vet`, `golangci-lint`) з правилами на
  виявлення затінення.
- У критичних місцях логіки додавати тести на негативні сценарії та граничні
  умови.

#### Висновок:

`Shadowing` — не синтаксична дрібниця, а джерело підступних логічних помилок.
У продакшн-Go-коді дисципліна оголошення змінних напряму впливає на коректність
бізнес-поведінки системи.

</details>

<details>
<summary>7. Навіщо використовувати `struct{}` (порожню структуру) і в яких сценаріях це ефективно?</summary>

#### Go

`struct{}` у Go — це порожня структура, тобто тип без полів. Її ключова
властивість: вона не несе корисного навантаження даними, а лише фіксує сам факт
наявності значення або події.

#### Чому `struct{}` ефективна:

1. **Нульовий інформаційний обсяг:** тип не містить полів, тож використовується
   як маркер, а не контейнер даних.

2. **Ясна семантика наміру:** код прямо показує, що важливий факт «є/нема», а не
   payload.

3. **Зменшення зайвих алокацій у службових структурах:** у багатьох патернах
   це практичніший вибір за `bool` або довільні значення, коли дані не потрібні.

#### Типові сценарії використання:

1. **Множина (set) через `map[K]struct{}`:**
   `map` у Go — це ключ-значення, а для множини нам потрібні лише унікальні
   ключі. `struct{}` тут ідеально позначає «ключ присутній».

2. **Сигнальні канали `chan struct{}`:**
   застосовуються для нотифікації «подія сталася» (stop/done/shutdown), коли
   передавати дані не потрібно.

3. **Маркерні типи й API-контракти:**
   порожня структура може виступати легковаговим семантичним маркером у
   внутрішніх протоколах програми.

4. **Вбудовування для композиції поведінки:**
   інколи `struct{}` використовують як технічний елемент композиції, коли
   потрібна структура без стану.

#### Коли не варто використовувати:

- Коли потрібен реальний стан або атрибути сутності.
- Коли `bool` дає зрозумілішу бізнес-семантику (наприклад, явний прапорець
  умови, а не факт приналежності до множини).

#### Підсумок:

`struct{}` — це інструмент точного наміру: якщо дані не потрібні, але треба
позначити факт, присутність або сигнал, порожня структура є елегантним і
ефективним рішенням у Go-коді.

</details>

<details>
<summary>8. Як працює внутрішня структура `slice` і що відбувається при передачі його до функції?</summary>

#### Go

У Go `slice` — це не сам масив, а легка «надбудова»-дескриптор над ділянкою
масиву. Саме тому поведінка `slice` відрізняється від звичайного копіювання
масивів і часто викликає помилки в інтерв'ю та реальному коді.

#### Внутрішня модель `slice`:

`slice` концептуально складається з трьох частин:

1. **Вказівник на базовий масив** (`ptr`)
2. **Довжина** (`len`) — скільки елементів доступно зараз
3. **Місткість** (`cap`) — скільки елементів доступно до межі базового масиву

Тобто `slice` зберігає метадані про область у пам'яті, а не дублює всі елементи.

#### Що відбувається при передачі `slice` у функцію:

1. **Копіюється заголовок `slice` (ptr/len/cap), а не весь масив.**
2. **Обидві сторони (caller і callee) спершу дивляться на той самий базовий
   масив.**
3. **Зміна елементів через індекс** (`s[i] = ...`) у функції зазвичай видима
   ззовні, бо змінюються дані спільного масиву.
4. **Зміна самого заголовка** (`s = s[:n]`, `s = append(...)`) у функції не
   змінює заголовок у викликача, якщо ви не повертаєте новий `slice`.

#### Ключовий нюанс з `append`:

- Якщо під час `append` вистачає `cap`, запис іде в той самий базовий масив.
- Якщо `cap` не вистачає, runtime алокує новий масив, копіює туди дані, і
  локальний `slice` у функції починає посилатися вже на іншу пам'ять.

Отже, після `append` функція може працювати вже з новим масивом, тоді як зовні
залишиться старий `slice`, якщо нове значення не повернуто.

#### Практичний висновок:

- Хочете змінити елементи — можна передавати `slice` як є.
- Хочете змінити довжину/місткість або результат `append` — поверніть оновлений
  `slice` з функції (або передавайте вказівник на `slice`, коли це справді
  виправдано архітектурно).

#### Приклад:

```go
package main

import "fmt"

func grow(s []int) {
	s = append(s, 99) // змінюємо локальний заголовок slice
}

func mutate(s []int) {
	s[0] = 42 // змінюємо спільний базовий масив
}

func main() {
	s := []int{1, 2, 3}
	mutate(s)
	grow(s)
	fmt.Println(s) // [42 2 3], append у grow не змінив заголовок у викликачі
}
```

</details>

<details>
<summary>9. Чому `make([]T, 0, n)` краще ніж `var s []T` при відомих розмірах?</summary>

#### Go

Коли вам заздалегідь відомо приблизну або точну кількість елементів, конструкція
`make([]T, 0, n)` майже завжди практичніша за `var s []T`, оскільки вона
відразу резервує потрібну місткість і зменшує кількість перевиділень пам'яті.

#### Що відрізняє ці два підходи:

1. **`var s []T`**
- створює `nil`-slice з `len=0`, `cap=0`;
- перший же `append` змушує runtime виділяти пам'ять;
- при рості даних відбуваються нові reallocation-и й копіювання.

2. **`make([]T, 0, n)`**
- створює slice з `len=0`, але вже з `cap=n`;
- елементи додаються через `append` без перевиділення, доки не вичерпано `cap`;
- менше копіювань даних і стабільніша продуктивність.

#### Чому це важливо на практиці:

1. **Менше алокацій у heap:** знижується навантаження на GC.
2. **Краще latency-поведінка:** менше «стрибків» часу на перевиділення.
3. **Вища пропускна здатність у гарячих шляхах:** особливо у циклах, парсингу,
   агрегації, серіалізації.
4. **Передбачуваність ресурсів:** простіше оцінити пам'ять для конкретного
   сценарію.

#### Коли різниця особливо помітна:

- Велика кількість `append` у циклах.
- Обробка потоків даних у бекенд-сервісах.
- Часто викликані функції, де навіть невеликі алокації накопичуються в істотні
  витрати.

#### Висновок:

Якщо розмір колекції відомий або добре оцінюється наперед, `make([]T, 0, n)` —
це інженерно зрілий вибір: він дає менше алокацій, кращу продуктивність і
стабільнішу поведінку під навантаженням.

</details>

<details>
<summary>10. Як slice expression `a[low:high:max]` контролює `cap` нового слайса?</summary>

#### Go

У Go повна форма зрізу `a[low:high:max]` дозволяє керувати не лише довжиною
(`len`), а й місткістю (`cap`) нового `slice`. Це важливий інструмент для
контролю побічних ефектів під час `append`.

#### Формули:

Для `s := a[low:high:max]`:

1. `len(s) = high - low`
2. `cap(s) = max - low`

За умови коректних меж:

- `0 <= low <= high <= max <= cap(a)` (для slice-бази)

#### Що це дає практично:

1. **Обмеження видимої місткості:**
   ви можете «відрізати» доступ до хвоста базового масиву, навіть якщо він
   фізично існує.

2. **Безпечніший `append`:**
   якщо `cap` штучно зменшена, `append` швидше виконає перевиділення пам'яті,
   замість перезапису сусідніх даних у спільному масиві.

3. **Краща ізоляція між частинами коду:**
   це особливо корисно, коли один slice передається в іншу функцію або шар
   системи, і ви не хочете, щоб він міг «дорости» в чужу область.

#### Концептуальний приклад:

- `a[2:5]` дає `len=3`, `cap` тягнеться до кінця базового масиву.
- `a[2:5:5]` дає `len=3`, `cap=3` — подальший `append` уже не має запасу й
  змушує створити новий масив.

#### Висновок:

Третій індекс у `a[low:high:max]` — це точний важіль керування `cap`. Він
потрібен тоді, коли важливо контролювати ріст `slice`, уникати неочікуваного
перезапису спільної пам'яті й робити поведінку коду передбачуваною.

#### Приклад:

```go
package main

import "fmt"

func main() {
	a := []int{0, 1, 2, 3, 4, 5}
	s := a[2:4:4] // len=2 (2,3), cap=2
	fmt.Println(len(s), cap(s)) // 2 2

s = append(s, 99) // новий backing array, а не розширення в a
	fmt.Println(a)    // [0 1 2 3 4 5]
	fmt.Println(s)    // [2 3 99]
}
```

</details>

<details>
<summary>11. Чи гарантується, що вказівник на елемент слайсу залишиться валідним після виклику `append`?</summary>

#### Go

Коротка відповідь: **ні, не гарантується**. Після `append` вказівник на елемент
старого `slice` може втратити актуальність щодо нового `slice`, якщо відбулося
перевиділення базового масиву.

#### Чому так відбувається:

1. `append` додає елементи в межах наявної `cap`, якщо місця достатньо.
2. Якщо `cap` вичерпано, runtime створює новий масив, копіює дані та повертає
   `slice`, що посилається вже на нову адресу.
3. Раніше взяті вказівники залишаються прив'язаними до старого масиву, а не до
   оновленого `slice`.

#### Практичні наслідки:

1. **Pointer aliasing стає небезпечним:** логіка може «дивитися» в застарілу
   область пам'яті.
2. **Неочікувані баги в модифікаціях:** зміни через старий pointer не впливають
   на новий `slice` після relocation.
3. **Складний дебагінг:** код компілюється і часто працює, але дає
   непередбачувану поведінку під навантаженням або на інших обсягах даних.

#### Як писати безпечно:

- Не зберігати довгоживучі вказівники на елементи `slice`, який потенційно
  зростатиме через `append`.
- Якщо pointer справді потрібен, забезпечити стабільність пам'яті:
  попередньо резервувати місткість (`make(..., 0, n)`) або не виконувати `append`
  після взяття адрес.
- Часто безпечніше передавати індекс або повертати новий `slice` і перев’язувати
  всі похідні посилання.

#### Висновок:

Після `append` валідність pointer-ів на елементи `slice` не є контрактом Go.
Безпечний код має виходити з припущення, що `append` може змінити базову адресу
даних.

</details>

<details>
<summary>12. Як у Go ефективно видаляти елементи зі слайса без збереження порядку?</summary>

#### Go

Якщо порядок елементів не має значення, найефективніша стратегія видалення —
замінити елемент, що видаляється, останнім елементом `slice`, а потім укоротити
`slice` на один.

#### Ідея підходу:

1. Знайти індекс `i` елемента для видалення.
2. Присвоїти `s[i] = s[len(s)-1]`.
3. Зменшити довжину: `s = s[:len(s)-1]`.

#### Чому це ефективно:

1. **O(1) за часом** (без зсуву всіх наступних елементів).
2. **Мінімум копіювань** у порівнянні з видаленням із збереженням порядку.
3. **Добре масштабується** на великих колекціях та в гарячих циклах.

#### На що звернути увагу:

- Порядок елементів після операції змінюється.
- Потрібна перевірка коректності індексу.
- Для `slice` з pointer-типами інколи доречно занулити хвостовий елемент перед
  укороченням, щоб не тримати зайві посилання в пам'яті.

#### Висновок:

Коли стабільний порядок не є вимогою бізнес-логіки, «swap with last + truncate»
є канонічним і найшвидшим способом видалення елемента зі `slice` у Go.

#### Приклад:

```go
func removeUnordered[T any](s []T, i int) []T {
	last := len(s) - 1
	s[i] = s[last]
	var zero T
	s[last] = zero // опційно: щоб не тримати зайве посилання
	return s[:last]
}
```

</details>

<details>
<summary>13. Який порядок ітерації ключів у `map` і чи можна на нього покладатися? Як це впливає на тести та серіалізацію?</summary>

#### Go

У Go порядок ітерації ключів у `map` є **недетермінованим**. Це означає, що під
час `for range` послідовність ключів може відрізнятися між запусками програми і
навіть між окремими ітераціями в межах одного запуску.

#### Чи можна покладатися на порядок:

1. **Ні, не можна.**
2. Порядок у `map` не є частиною контракту мови.
3. Будь-яка логіка, що неявно спирається на «стабільний» порядок, є
   потенційно дефектною.

#### Як це впливає на тести:

1. **Flaky-тести:** порівняння рядків/масивів, сформованих із `map`, може
   випадково падати через інший порядок елементів.
2. **Хибні регресії:** змін у бізнес-логіці немає, але тест падає через
   нестабільний output.
3. **Правильний підхід:** у тестах потрібно або:
- порівнювати структури як множини/асоціативні колекції;
- або попередньо сортувати ключі та будувати детермінований результат.

#### Як це впливає на серіалізацію:

1. Якщо серіалізація будується на прямому обході `map`, текстовий результат
   може мати різний порядок полів/пар ключ-значення.
2. Це ускладнює:
- snapshot/golden-тести;
- хешування payload-ів;
- порівняння артефактів у CI.
3. Для стабільного output слід:
- отримати ключі окремо;
- відсортувати їх;
- формувати результат у фіксованій послідовності.

#### Висновок:

`map` у Go оптимізовано для швидкого доступу за ключем, а не для збереження
порядку. Тому в тестах, логуванні, підписі даних і серіалізації потрібно
свідомо вводити детермінізм через сортування ключів або інші канонічні правила.

</details>

<details>
<summary>14. Як ітерувати `map` у передбачуваному порядку?</summary>

#### Go

Оскільки `map` у Go не гарантує стабільного порядку обходу, передбачувану
ітерацію потрібно організовувати явно: спочатку зібрати ключі, потім
відсортувати їх, і лише після цього читати значення в цьому фіксованому порядку.

#### Канонічний підхід (Go 1.23+):

1. Використати `maps.Keys` для отримання ітератора ключів.
2. За допомогою `slices.Sorted` (`slices.SortedFunc`) отримати відсортований слайс ключів.
3. Ітерувати по відсортованому слайсу.

#### Чому це правильно:

1. **Детермінованість:** однаковий вхід дає однаковий порядок результату.
2. **Стабільні тести:** зникають випадкові падіння через різну послідовність.
3. **Передбачувана серіалізація:** простіше робити golden-тести, підписи,
   порівняння артефактів.

#### Важливі нюанси:

- Для ключів-структур або власних типів потрібно визначити явний критерій
  сортування.
- Складність зростає через сортування (`O(n log n)`), але це плата за
  передбачуваність.
- Якщо порядок критично важливий у гарячому шляху, інколи доцільно розглянути
  іншу структуру даних (наприклад, підтримувати окремий впорядкований список
  ключів).

#### Висновок:

Передбачувана ітерація `map` у Go — це завжди свідома трифазна стратегія:
«зібрати ключі → відсортувати → обійти». Саме цей патерн вважається
продакшн-стандартом для стабільного output. Компактна форма через
`slices.Sorted(maps.Keys(m))` доступна починаючи з Go 1.23.

#### Приклад:

```go
keys := slices.Sorted(maps.Keys(m))
for _, k := range keys {
	fmt.Printf("%v=%v\n", k, m[k])
}
```

</details>

<details>
<summary>15. Чому не можна брати адресу елемента мапи?</summary>

#### Go

У Go не можна взяти адресу елемента `map` (наприклад, `&m[key]`), бо значення в
`map` не має стабільної адреси в пам'яті. Під час росту, ребалансування або
внутрішньої реорганізації `map` runtime може переміщувати елементи між бакетами.

#### Ключова причина обмеження:

1. **Нестабільність розміщення:** `map` динамічно змінює внутрішню структуру.
2. **Небезпека «висячих» pointer-ів:** адреса, отримана сьогодні, може стати
   невалідною після наступних операцій з `map`.
3. **Гарантія безпеки мови:** компілятор забороняє таку операцію, щоб уникнути
   прихованих memory-багів.

#### Практичні наслідки:

1. Ви не можете напряму змінювати поле структури через `m[key].Field = ...`
   якщо значенням мапи є структура.
2. Патерн оновлення для map-value-struct виглядає так:
- прочитати значення в тимчасову змінну;
- змінити її;
- записати назад у `map`.

#### Коли потрібна мутабельність за адресою:

- Використовуйте `map[K]*T` замість `map[K]T`, якщо вам необхідно працювати з
  одним і тим самим об'єктом через pointer.
- Але пам'ятайте про компроміси: додаткові алокації, питання життєвого циклу
  об'єктів і потребу в синхронізації при конкурентному доступі.

#### Висновок:

Заборона брати адресу елемента `map` — це свідомий дизайн Go на користь
memory-safety. Якщо потрібні зміни «на місці», обирайте або цикл
read-modify-write, або `map` зі значеннями-вказівниками.

</details>

<details>
<summary>16. Чому `map` в Go не є потокобезпечною «з коробки»?</summary>

#### Go

`map` у Go не є потокобезпечною за задумом мови: одночасний доступ із кількох
горутин без синхронізації (особливо коли є запис) призводить до data race і
невизначеної поведінки.

#### Чому так зроблено:

1. **Продуктивність у базовому сценарії:** більшість `map` використовуються
   локально в одній горутині; вбудований lock для кожної операції зробив би ці
   сценарії повільнішими.

2. **Явна модель конкурентності:** Go покладає контроль синхронізації на
   розробника, щоб той обирав механізм під конкретний workload.

3. **Гнучкість архітектури:** різні задачі потребують різних стратегій
   (mutex, sharding, actor-підхід, `sync.Map`), і «універсальний» автолок не
   дає оптимуму для всіх випадків.

#### Що це означає на практиці:

1. **Concurrent read + write без захисту — заборонено.**
2. **Write + write без захисту — заборонено.**
3. **Лише read + read** може бути безпечним, якщо ніхто не модифікує `map`.

#### Як робити правильно:

- `map` + `sync.Mutex` або `sync.RWMutex` для керованої синхронізації.
- `sync.Map` для специфічних патернів доступу (багато читань, рідкісні записи
  або незалежні ключі).
- Архітектурна ізоляція стану через одну «власницьку» горутину і канали.

#### Висновок:

Непотокобезпечність `map` «з коробки» — це не вада, а свідомий компроміс Go:
мінімальні накладні витрати в загальному випадку та повний контроль конкурентної
безпеки в руках інженера.

</details>

<details>
<summary>17. Чи може структура бути ключем у `map` і які обмеження на це накладаються? Чим це краще за вкладені map?</summary>

#### Go

Так, у Go структура може бути ключем у `map`, **якщо вона порівнювана**
(`comparable`). Це означає, що всі її поля також мають бути порівнюваними.

#### Обмеження для struct-ключа:

1. **Усі поля структури мають бути comparable.**
- Дозволені, зокрема: числа, рядки, bool, вказівники, масиви (з comparable
  елементами), інші comparable-структури.
- Заборонені в ключі поля типів: `slice`, `map`, `func` (вони не comparable).

2. **Порівняння відбувається за значенням усіх полів.**
- Два ключі вважаються однаковими лише тоді, коли рівні всі відповідні поля.

3. **Ключ має бути стабільним після вставки.**
- Змінювати «сенс» ключа через зовнішній мутабельний стан — погана практика, бо
  це руйнує передбачуваність доступу.

#### Чим struct-ключ часто кращий за вкладені `map`:

1. **Простіша модель даних:**
- Замість `map[A]map[B]V` можна використати `map[CompositeKey]V`, де
  `CompositeKey` — структура з полями `A`, `B`.

2. **Менше бойлерплейту і перевірок на `nil`:**
- У вкладених `map` треба ініціалізувати внутрішні мапи та обробляти проміжні
  відсутності ключів.

3. **Краща локальність логіки:**
- Усі виміри ключа зібрані в одному типі, що підвищує читабельність і
  підтримуваність.

4. **Менше простору для помилок:**
- Легше уникнути частково ініціалізованих структур і неузгоджених шляхів доступу.

#### Коли вкладені `map` можуть бути доречні:

- Коли потрібна ієрархічна семантика даних.
- Коли часто оперують проміжними зрізами на рівні першого ключа.
- Коли різні рівні мають окремі правила життєвого циклу.

#### Висновок:

Struct-ключ у Go — потужний і чистий інструмент для композитної адресації. Якщо
тип ключа коректно спроєктовано й він `comparable`, це рішення нерідко
елегантніше та надійніше за вкладені `map`.

</details>

<details>
<summary>18. Як порівнювати дві структури — коли це компілюється, а коли ні?</summary>

#### Go

У Go дві структури можна порівнювати оператором `==` або `!=` лише тоді, коли
тип структури є `comparable`. Практично це означає: **усі поля структури мають
бути порівнюваними**.

#### Коли порівняння компілюється:

1. Структури мають однаковий тип.
2. Кожне поле в структурі — comparable-тип.
3. Порівняння виконується за значенням усіх полів.

#### Коли порівняння не компілюється:

1. Якщо хоча б одне поле має непорівнюваний тип:
- `slice`
- `map`
- `func`

2. Якщо намагаються порівняти різні типи структур, навіть із подібними полями.

#### Важливі уточнення:

1. **Масиви порівнювані**, якщо їхні елементи порівнювані.
2. **Вказівники порівнювані** (порівнюються адреси).
3. **Інтерфейси порівнювані**, якщо динамічне значення всередині також
   порівнюване; інакше можливий runtime panic під час порівняння.

#### Практичний висновок:

- Якщо структура повністю з comparable-полів, сміливо використовуйте `==`.
- Якщо в структурі є `slice/map/func`, застосовуйте явне порівняння полів або
  окремі підходи (наприклад, спеціалізовану логіку порівняння), а не прямий
  оператор рівності.

</details>

<details>
<summary>19. Як реалізувати порівняння двох структур, якщо вони містять слайси або мапи? Що таке `reflect.DeepEqual()`?</summary>

#### Go

Якщо структура містить `slice` або `map`, пряме порівняння через `==` не
скомпілюється. У таких випадках порівняння треба реалізовувати окремо: або
вручну, або за допомогою утиліт глибокого порівняння.

#### Базові підходи:

1. **Явне порівняння полів (рекомендовано для критичної логіки):**
- порівнюєте прості поля напряму;
- для `slice` перевіряєте довжину та елементи;
- для `map` перевіряєте кількість ключів і відповідність значень.

2. **`reflect.DeepEqual(a, b)`:**
- виконує рекурсивне («глибоке») порівняння складних структур;
- зручний для швидких перевірок, прототипів і частини тестових сценаріїв.

#### Що таке `reflect.DeepEqual()`:

`reflect.DeepEqual()` — функція стандартного пакета `reflect`, яка намагається
визначити глибоку рівність двох значень, проходячи вкладені поля, елементи
колекцій і структури даних рекурсивно.

#### Нюанси `reflect.DeepEqual`, про які важливо пам'ятати:

1. **Семантика може не збігатися з бізнес-рівністю:**
- наприклад, `nil`-slice і порожній `[]T{}` часто трактуються по-різному.

2. **Менш прозора діагностика:**
- при падінні складніше зрозуміти, яке саме поле відрізняється, без додаткових
  інструментів.

3. **Продуктивність:**
- рефлексія повільніша за спеціалізоване ручне порівняння в гарячих шляхах.

#### Коли що обирати:

1. **Продакшн-бізнес-правила:** явне доменне порівняння (чітка семантика).
2. **Тести й допоміжні перевірки:** `reflect.DeepEqual` або більш спеціалізовані
   тестові бібліотеки.
3. **Критично важливі сценарії:** уникайте «магії» рефлексії там, де потрібен
   строгий контроль еквівалентності.

#### Висновок:

Для структур із `slice/map` правильне порівняння — це насамперед питання
семантики, а не техніки. `reflect.DeepEqual()` корисний інструмент, але
інженерно найнадійнішим лишається явний, доменно обґрунтований спосіб
порівняння.

</details>

<details>
<summary>20. Що відбувається при приведенні між іменованими типами з однаковою структурою, якщо в них різні методи?</summary>

#### Go

У Go приведення між іменованими типами з однаковою підлеглою структурою
стосується **лише значення даних**, але не «переносить» методи. Тобто після
конвертації ви отримуєте нове значення іншого іменованого типу з його власним
method set.

#### Головний принцип:

1. **Конвертація змінює тип значення, а не об'єднує поведінку типів.**
2. **Методи належать конкретному іменованому типу**, на якому їх оголошено.
3. Після `T2(vT1)` доступні методи `T2`, а методи `T1` вже недоступні напряму.

#### Що зберігається під час приведення:

1. Бітове/логічне представлення полів (за правилами сумісності типів).
2. Значення даних.

#### Що не зберігається:

1. Метод-сет вихідного типу.
2. Автоматична відповідність інтерфейсам, яку давав початковий тип.

#### Практичні наслідки:

1. Два типи з однаковими полями можуть мати різну поведінку в API.
2. Після конвертації код може перестати компілюватися в місцях, де очікувався
   інтерфейс, реалізований лише вихідним типом.
3. Це корисно для доменного моделювання: однакова структура даних, але різні
   семантичні ролі та контракти.

#### Висновок:

У Go конвертація між іменованими типами — це зміна «ідентичності» типу, а не
наслідування поведінки. Дані можуть бути однаковими, але методи та інтерфейсні
можливості визначаються виключно цільовим типом.

</details>

<details>
<summary>21. Що таке `Memory Alignment` (вирівнювання) і як воно впливає на розмір структур?</summary>

#### Go

`Memory Alignment` (вирівнювання) — це правило розміщення даних у пам'яті за
адресами, кратними певному кроку (alignment requirement) для конкретного типу.
Процесор і runtime читають такі дані швидше та безпечніше, коли ці вимоги
дотримані.

#### Як це працює у структурах:

1. Кожне поле має власну вимогу вирівнювання (наприклад, `int64` зазвичай
   вимагає суворішого вирівнювання, ніж `byte`).
2. Між полями компілятор може додавати **padding** (службові байти-заповнювачі),
   щоб наступне поле починалося з коректної адреси.
3. Наприкінці структури також може бути tail-padding, щоб масив таких структур
   зберігав правильне вирівнювання кожного елемента.

#### Вплив на розмір структури:

1. **Розмір структури часто більший за суму розмірів полів** через padding.
2. **Порядок полів має значення:** невдале розташування (`byte`, `int64`,
   `byte`, ...) може суттєво збільшити загальний розмір.
3. **Оптимальне групування полів** (від більших за вирівнюванням до менших)
   зазвичай зменшує обсяг пам'яті.

#### Чому це важливо на практиці:

1. Менший розмір структур = краща cache locality.
2. Менше споживання RAM у великих масивах/кешах/індексах.
3. Вищий throughput у гарячих шляхах через зниження memory pressure.

#### Інженерний висновок:

Вирівнювання — це не «низькорівнева екзотика», а практичний фактор продуктивності.
У Go правильний порядок полів у структурі напряму впливає на її розмір, а отже —
на ефективність пам'яті та швидкодію системи.

</details>

<details>
<summary>22. Чому передача великої структури «за значенням» часто працює повільніше, ніж передача вказівника?</summary>

#### Go

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

#### Чому виникає різниця в продуктивності:

1. **Вартість копіювання пам'яті:**
   чим більша структура, тим більше байтів треба скопіювати на вході/виході
   викликів.

2. **Навантаження на кеш процесора:**
   масивні копії збільшують трафік пам'яті та можуть погіршувати cache locality
   у гарячих ділянках коду.

3. **Каскадний ефект у циклах і конвеєрах:**
   якщо структура передається багаторазово, накладні витрати накопичуються.

4. **Потенційний вплив на алокації:**
   у деяких сценаріях копіювання та escape-поведінка можуть підсилювати тиск на
   runtime і GC.

#### Коли вказівник часто кращий:

1. Коли структура велика й часто передається між функціями.
2. Коли потрібно змінювати спільний стан без додаткового копіювання.
3. Коли важлива стабільна latency-поведінка під навантаженням.

#### Але не завжди pointer — автоматично краще:

1. Для маленьких структур передача за значенням може бути простішою й цілком
   ефективною.
2. Значення дає кращу ізоляцію стану (немає неявного shared mutable state).
3. Pointer додає ризики aliasing і потребу уважнішої синхронізації в
   конкурентному коді.

#### Практичний висновок:

У Go вибір між value і pointer роблять не догматично, а за профілем даних:
великі структури й часті виклики схиляють до вказівника; малі immutable-подібні
дані часто доречно передавати за значенням.

</details>

<details>
<summary>23. Чому `map` повільніший за `slice` при sequential access і коли обрати що?</summary>

#### Go

За послідовного доступу (`sequential access`) `slice` зазвичай швидший за `map`,
оскільки елементи `slice` розташовані компактно й читаються лінійно, тоді як
`map` виконує хешування ключа та доступ до більш складної внутрішньої структури.

#### Чому `slice` швидший у послідовному проході:

1. **Лінійне розміщення в пам'яті:**
   елементи лежать поруч, що добре узгоджується з кешами CPU.

2. **Простий доступ за індексом:**
   мінімум допоміжних операцій на кожен елемент.

3. **Краща передбачуваність для процесора:**
   лінійний патерн знижує кількість cache misses.

#### Чому `map` повільніша в цьому сценарії:

1. **Хешування ключів** додає обчислювальні витрати.
2. **Нерівномірне розміщення бакетів** гірше для локальності пам'яті.
3. **Складніша логіка доступу** (пошук у бакетах, колізії, службові перевірки).

#### Коли обирати `slice`:

1. Дані проходяться послідовно.
2. Потрібні ітерації, сортування, batch-обробка.
3. Ключем фактично є позиція (індекс), а не довільний ідентифікатор.

#### Коли обирати `map`:

1. Потрібен швидкий доступ за ключем (`id`, `name`, composite key).
2. Важлива семантика множини/словника.
3. Пошук за значенням ключа домінує над повним лінійним обходом.

#### Практичний висновок:

`slice` — інструмент для упорядкованих, щільних ітерацій; `map` — для адресного
доступу за ключем. Якщо workload здебільшого послідовний, `slice` зазвичай дає
кращу продуктивність і менші накладні витрати.

</details>

<details>
<summary>24. Як перевірити, чи змінна реалізує інтерфейс?</summary>

#### Go

У Go реалізація інтерфейсу є неявною: тип вважається таким, що реалізує
інтерфейс, якщо має весь потрібний набір методів. Тому перевірка можлива як на
етапі компіляції, так і під час виконання.

#### 1) Перевірка на етапі компіляції (рекомендовано):

Найнадійніший підхід — додати compile-time assertion:

```go
var _ MyInterface = (*MyType)(nil)
```

Що це означає:

1. Якщо `*MyType` не реалізує `MyInterface`, код не скомпілюється.
2. Це документує контракт типу прямо в кодовій базі.
3. Особливо корисно для публічних API, адаптерів і великих команд.

#### 2) Перевірка під час виконання (runtime):

Коли є значення типу `any`/інтерфейсу, застосовують type assertion:

```go
v, ok := x.(MyInterface)
```

1. `ok == true` — значення реалізує інтерфейс.
2. `ok == false` — не реалізує.
3. Варіант без `ok` може спричинити panic, тому в продакшн-коді зазвичай
   використовують безпечну форму з `ok`.

#### Pointer vs value receiver — критичний нюанс:

1. Метод-сет `T` і `*T` відрізняється.
2. Часто саме `*T` реалізує інтерфейс, а `T` — ні.
3. На співбесіді важливо явно проговорити цей момент, бо це типове джерело
   помилок.

#### Висновок:

Найкраща практика — фіксувати реалізацію інтерфейсу compile-time assertion-ом, а
runtime-перевірку через assertion використовувати там, де тип значення відомий
лише під час виконання.

</details>

<details>
<summary>25. Що таке `type assertion` та `type switch` — яка від них користь і як обробити assertion без паніки?</summary>

#### Go

`type assertion` і `type switch` у Go — це механізми роботи з інтерфейсними
значеннями, коли фактичний (динамічний) тип потрібно уточнити під час
виконання.

#### Що таке `type assertion`:

`type assertion` має форму:

```go
v, ok := x.(T)
```

1. `x` — значення інтерфейсного типу.
2. `T` — тип, до якого намагаємося привести.
3. `ok == true` означає, що динамічний тип сумісний із `T`.

#### Користь `type assertion`:

1. Дозволяє отримати доступ до специфічної поведінки конкретного типу.
2. Дає змогу безпечно працювати з `any`/інтерфейсами в адаптерах, декодерах,
   middleware.
3. Корисний, коли очікується один конкретний тип.

#### Як уникнути паніки:

Небезпечна форма:

```go
v := x.(T) // panic, якщо x не є T
```

Безпечна форма:

```go
v, ok := x.(T)
if !ok {
    // обробити невідповідність типу
}
```

Саме двозначна форма з `ok` є продакшн-стандартом.

#### Що таке `type switch`:

`type switch` — зручний спосіб обробити кілька можливих типів одразу:

```go
switch v := x.(type) {
case string:
    // ...
case int:
    // ...
default:
    // ...
}
```

#### Користь `type switch`:

1. Робить розгалуження за типами читабельним.
2. Зменшує каскад множинних assertion-ів.
3. Дає чіткий `default`-шлях для невідомих типів.

#### Коли що використовувати:

1. **`type assertion`** — коли перевіряємо один очікуваний тип.
2. **`type switch`** — коли допускаємо кілька типів і потрібна різна логіка для
   кожного.

#### Висновок:

`type assertion` і `type switch` — це керований спосіб «розкрити» динамічний тип
інтерфейсного значення. Щоб уникати аварій, assertion слід робити у безпечній
формі `v, ok := ...` і завжди мати сценарій обробки `ok == false`.

</details>

<details>
<summary>26. Чому `interface{}` і `any` ідентичні, але `*interface{}` майже завжди помилка?</summary>

#### Go

У Go `any` — це лише псевдонім (`alias`) для `interface{}`. Тобто з погляду
типової системи вони абсолютно однакові: різниця лише стилістична та
семантична для читабельності коду.

#### Чому `interface{}` == `any`:

1. `any` введено для кращої виразності, особливо в generics-коді.
2. Компілятор трактує `any` і `interface{}` як той самий тип.
3. Поведінка під час присвоєння, assertion, switch — ідентична.

#### Чому `*interface{}` майже завжди помилка:

1. **Інтерфейс уже є «контейнером посилання» на значення + тип.**
   Додавати ще один pointer-рівень зазвичай немає сенсу.

2. **Ускладнення семантики nil:**
   з `*interface{}` з'являється ще один шар станів (`nil` pointer, ненульовий
   pointer на nil-interface тощо), що породжує неочевидні баги.

3. **Гірша читабельність і API-дизайн:**
   такий тип майже завжди сигналізує, що модель даних або сигнатура функції
   спроєктовані невдало.

4. **Замість `*interface{}` зазвичай достатньо:**
- або передати `interface{}`/`any` за значенням;
- або використати конкретний pointer-тип (`*T`), якщо потрібна мутабельність
  саме об'єкта `T`.

#### Коли `*interface{}` може трапитися:

- У вузьких технічних сценаріях (де потрібно змінити саме інтерфейсну змінну як
  комірку), але в прикладному продакшн-коді це рідкісний і переважно небажаний
  патерн.

#### Висновок:

`any` і `interface{}` — тотожні. Натомість `*interface{}` у більшості випадків
є зайвою абстракцією, яка ускладнює код і збільшує ризик логічних помилок.

</details>

<details>
<summary>27. Коли варто використовувати `interface{}` (`any`), а коли це вважається поганим тоном?</summary>

#### Go

`any` (тобто `interface{}`) доцільний там, де тип значення об'єктивно невідомий
на межі API. Водночас надмірне використання `any` у доменній логіці зазвичай
погіршує типобезпеку й ускладнює супровід.

#### Коли `any` справді виправданий:

1. **Інфраструктурні шари та універсальні контейнери:**
   логування, generic-обгортки, middleware, низькорівневі бібліотеки.

2. **Декодування слабко типізованих форматів:**
   наприклад, частини JSON із непередбачуваною схемою.

3. **Точки інтеграції з зовнішніми API:**
   коли контракт динамічний і строгий тип неможливо зафіксувати наперед.

4. **Перехідні етапи рефакторингу:**
   як тимчасовий компроміс із подальшим поверненням до конкретних типів.

#### Коли це поганий тон:

1. **У бізнес-моделі, де тип відомий:**
   `any` ховає помилки до runtime замість compile-time.

2. **Коли `any` підміняє нормальний дизайн API:**
   множинні assertion-и й type switch-и в кожному другому місці — симптом
   невизначених контрактів.

3. **Коли можна використати generics або інтерфейс із мінімальним методом:**
   це дає строгіші й читабельніші обмеження.

4. **Коли `any` потрапляє «всюди» за інерцією:**
   код стає крихким, важче тестується й складніше еволюціонує.

#### Практичне правило:

- За замовчуванням обирайте **конкретний тип**.
- Якщо потрібна абстракція поведінки — **інтерфейс із чітким контрактом**.
- Якщо потрібна узагальненість даних — **generics**.
- `any` лишайте для справді динамічних меж системи.

#### Висновок:

`any` — корисний інструмент, але не універсальна відповідь. У зрілому Go-коді
його застосовують точково: там, де невизначеність типу є природною, а не там,
де можна і треба виразити строгий контракт.

</details>

<details>
<summary>28. У чому перевага прийому інтерфейсів та повернення конкретних структур?</summary>

#### Go

У Go поширений і вкрай практичний принцип: **приймай інтерфейси, повертай
структури**. Його сила в тому, що вхідні залежності залишаються гнучкими, а
вихідні контракти — чіткими й багатими на можливості.

#### Що означає «приймай інтерфейси»:

1. Функція/метод приймає мінімальний поведінковий контракт (наприклад,
   `io.Reader`), а не жорстко конкретний тип.
2. Це зменшує зв'язаність (coupling) між модулями.
3. Спрощує тестування: легко підставити stub/mock/fake з потрібними методами.

#### Що означає «повертай структури»:

1. Виклик отримує конкретний тип із повним набором його методів.
2. API стає прозорішим: користувач бачить реальні можливості об'єкта.
3. Легше еволюціонувати тип без ламання зовнішніх інтерфейсних контрактів.

#### Чому це поєднання ефективне:

1. **На вході — абстракція, на виході — конкретика.**
2. **Вища гнучкість інтеграції** без втрати виразності API.
3. **Краща підтримуваність:** межі модулів чіткі, залежності контрольовані.
4. **Простіший рефакторинг:** внутрішні зміни легше робити без каскадних правок.

#### Коли варто бути обережним:

1. Не створювати інтерфейси «про запас» без реальної потреби.
2. Інтерфейс має жити там, де його споживають, а не там, де реалізують.
3. Якщо потрібна лише одна реалізація і немає тестової користі, зайва
   абстракція може шкодити читабельності.

#### Висновок:

Прийом інтерфейсів і повернення конкретних структур — це баланс між
розширюваністю та ясністю. Саме він дозволяє писати Go-код, який одночасно
зручно тестувати, легко підтримувати і природно розвивати.

</details>

<details>
<summary>29. Навіщо в Go використовують інтерфейси з одним методом (наприклад `io.Reader`, `fmt.Stringer`) і яку архітектурну користь це дає?</summary>

#### Go

Однометодові інтерфейси в Go — це концентрований контракт поведінки: вони
описують рівно одну здатність об'єкта, без зайвого навантаження на API. Саме
тому `io.Reader`, `io.Writer`, `fmt.Stringer` стали фундаментальними
будівельними блоками екосистеми.

#### Чому цей підхід такий сильний:

1. **Мінімальний контракт:**
   типу достатньо реалізувати один метод, щоб інтегруватися з великою кількістю
   компонентів.

2. **Низька зв'язаність:**
   модулі залежать від здатності, а не від конкретної реалізації чи великого
   «товстого» інтерфейсу.

3. **Композиційність:**
   складні можливості легко будуються з комбінацій малих інтерфейсів.

4. **Просте тестування:**
   для тесту достатньо маленького fake/stub з одним методом.

#### Архітектурна користь:

1. **Плагіноподібна взаємозамінність реалізацій:**
   файл, мережевий сокет, буфер у пам'яті можуть однаково працювати як
   `io.Reader`.

2. **Стабільні межі модулів:**
   залежності між шарами системи стають чіткими та еволюційно стійкими.

3. **Легка еволюція коду:**
   нову реалізацію можна додати без зміни споживачів, якщо контракт збережено.

4. **Читабельність наміру:**
   сигнатура функції одразу відповідає на питання «що потрібно від аргументу».

#### Практичний висновок:

Однометодові інтерфейси — це не стилістична прикраса, а архітектурна стратегія
Go: малі контракти, висока композиційність, проста тестованість і керована
масштабованість системи.

</details>

<details>
<summary>30. Чому `nil != nil` в Go і як це пов'язано з інтерфейсами?</summary>

#### Go

Фраза «`nil != nil`» у Go зазвичай стосується інтерфейсів і означає таке:
інтерфейсне значення може містити **тип + значення**, де значення всередині —
`nil`, але сам інтерфейс при цьому не є `nil`.

#### Як влаштований інтерфейс концептуально:

Інтерфейс складається з двох частин:

1. **Динамічний тип**
2. **Динамічне значення**

Інтерфейс дорівнює `nil` лише тоді, коли **обидві** частини відсутні.

#### Де виникає пастка:

1. Маємо `var p *MyType = nil`.
2. Присвоюємо `var i any = p`.
3. Тепер `i` містить:
- тип: `*MyType`
- значення: `nil`

Отже, `i != nil`, бо типова частина заповнена.

#### Практичні наслідки:

1. Перевірка `if err != nil` або `if x != nil` може поводитися не так, як
   очікує розробник, якщо в інтерфейс загорнуто typed nil.
2. Це типове джерело багів у помилках, фабриках, middleware, DI-коді.

#### Як уникати проблем:

1. Повертати `nil` саме як «порожній інтерфейс», а не typed nil усередині
   інтерфейсу.
2. Обережно конструювати `error` та інші інтерфейсні результати.
3. За потреби робити явну перевірку конкретного типу через assertion/switch.

#### Висновок:

У Go «`nil != nil`» — це не парадокс, а наслідок двокомпонентної природи
інтерфейсу. Ключове правило: інтерфейс є `nil` лише коли в ньому одночасно
немає ні динамічного типу, ні динамічного значення.

#### Приклад:

```go
var p *bytes.Buffer = nil
var x any = p

fmt.Println(p == nil) // true
fmt.Println(x == nil) // false: type=*bytes.Buffer, value=nil
```

</details>

<details>
<summary>31. Чи можна викликати методи на `nil`-значеннях і де це активно використовується?</summary>

#### Go

Так, у Go метод можна викликати на `nil`-значенні, **якщо це допустимо з погляду
типу receiver-а**. Найчастіше йдеться про методи з pointer receiver (`*T`), де
отримувач може бути `nil`.

#### Ключова ідея:

1. Виклик методу на `nil`-pointer технічно можливий.
2. Питання в тому, що робить код методу всередині.
3. Якщо метод розіменовує receiver без перевірки, отримаємо panic.

#### Коли це працює безпечно:

1. Метод явно обробляє `nil` receiver:
- повертає дефолтне значення;
- повертає помилку;
- поводиться як no-op.

2. Такий дизайн інколи свідомо застосовують для зручного API.

#### Де це реально використовується:

1. **Error-типи й обгортки:**
   методи на pointer-типах можуть коректно працювати з `nil`, щоб спростити
   обробку помилок.

2. **Linked/list/tree-подібні структури:**
   `nil`-вузол може трактуватися як порожній стан із коректною поведінкою.

3. **Сервісні об'єкти з optional-компонентами:**
   `nil` receiver інколи використовується як «вимкнений» або «порожній» режим.

#### Важливий нюанс з інтерфейсами:

Якщо `nil` pointer загорнуто в інтерфейс, сам інтерфейс може бути не-`nil`.
Тому перевірки на `nil` треба робити уважно, щоб уникати хибної впевненості.

#### Практичний висновок:

Методи на `nil`-значеннях у Go — легітимний інструмент, але тільки за умови
свідомого API-дизайну: або безпечна обробка `nil` всередині методу, або чітка
документація, що виклик на `nil` неприпустимий.

</details>

<details>
<summary>32. Як вказати головній горутині очікувати завершення роботи всіх робочих горутин?</summary>

#### Go

Канонічний спосіб дочекатися завершення всіх робочих горутин у Go — використати
`sync.WaitGroup`. Він дає просту й надійну модель: збільшити лічильник перед
запуском роботи, зменшити після завершення, а в головній горутині викликати
`Wait()`.

#### Базова схема:

1. Створити `var wg sync.WaitGroup`.
2. Перед кожною горутиною викликати `wg.Add(1)`.
3. Усередині горутини виконати `defer wg.Done()`.
4. У головній горутині викликати `wg.Wait()`.

#### Чому це працює:

1. `WaitGroup` рахує кількість незавершених задач.
2. `Wait()` блокує виконання, доки лічильник не стане нулем.
3. Це гарантує, що `main` не завершиться раніше за робочі горутини.

#### Типові помилки, яких слід уникати:

1. Викликати `Add(1)` **після** старту горутини (ризик race і некоректного
   завершення).
2. Забути `Done()` у гілці помилки або раннього `return`.
3. Повторно використовувати той самий `WaitGroup` у різних фазах без чіткої
   синхронізації.

#### Коли краще `errgroup`:

Якщо, крім очікування, потрібно ще й:

1. зібрати першу помилку,
2. скасувати інші задачі через `context`,

то практичніше застосувати `errgroup.Group`.

#### Висновок:

Для задачі «дочекатися завершення всіх горутин» стандартним інструментом є
`sync.WaitGroup`: простий контракт, передбачувана поведінка й продакшн-надійність.

#### Приклад:

```go
var wg sync.WaitGroup

for i := 0; i < 3; i++ {
	wg.Add(1)
	go func(id int) {
		defer wg.Done()
		fmt.Println("worker", id)
	}(i)
}

wg.Wait()
```

</details>

<details>
<summary>33. Чому в циклах використовували шаблон `value := value` і чи він актуальний після Go 1.22?</summary>

#### Go

Шаблон `value := value` історично застосовували в циклах `for range`, щоб
створити окрему локальну копію змінної і безпечно захопити її в замиканні
(closure), зокрема в горутині.

#### Чому це було потрібно до Go 1.22:

1. Ітераційна змінна в `range` фактично перевикористовувалась між ітераціями.
2. Замикання часто захоплювало одну й ту саму змінну, а не її «моментальне»
   значення.
3. У результаті горутини бачили неочікувані дані (зазвичай останнє значення).

Тому писали:

`v := v`

щоб створити нову змінну в межах ітерації.

#### Що змінилося після Go 1.22:

1. Семантику `range` змінено: для кожної ітерації змінні циклу мають окремі
   значення для захоплення в closure.
2. Типовий баг із «пізнім» значенням у горутинах усунуто на рівні мови.
3. У більшості сучасних кейсів шаблон `value := value` більше не потрібен.

#### Чи актуальний шаблон сьогодні:

1. **Для коду, що гарантовано працює на Go 1.22+** — зазвичай ні.
2. **Для проєктів зі старішими версіями Go** — так, може бути необхідним.
3. **Для змішаних середовищ/бібліотек** варто орієнтуватися на найнижчу
   підтримувану версію.

#### Практичний висновок:

`value := value` був захисним патерном від специфічної пастки `range`. Після
Go 1.22 потреба в ньому переважно зникла, але в legacy-коді або при підтримці
старих версій він залишається релевантним.

</details>

<details>
<summary>34. Чи може використання горутин сповільнити систему і в яких випадках?</summary>

#### Go

Так, може. Попри легковаговість горутин, вони не є «безкоштовними». Неправильне
або надмірне їх використання здатне зменшити продуктивність, підвищити latency й
ускладнити роботу runtime.

#### Коли горутини можуть сповільнювати систему:

1. **Надмірна кількість горутин (goroutine explosion):**
   тисячі або сотні тисяч задач без обмеження конкуренції створюють тиск на
   планувальник і пам'ять.

2. **Дрібнозернисті задачі:**
   якщо робота дуже мала, накладні витрати на запуск/координацію можуть бути
   більшими за корисну роботу.

3. **Інтенсивна синхронізація:**
   часті блокування (`mutex`, канали, `select`) створюють contention і знижують
   throughput.

4. **Невдалий обмін даними через канали:**
   зайві пересилання великих payload-ів або складні fan-in/fan-out топології
   можуть коштувати дорожче за простіші моделі.

5. **Відсутність backpressure:**
   коли продюсери генерують роботу швидше, ніж споживачі її обробляють,
   накопичуються черги, росте пам'ять і затримки.

6. **Проблеми з I/O та зовнішніми ресурсами:**
   надмірний паралелізм може перевантажити БД, мережу, файлову систему або
   сторонні API, що погіршує загальну систему, а не прискорює її.

#### Як уникати деградації:

1. Обмежувати конкуренцію (worker pool, semaphore, bounded queues).
2. Профілювати (`pprof`, trace), а не покладатися на інтуїцію.
3. Зменшувати спільний mutable state і lock contention.
4. Підбирати розмір паралелізму під реальний workload та ресурси.

#### Висновок:

Горутини прискорюють систему лише тоді, коли паралелізм керований. У продакшні
принцип простий: не «більше горутин», а «достатньо горутин із правильними
межами та синхронізацією».

</details>

<details>
<summary>35. У чому різниця між буферизованими та небуферизованими каналами? Коли замість каналів доречно використовувати slice + mutex?</summary>

#### Go

Канали в Go можуть бути буферизованими або небуферизованими, і ця різниця
визначає семантику синхронізації між горутинами. Вибір типу каналу — це вибір
моделі координації, а не просто «технічна дрібниця».

#### Небуферизований канал (`make(chan T)`):

1. **Синхронний обмін:** `send` блокується, доки інша горутина не виконає
   відповідний `receive` (і навпаки).
2. **Чіткий handoff:** добре підходить, коли потрібна жорстка синхронізація
   кроків.
3. **Мінімум черги:** дані не накопичуються в каналі.

#### Буферизований канал (`make(chan T, n)`):

1. **Асинхронніша взаємодія:** `send` не блокується, доки в буфері є місце.
2. **Керована черга:** дозволяє згладжувати короткі піки навантаження.
3. **Backpressure через місткість:** коли буфер заповнено, `send` знову
   блокується.

#### Коли доречно `slice + mutex` замість каналів:

1. **Потрібен спільний буфер із нетривіальними операціями:**
   batch-видалення, reorder, random access, складні правила агрегації.

2. **Коли модель — «спільний стан із явним lock», а не потік повідомлень:**
   канали не завжди найпростіший інструмент для mutable-колекцій.

3. **Коли важлива тонка оптимізація memory/layout:**
   `slice` дає пряміший контроль над структурою даних і операціями.

4. **Коли канальна архітектура створює зайву складність:**
   іноді `mutex` + чіткий інваріант простіше, читабельніше й швидше.

#### Практичне правило вибору:

1. **Канали** — для передачі подій/повідомлень між незалежними актороподібними
   горутинами.
2. **`slice + mutex`** — для керування спільною колекцією з багатим набором
   операцій над станом.

#### Висновок:

Буферизовані й небуферизовані канали відрізняються рівнем синхронності обміну.
Альтернатива `slice + mutex` виправдана тоді, коли вам потрібна саме керована
структура спільного стану, а не транспорт повідомлень.

#### Приклад:

```go
unbuf := make(chan int)    // надсилання чекає отримувача
buf := make(chan int, 100) // надсилання не блокується, поки є місце

buf <- 1
buf <- 2
```

</details>

<details>
<summary>36. Що станеться при читанні, записі або закритті `nil`-каналу?</summary>

#### Go

`nil`-канал у Go — це канал без ініціалізованого внутрішнього буфера й
механізмів синхронізації. Його поведінка суворо визначена і дуже важлива для
конкурентної логіки.

#### Поведінка `nil`-каналу:

1. **Читання з `nil`-каналу** — блокує назавжди.
2. **Запис у `nil`-канал** — блокує назавжди.
3. **Закриття `nil`-каналу** — викликає panic.

#### Чому так:

1. `nil`-канал не має «живої» структури, через яку можна виконати обмін.
2. Тому операції send/receive не можуть завершитися успішно.
3. `close(nil)` заборонений, бо закривати фактично нічого.

#### Практичні наслідки:

1. У звичайному коді випадковий `nil`-канал часто призводить до deadlock.
2. У `select` це може бути свідомим інструментом:
- гілка з `nil`-каналом стає неактивною;
- так динамічно «вимикають» певний кейс без додаткових прапорців.

#### Висновок:

Для `nil`-каналу send/receive — вічне блокування, а `close` — panic. Ця
властивість одночасно є джерелом типових помилок і потужним прийомом керування
`select`, якщо використовувати її свідомо.

</details>

<details>
<summary>37. Як і навіщо використовувати `nil`-канали в `select`? Чому `nil`-канал блокує назавжди і як це використати?</summary>

#### Go

`nil`-канал у `select` — це керований спосіб динамічно вмикати або вимикати
окремі гілки. Оскільки операції над `nil`-каналом не можуть завершитися,
відповідний `case` стає неактивним.

#### Чому `nil`-канал блокує назавжди:

1. Канал не ініціалізований (`var ch chan T`), тобто не має runtime-структури
   для send/receive.
2. `send` і `receive` не мають «точки зустрічі», тож чекають безстроково.
3. У `select` це означає: кейс із таким каналом ніколи не буде вибраний.

#### Як це використовувати в `select`:

1. **Динамічне вимкнення джерела подій:**
   присвоїти `ch = nil`, і гілка `case <-ch:` більше не активується.

2. **Керування життєвим циклом етапів pipeline:**
   після завершення певного етапу канал зануляють, щоб виключити його з
   подальшого вибору.

3. **Уникнення зайвих прапорців стану:**
   замість додаткових `if` усередині циклу логіка стану переноситься в сам
   механізм `select`.

#### Практичні застереження:

1. Якщо всі канали в `select` стали `nil` і немає `default`, отримаєте вічне
   блокування.
2. `close(nil)` викликає panic, тому занулення й закриття не можна плутати.
3. Код із `nil`-каналами потребує чітких інваріантів, інакше легко дістати
   важкий для дебагу deadlock.

#### Висновок:

`nil`-канал у `select` — це елегантний перемикач активності кейсів. Він корисний
для керованої конкурентної логіки, якщо уважно контролювати стани й уникати
ситуації, де всі шляхи стають заблокованими.

#### Приклад:

```go
var in <-chan int = source
for {
	select {
	case v, ok := <-in:
		if !ok {
			in = nil // вимикаємо гілку
			continue
		}
		_ = v
	case <-ctx.Done():
		return
	}
}
```

</details>

<details>
<summary>38. У яких випадках доцільно використовувати `select` із гілкою `default` і які сценарії це покриває?</summary>

#### Go

`select` із гілкою `default` робить операцію неблокувальною: якщо жоден канал не
готовий до обміну, керування негайно переходить у `default`. Це корисно для
контрольованої реактивності, але небезпечно при бездумному використанні.

#### Коли це доречно:

1. **Try-send / try-receive сценарії:**
   потрібно спробувати обмін і, якщо він неможливий зараз, піти альтернативним
   шляхом без блокування.

2. **Подієві цикли з фоновою роботою:**
   коли в очікуванні подій горутина має виконувати допоміжні дії (heartbeat,
   housekeeping, легка телеметрія).

3. **Backpressure і кероване скидання навантаження:**
   якщо буфер переповнений, у `default` можна відмовити/відкласти задачу замість
   блокування всього контуру.

4. **М'які таймаути/опитування стану:**
   у поєднанні з `time.Ticker` або іншою логікою дозволяє не «зависати» в
   очікуванні каналу.

#### Які ризики покриває і створює:

1. **Покриває ризик зависання** в критичних ділянках, де блокування неприпустиме.
2. **Але може створити busy loop** (активне крутіння CPU), якщо `default`
   спрацьовує занадто часто без паузи або осмисленої роботи.

#### Практичні застереження:

1. Не використовуйте `default`, якщо потрібна саме блокуюча синхронізація.
2. У циклах додавайте контроль темпу (`ticker`, `sleep`, ліміти), щоб уникнути
   марного споживання CPU.
3. Чітко фіксуйте політику: що робимо, коли канал не готовий (drop, retry,
   queue, log, metric).

#### Висновок:

`select` із `default` — інструмент неблокувальної конкурентності. Він доречний
там, де пріоритет — реактивність і керування навантаженням, але вимагає
дисципліни, аби не перетворити цикл обробки на неефективне активне опитування.

</details>

<details>
<summary>39. Як працює `select` при одночасному надходженні даних у кілька каналів?</summary>

#### Go

Якщо в момент виконання `select` готовими є кілька `case`, Go обирає один із
них псевдовипадково. Це зроблено, щоб уникати жорсткого пріоритету першої гілки
та зменшувати систематичне «голодування» окремих каналів.

#### Що відбувається крок за кроком:

1. Runtime перевіряє всі `case` у `select`.
2. Визначає множину готових операцій (send/receive, які можна виконати зараз).
3. Якщо готовий один `case` — виконується він.
4. Якщо готових кілька — обирається один псевдовипадково.
5. Якщо жоден не готовий:
- виконується `default` (якщо є),
- інакше `select` блокується до готовності хоча б одного `case`.

#### Практичні наслідки:

1. **Немає гарантії порядку обробки** між одночасно готовими каналами.
2. **Не можна кодувати бізнес-пріоритет** лише порядком `case` у `select`.
3. **Поведінка є конкурентно коректною, але недетермінованою**, що нормально для
   event-driven логіки.

#### Як реалізувати пріоритет, якщо він потрібен:

1. Будувати двофазний `select` (спочатку критичний канал, потім загальний).
2. Використовувати окремі черги/планувальник пріоритетів.
3. Застосовувати явну політику fair/priority у прикладному шарі, а не
   покладатися на випадковий вибір runtime.

#### Висновок:

За одночасної готовності кількох каналів `select` обирає один випадково
(псевдовипадково). Це добра стратегія для загальної fairness, але для
пріоритетної обробки потрібна явна архітектурна логіка поверх базового `select`.

</details>

<details>
<summary>40. Як безпечно закрити канал у Go, якщо в нього пишуть кілька горутин?</summary>

#### Go

Базове правило Go: канал закриває **той, хто володіє стороною запису**, і лише
після того, як гарантовано завершено всі `send`-операції. Для сценарію з
кількома writer-горутинами потрібна координація завершення.

#### Безпечний підхід (канонічний):

1. Запускаєте кілька writer-горутини.
2. Кожна writer після завершення роботи сигналізує про це (`WaitGroup.Done()`).
3. Окрема керівна горутина чекає `wg.Wait()`.
4. Лише після цього викликає `close(ch)`.

#### Чому це безпечно:

1. Жодна горутина не пише в канал після `close`.
2. Уникається panic `send on closed channel`.
3. Закриття відбувається рівно один раз у контрольованій точці.

#### Чого робити не можна:

1. Дозволяти кожному writer самостійно закривати спільний канал.
2. Закривати канал «про всяк випадок» із кількох місць.
3. Ловити panic як «механізм синхронізації» — це антипатерн.

#### Додаткові практики:

1. Для ранньої зупинки використовуйте окремий `done/context`, а не `close(dataCh)`
   з боку читачів.
2. Якщо потрібно гарантувати одноразове закриття в складній топології —
   застосовуйте `sync.Once`.

#### Висновок:

У багатописцевому сценарії канал безпечно закриває координатор після явного
підтвердження завершення всіх writer-горутини. Принцип простий: **many senders,
one closer, close-after-all-sends**.

#### Приклад:

```go
ch := make(chan int)
var wg sync.WaitGroup

for i := 0; i < 5; i++ {
	wg.Add(1)
	go func(v int) {
		defer wg.Done()
		ch <- v
	}(i)
}

go func() {
	wg.Wait()
	close(ch) // один координатор закриває канал
}()
```

</details>

<details>
<summary>41. Як реалізувати семафор через буферизований канал?</summary>

#### Go

У Go семафор природно моделюється буферизованим каналом фіксованої місткості.
Кількість слотів у буфері дорівнює максимально дозволеній кількості одночасних
операцій (паралелізму).

#### Принцип роботи:

1. **Acquire (зайняти слот):**
   перед початком роботи горутина виконує `sem <- token`.
   Якщо буфер заповнений, відправка блокується.

2. **Release (звільнити слот):**
   після завершення роботи горутина виконує `<-sem`.
   Це звільняє місце для наступної задачі.

#### Типова форма:

- `sem := make(chan struct{}, N)`
- `N` — ліміт одночасно активних задач.
- `struct{}` обирають як легковаговий маркер без payload.

#### Чому це ефективно:

1. **Проста модель backpressure:** надлишкові задачі природно чекають.
2. **Прозора синхронізація:** runtime Go виконує блокування/пробудження без
   ручного керування умовними змінними.
3. **Добре читається в коді:** намір «обмежити конкуренцію» видно одразу.

#### Практичні застереження:

1. Завжди робіть `release` через `defer`, щоб не втратити слот у разі помилки.
2. Для скасування очікування використовуйте `select` із `context.Done()`.
3. Не плутайте семафор (ліміт паралелізму) з чергою задач (worker pool).

#### Висновок:

Буферизований канал у Go — канонічна реалізація counting semaphore: проста,
надійна й добре інтегрована в модель горутин. Це один із найкращих способів
контролювати рівень конкурентності в продакшн-сервісах.

#### Приклад:

```go
sem := make(chan struct{}, 10) // максимум 10 одночасних задач

run := func(job Job) {
	sem <- struct{}{}         // зайняти слот
	defer func() { <-sem }() // звільнити слот
	job.Do()
}
```

</details>

<details>
<summary>42. Як реалізувати патерни `Fan-in` та `Fan-out`?</summary>

#### Go

`Fan-out` і `Fan-in` — базові конкурентні патерни в Go для керованого
паралелізму: перший розподіляє роботу на кілька виконавців, другий збирає
результати назад у спільний потік.

#### `Fan-out` (розгалуження навантаження):

1. Є вхідний канал задач.
2. Запускається `N` worker-горутини.
3. Кожен worker читає із спільного input-каналу та обробляє свою частину.

#### `Fan-in` (злиття результатів):

1. Кілька producer-каналів або worker-результатів.
2. Окремі merge-горутини пересилають дані в один output-канал.
3. Після завершення всіх merge-гілок output-канал закривається.

#### Типова архітектурна схема:

1. `jobs` канал → `fan-out` на worker-и.
2. Кожен worker пише в `results`.
3. `fan-in` агрегує `results` (або кілька `results`-каналів) в один канал для
   наступного етапу pipeline.

#### Критично важливі правила:

1. Закриття каналів має бути централізованим і одноразовим.
2. Використовуйте `WaitGroup` для координації завершення worker-ів.
3. Для дострокової зупинки застосовуйте `context`/`done`, щоб уникати витоків
   горутин.
4. Контролюйте розмір буферів і рівень паралелізму, щоб не перевантажити пам'ять
   або зовнішні залежності.

#### Висновок:

`Fan-out` масштабує обробку, `Fan-in` повертає контроль над потоком результатів.
Разом вони формують основу більшості ефективних pipeline-рішень у Go-сервісах.

</details>

<details>
<summary>43. Чому не варто використовувати канали для передачі великих обсягів даних?</summary>

#### Go

Канали в Go — чудовий інструмент для координації та передачі подій/невеликих
повідомлень, але не найкращий транспорт для масивних payload-ів. Для великих
обсягів даних вони часто створюють зайві накладні витрати.

#### Чому це може бути неефективно:

1. **Вартість копіювання:**
   передача великих значень через канал збільшує обсяг пам'яттєвих операцій і
   трафік між горутинами.

2. **Контеншн і синхронізаційні витрати:**
   канали мають внутрішню координацію доступу; при високому навантаженні це може
   стати bottleneck.

3. **Тиск на GC і пам'ять:**
   великі буфери каналів або численні великі повідомлення підвищують memory
   pressure і можуть збільшувати паузи/витрати runtime.

4. **Погіршення cache locality:**
   великі об'єкти гірше проходять через конкурентний конвеєр, ніж компактні
   сигнали + доступ до спільного сховища.

#### Кращі альтернативи:

1. Передавати через канал **посилання/дескриптори/індекси**, а не великі дані.
2. Зберігати payload у спільному буфері/пулі, а канал використовувати як
   сигнал готовності.
3. Використовувати worker pool із контрольованим доступом до спільної структури
   даних (`slice/map + mutex`) там, де це виправдано.

#### Коли канали все ж доречні:

1. Для невеликих повідомлень керування.
2. Для подій, команд, станів і сигналів завершення.
3. Для pipeline, де в каналі рухається легкий метаданний контекст.

#### Висновок:

Канал у Go — передусім механізм синхронізації і координації. Для великих
даних ефективніше розділяти: каналом передавати «що робити», а самі масивні
payload-и — через більш придатні структури пам'яті.

</details>

<details>
<summary>44. Як коректно повернути помилку з горутини в основний потік?</summary>

#### Go

Горутина не може «повернути» значення напряму через `return` у викликача.
Тому помилку з конкурентної задачі передають явно: через канал помилок або через
`errgroup`, який інкапсулює цей патерн.

#### Канонічні підходи:

1. **`errgroup.Group` + `context` (рекомендовано):**
   найзручніше для запуску групи горутин, збору першої помилки й скасування
   решти задач.

2. **Окремий `errCh` + `WaitGroup`:**
   явний контроль над життєвим циклом; після завершення всіх worker-ів канал
   закривають, а головний потік читає помилки.

#### Ключові правила коректності:

1. Помилки передаються в один погоджений канал/агрегатор.
2. Закриття `errCh` виконує координатор після завершення всіх writer-горутин.
3. За першої критичної помилки варто зупиняти інші задачі через `context`
   (щоб уникати марної роботи й витоків горутин).
4. Не можна ігнорувати помилки в конкурентних гілках — це породжує «тихі»
   дефекти.

#### Типова стратегія обробки:

1. Запустити worker-и з доступом до `ctx`.
2. На помилці відправити `error` у агрегатор.
3. Скасувати контекст (якщо потрібна fail-fast політика).
4. Дочекатися завершення всіх горутин.
5. Повернути узгоджений результат (перша помилка або агрегована помилка).

#### Висновок:

Коректне «повернення» помилки з горутини — це дисципліна явного каналу
комунікації плюс керування життєвим циклом через `WaitGroup`/`errgroup` і
`context`. У продакшні найчастіше оптимальним вибором є саме `errgroup`.

#### Приклад (Go 1.22+):

```go
g, ctx := errgroup.WithContext(context.Background())

for _, task := range tasks {
	g.Go(func() error {
		return task.Run(ctx)
	})
}

if err := g.Wait(); err != nil {
	return err
}
```

</details>

<details>
<summary>45. Чи може `defer` у Go перехопити (`recover`) паніку, яка сталася в дочірній горутині?</summary>

#### Go

Коротка відповідь: **ні**. `recover` працює лише в тій самій горутині, де сталася
паніка, і тільки в `defer`-функції, що виконується в її стеку викликів.

#### Головне правило:

1. Паніка не «перелітає» між горутинами як керований сигнал для `recover`.
2. `defer` у батьківській горутині не може зловити panic дочірньої.
3. Щоб перехопити panic у worker-горутини, `defer` з `recover` має бути
   всередині саме цієї worker-горутини.

#### Практичні наслідки:

1. Якщо panic у дочірній горутині не перехоплено локально, процес може впасти.
2. Для стабільних сервісів кожну «ризикову» горутину обгортають захисним
   `defer func(){ if r := recover(); r != nil { ... } }()`.
3. Після `recover` варто явно сигналізувати про збій у головний контур
   (через `error`-канал, `errgroup`, метрики, логування).

#### Що вважати доброю практикою:

1. Локальний `recover` у точці запуску довгоживучих worker-ів.
2. Чітка політика: panic перетворюється на помилку/алерт і не губиться мовчки.
3. Використання `context` для скоординованого завершення інших горутин після
   критичного збою.

#### Висновок:

`recover` у Go має локальну область дії — одну горутину. Тому перехоплення panic
в конкурентному коді треба проєктувати на рівні кожної дочірньої горутини
окремо.

</details>

<details>
<summary>46. Розкажіть про конкурентні патерни в Go.</summary>

#### Go

Конкурентні патерни в Go — це повторювані архітектурні схеми координації
горутин, каналів і синхронізаційних примітивів. Їхня мета — дати керований
паралелізм без хаосу, витоків і дедлоків.

#### Найуживаніші патерни:

1. **Worker Pool**
- фіксована кількість worker-горутини читає задачі з черги;
- обмежує рівень паралелізму й стабілізує навантаження.

2. **Fan-out / Fan-in**
- `fan-out`: розподіл однієї черги задач на багато виконавців;
- `fan-in`: злиття результатів із кількох джерел в один канал.

3. **Pipeline (конвеєр етапів)**
- дані проходять послідовні стадії обробки;
- кожна стадія може мати власну конкурентність і backpressure.

4. **Semaphore через buffered channel**
- лімітує кількість одночасних операцій;
- корисно для роботи з БД, файловими дескрипторами, зовнішніми API.

5. **Context cancellation**
- централізоване скасування всієї групи горутин;
- запобігає витокам при timeout, помилці або shutdown.

6. **Errgroup (fail-fast orchestration)**
- збирає помилки з групи задач;
- зручно поєднується з `context` для дострокової зупинки решти робіт.

7. **Single owner / Actor-like loop**
- одна горутина володіє mutable-станом;
- інші взаємодіють через повідомлення, зменшуючи lock contention.

8. **Publish/Subscribe (broadcast)**
- події розсилаються кільком споживачам;
- потребує уважного контролю буферів і життєвого циклу підписників.

#### Критичні принципи для всіх патернів:

1. Явне володіння ресурсом і правила закриття каналів.
2. Обмеження конкуренції (не «безмежні» горутини).
3. Обов'язковий шлях завершення (`context`, `done`, `WaitGroup`).
4. Спостережуваність: метрики, логування, профілювання.

#### Висновок:

Сила Go не в «самих горутинах», а в дисципліні патернів. Саме правильне
поєднання worker-pool, pipeline, fan-in/fan-out, cancellation і error-координації
дає системам масштабованість, передбачуваність і продакшн-надійність.

</details>

<details>
<summary>47. Коли використовувати `sync.Mutex`, а коли `sync.RWMutex`?</summary>

#### Go

`sync.Mutex` і `sync.RWMutex` розв'язують одну задачу — захист спільного стану,
але з різною моделлю конкуренції. Правильний вибір залежить від профілю доступу
до даних: співвідношення читань і записів, тривалості критичних секцій та рівня
контеншну.

#### `sync.Mutex` — коли обирати:

1. **Змішане або часте записування:**
   якщо write-операції не рідкісні, перевага `RWMutex` часто нівелюється.

2. **Короткі критичні секції:**
   простий lock/unlock зазвичай дає передбачувану й швидку поведінку.

3. **Базовий вибір за замовчуванням:**
   менше складності, менше шансів помилитися з моделлю блокувань.

4. **Коли важлива простота підтримки:**
   `Mutex` легше читати, відлагоджувати і профілювати.

#### `sync.RWMutex` — коли має сенс:

1. **Домінують читання, записи рідкісні:**
   багато concurrent reader-ів можуть працювати паралельно.

2. **Читання відносно тривалі:**
   паралельний read-доступ дає реальний виграш у throughput.

3. **Контеншн на читанні високий:**
   і є емпіричне підтвердження, що саме read-lock стає вузьким місцем.

#### Важливі застереження:

1. `RWMutex` не «автоматично швидший» — через складнішу внутрішню координацію
   він може бути повільнішим у реальних workload-ах.
2. За частих write-операцій читачі все одно блокуються.
3. Остаточний вибір треба робити за профілюванням (`pprof`, benchmarks), а не
   за інтуїцією.

#### Практичне правило:

1. Починайте з `sync.Mutex`.
2. Переходьте на `sync.RWMutex` лише коли є виміряний read-heavy сценарій і
   доведений performance gain.

#### Висновок:

`sync.Mutex` — надійний дефолт для більшості задач. `sync.RWMutex` — точковий
інструмент оптимізації для читачоорієнтованих навантажень, де виграш підтверджено
метриками.

</details>

<details>
<summary>48. Чому не можна копіювати об'єкти `sync.Mutex`?</summary>

#### Go

`sync.Mutex` містить внутрішній стан блокування. Після першого використання
копіювання такого об'єкта створює небезпечну ситуацію: з'являються два різні
екземпляри lock-стану, які програміст може помилково сприймати як один.

#### Чому це заборонено по суті:

1. **Mutex — не просто «дані», а синхронізаційний примітив зі станом.**
2. **Копія не ділить той самий lock-стан** із оригіналом.
3. Це руйнує гарантії взаємовиключення й може призвести до race, deadlock або
   panic у складних сценаріях.

#### Типові способи випадково скопіювати mutex:

1. Передати структуру з `sync.Mutex` за значенням у функцію.
2. Повернути таку структуру за значенням після ініціалізації/використання.
3. Зберігати/пересилати копії через канали чи колекції значень.

#### Правильна практика:

1. Структури з `sync.Mutex` використовувати через вказівники (`*T`), а не value-copy.
2. Не експортувати `Mutex` напряму в публічному API.
3. Якщо тип має lock, документувати, що він не копіюється після першого
   використання.
4. Використовувати `go vet` (copylocks) і лінтери для раннього виявлення.

#### Висновок:

Копіювати `sync.Mutex` не можна, бо це підриває саму модель синхронізації.
Пам'ятайте правило: lock-примітиви мають стабільну ідентичність і повинні
жити в одному екземплярі на захищений стан.

</details>

<details>
<summary>49. Чому читання і запис shared state без синхронізації — це data race, навіть якщо «логічно безпечно»?</summary>

#### Go

У термінах моделі пам'яті Go `data race` виникає тоді, коли дві або більше
горутини одночасно звертаються до однієї змінної, принаймні одна операція —
запис, і між цими доступами немає встановленого відношення
`happens-before` (тобто синхронізації).

#### Чому «логічно безпечно» не рятує:

1. **Логіка в голові розробника ≠ гарантія моделі пам'яті.**
   Без синхронізації порядок видимості записів між ядрами/потоками не визначено.

2. **Оптимізації компілятора й CPU можуть змінювати спостережуваний порядок**
   читань/записів у межах дозволеного memory model.

3. **Нестабільність під навантаженням:**
   код може «працювати» в локальному запуску, але ламатися в продакшні або в CI.

#### Які наслідки race:

1. Читання застарілих або частково оновлених значень.
2. Невідтворювані баги (heisenbugs), що важко дебажаться.
3. Порушення інваріантів бізнес-стану без явної паніки.

#### Що вважається правильною синхронізацією:

1. `sync.Mutex` / `sync.RWMutex`
2. Атоміки (`sync/atomic`) для простих low-level сценаріїв
3. Канали як механізм передачі володіння/сигналізації
4. `WaitGroup`, `Cond`, `Once`, `context` — у своїх ролях координації

#### Висновок:

Без синхронізації shared read/write у Go — це race за визначенням, незалежно від
суб'єктивної «логічної безпеки». Єдиний надійний шлях — явно формувати
`happens-before` відношення через коректні примітиви конкурентності.

</details>

<details>
<summary>50. Що таке Race Condition і як працює детектор `-race`? Що він може і чого не може виявити?</summary>

#### Go

`Race Condition` — це загальний клас конкурентних дефектів, коли результат
програми залежить від непередбачуваного порядку подій між потоками виконання.
`Data race` — окремий випадок race condition, де йдеться саме про небезпечний
одночасний доступ до однієї пам'яті без синхронізації.

#### Як працює `-race`:

1. Під час `go test -race` / `go run -race` код інструментується.
2. Runtime відстежує читання/записи пам'яті між горутинами.
3. Якщо виявлено доступи без `happens-before` (і є запис) — репортується
   `data race` із стек-трейсами.

#### Що `-race` добре виявляє:

1. Класичні read/write та write/write гонки на спільних змінних.
2. Пропущені lock/unlock у конкурентних ділянках.
3. Частину помилок координації в тестових сценаріях із реальною конкуренцією.

#### Чого `-race` не гарантує:

1. **Не знаходить усі race condition як логічні баги:**
   наприклад, неправильний протокол взаємодії без прямого data race.

2. **Не бачить невиконаний код:**
   якщо тести не покривають конкурентний шлях, race може лишитися непоміченим.

3. **Не доводить відсутність багів:**
   «чистий» прогін означає лише, що під час цього запуску інструмент не зафіксував
   порушень.

4. **Має накладні витрати:**
   уповільнення й зростання споживання пам'яті в режимі інструментації.

#### Практичний висновок:

`-race` — обов'язковий інструмент гігієни конкурентного коду, але не абсолютний
оракул коректності. Його сила розкривається в комбінації з якісними тестами,
інваріантами дизайну й дисципліною синхронізації.

</details>

<details>
<summary>51. У чому переваги atomic-операцій порівняно з mutex для простих конкурентних операцій?</summary>

#### Go

`atomic`-операції в Go доречні для дуже простих конкурентних сценаріїв, де
потрібно безпечно виконати елементарну дію над одним значенням
(інкремент, читання прапорця, CAS). У таких випадках вони можуть бути
легшими за `mutex`.

#### Переваги atomic-підходу:

1. **Менші накладні витрати для простих дій:**
   немає явних `Lock/Unlock` навколо короткої операції.

2. **Висока ефективність у hot-path лічильниках і прапорцях:**
   наприклад, метрики, стани stop/start, lightweight coordination.

3. **Відсутність блокування в класичному сенсі:**
   потокам не потрібно чекати lock-власника для атомарного читання/запису.

4. **Чіткі memory-order гарантії через API `sync/atomic`:**
   забезпечується коректна видимість між горутинами для конкретної змінної.

#### Коли atomic кращий за mutex:

1. Операція стосується **однієї** змінної або дуже локального стану.
2. Логіка — проста й добре формалізована (`Load`, `Store`, `Add`, `CompareAndSwap`).
3. Потрібна мінімальна latency у високочастотному шляху.

#### Коли краще mutex:

1. Потрібно захистити **інваріант між кількома полями**.
2. Операція включає кілька кроків із доменною логікою.
3. Важливіша читабельність і підтримуваність, ніж мікрооптимізація.

#### Важливе застереження:

Atomic — не універсальна заміна `mutex`. Надмірне використання атоміків
ускладнює код і підвищує ризик тонких багів у memory model.

#### Висновок:

Перевага atomic-операцій — швидка, низьковитратна синхронізація для простих
випадків. Для складного спільного стану й бізнес-інваріантів надійнішим
інструментом зазвичай лишається `mutex`.

</details>

<details>
<summary>52. Як працює `sync.WaitGroup` і що буде при від'ємному лічильнику? Чому не можна викликати `wg.Done()` до `wg.Add()`?</summary>

#### Go

`sync.WaitGroup` — це лічильник активних конкурентних задач. Його призначення:
дозволити одній горутині (`Wait`) дочекатися, доки інші завершать роботу.

#### Як він працює:

1. `wg.Add(n)` збільшує лічильник на `n` (додаємо кількість задач).
2. Кожна завершена задача викликає `wg.Done()` (еквівалент `Add(-1)`).
3. `wg.Wait()` блокується, доки лічильник не стане нулем.

#### Що буде при від'ємному лічильнику:

1. Це логічна помилка координації.
2. Runtime викликає panic (типово: `sync: negative WaitGroup counter`).
3. Така ситуація означає, що `Done()` викликали більше разів, ніж було `Add()`.

#### Чому не можна робити `Done()` до `Add()`:

1. Порушується контракт життєвого циклу задач.
2. `Wait()` може завершитися передчасно, бо на момент очікування лічильник ще
   не відображає реальну кількість робіт.
3. У гіршому випадку отримаємо від'ємний лічильник і panic.

#### Правильна дисципліна:

1. Викликати `Add(1)` **до** запуску горутини.
2. Усередині горутини ставити `defer wg.Done()` одразу на вході.
3. Викликати `Wait()` лише після реєстрації всіх задач.

#### Висновок:

`WaitGroup` надійний лише за строгої послідовності `Add -> go -> Done -> Wait`.
Від'ємний лічильник і `Done()` до `Add()` — це сигнал порушеної моделі
синхронізації, який неминуче призводить до нестабільної поведінки або panic.

#### Приклад:

```go
var wg sync.WaitGroup
wg.Add(1)

go func() {
	defer wg.Done()
	work()
}()

wg.Wait()
```

</details>

<details>
<summary>53. У чому різниця між `sync.WaitGroup` і `errgroup.Group`? Коли використовувати кожен?</summary>

#### Go

`sync.WaitGroup` і `errgroup.Group` обидва координують завершення горутин, але
рівень абстракції в них різний: `WaitGroup` лише чекає, а `errgroup` додатково
працює з помилками та скасуванням через `context`.

#### `sync.WaitGroup`:

1. Відповідає лише за очікування завершення задач.
2. Не збирає помилки «з коробки».
3. Не скасовує інші горутини автоматично.
4. Потребує ручної інфраструктури:
- каналу помилок;
- координації `context`;
- логіки fail-fast.

#### `errgroup.Group`:

1. Дозволяє запускати горутини через `Go(func() error)`.
2. Повертає першу отриману помилку у `Wait()`.
3. У парі з `errgroup.WithContext` автоматично скасовує контекст при помилці.
4. Зменшує бойлерплейт для типового патерну «паралельні задачі + stop on error».

#### Коли обирати `WaitGroup`:

1. Потрібно лише дочекатися завершення без error-агрегації.
2. Політика обробки помилок нестандартна й повністю кастомна.
3. Низькорівневий контроль важливіший за зручність API.

#### Коли обирати `errgroup`:

1. Потрібна чітка модель «помилка в одній задачі → зупинка решти».
2. Потрібно швидко й чисто реалізувати конкурентний orchestration.
3. Важлива читабельність і короткий, підтримуваний код.

#### Висновок:

`WaitGroup` — примітив синхронізації «лише чекати». `errgroup` — вищий рівень:
«чекати + повернути помилку + скасувати решту через context». Для більшості
продакшн-сценаріїв із помилками та fail-fast семантикою практичнішим є
`errgroup`.

</details>

<details>
<summary>54. Опишіть призначення та реалізацію `sync.Once` — як він гарантує одноразову ініціалізацію?</summary>

#### Go

`sync.Once` призначений для гарантованого одноразового виконання функції в
умовах конкурентного доступу. Незалежно від кількості горутин, що одночасно
викликають `once.Do(f)`, тіло `f` має бути виконане лише один раз.

#### Для чого використовується:

1. Лінива ініціалізація singleton-ресурсів.
2. Одноразове підвантаження конфігурації/кешу.
3. Безпечний запуск важкої ініціалізації без дублювання роботи.

#### Як `sync.Once` гарантує одноразовість:

1. Перевіряє внутрішній прапорець стану «виконано/не виконано».
2. Якщо ініціалізація ще не зроблена — синхронізовано блокує конкурентів.
3. Рівно одна горутина виконує `f`.
4. Після успіху позначає стан як «done», і подальші `Do` повертаються без
   повторного запуску `f`.

#### Важливі властивості:

1. Гарантується коректна видимість ініціалізованих даних для інших горутин
   (memory-safety через внутрішню синхронізацію).
2. Інші горутини, що прийшли під час виконання `f`, дочекаються завершення.
3. `Once` не призначений для «перезапуску» — це одноразовий життєвий цикл.

#### Нюанси й застереження:

1. Якщо `f` панікує, поведінка потребує уважного трактування в дизайні:
   `Once` не є механізмом ретраю.
2. Не варто ховати в `Do` надто складну бізнес-логіку; краще тримати там саме
   ініціалізацію ресурсу.
3. Для задач із reset/reload потрібні інші патерни (atomic pointer, mutex,
   versioned state тощо).

#### Висновок:

`sync.Once` — це дисциплінований примітив одноразової ініціалізації:
конкурентно-безпечний, передбачуваний і дуже корисний там, де повторний запуск
ініціалізації є або зайвим, або небезпечним.

</details>

<details>
<summary>55. Що таке `sync.Cond` і коли він переважає канал?</summary>

#### Go

`sync.Cond` — це примітив умовної синхронізації: він дозволяє горутинам чекати,
доки певний стан (умова) стане істинним, і бути пробудженими сигналом від іншої
горутини.

#### Базова модель `sync.Cond`:

1. `Cond` працює поверх `Locker` (зазвичай `*sync.Mutex`).
2. Горутина в циклі перевіряє умову під lock.
3. Якщо умова хибна — викликає `Wait()`.
4. Інша горутина після зміни стану викликає `Signal()` або `Broadcast()`.

#### Ключові методи:

1. **`Wait()`** — атомарно відпускає lock, засинає, після пробудження знову
   захоплює lock.
2. **`Signal()`** — будить одну горутину, що чекає.
3. **`Broadcast()`** — будить усіх очікувачів.

#### Коли `sync.Cond` переважає канал:

1. **Складна умова на спільному стані, а не передача повідомлення:**
   коли важливо чекати саме «predicate over state», а не отримати payload.

2. **Багато waiter-ів на одному lock-захищеному ресурсі:**
   `Cond` природніше виражає coordination around shared state.

3. **Потрібен точний контроль пробудження:**
   `Signal/Broadcast` інколи краще відповідають вимогам, ніж канальна семантика.

4. **Високочастотні сценарії з мінімальним алокаційним шумом:**
   у певних low-level випадках `Cond` дає ефективнішу модель, ніж побудова
   додаткових каналних протоколів.

#### Коли краще канал:

1. Коли задача — передати подію/дані між незалежними акторами.
2. Коли важлива проста pipeline-модель і читабельний message flow.
3. Коли не хочеться керувати спільним mutable state під lock.

#### Висновок:

`sync.Cond` — інструмент «чекаємо на зміну умови під mutex», тоді як канал —
інструмент «передаємо повідомлення». `Cond` переважає там, де центр логіки —
саме стан і його інваріанти, а не транспорт даних.

</details>

<details>
<summary>56. Як влаштований `sync.Map`, коли він дає кращу продуктивність порівняно з map + mutex і де він використовується в стандартній бібліотеці?</summary>

#### Go

`sync.Map` — це спеціалізована конкурентна мапа з пакета `sync`, оптимізована
передусім під read-heavy навантаження та сценарії, де ключі часто читаються й
рідко змінюються.

#### Як `sync.Map` влаштований концептуально:

1. Має двошарову модель доступу:
- **read-частина** для швидких, переважно lock-free читань;
- **dirty-частина** для оновлень і нових записів під синхронізацією.

2. Читання з «гарячої» read-зони часто обходяться без загального mutex, що
   зменшує contention.

3. Записи/промоції між шарами мають складнішу внутрішню логіку, але вона
   спрямована на те, щоб не штрафувати масові читання.

#### Коли `sync.Map` може бути швидшим за `map + mutex`:

1. **Багато читань, мало записів** (класичний read-mostly workload).
2. **Ключі переважно стабільні**, без агресивного churn.
3. **Високий конкурентний read-доступ** з багатьох горутин.

#### Коли частіше краще `map + mutex`:

1. Записів багато або вони домінують.
2. Потрібні складні інваріанти над кількома ключами.
3. Важливіша типобезпека (бо `sync.Map` працює через `any`).
4. Потрібна простіша й очевидніша логіка для підтримки командою.

#### Де застосовується в стандартній бібліотеці:

`sync.Map` використовують у внутрішніх кешах і таблицях, де характер доступу
наближений до read-heavy (зокрема в частинах рантайму/стандартних пакетів для
кешування метаданих та допоміжних структур). Ключова ідея всюди однакова:
мінімізувати блокування на масових читаннях.

#### Висновок:

`sync.Map` — не «краща map загалом», а точковий інструмент для певного профілю
навантаження. Якщо у вас read-mostly сценарій із високою конкуренцією, він може
дати виграш; в інших випадках простий `map + mutex` часто прозоріший і
ефективніший.

</details>

<details>
<summary>57. Що таке конкурентні тести в Go і навіщо їх використовують?</summary>

#### Go

Конкурентні тести в Go — це тести, які перевіряють поведінку коду в умовах
паралельного виконання горутин, спільного доступу до стану та змагання за
ресурси. Їхня мета — виявити дефекти, що не проявляються в лінійному сценарії.

#### Що саме перевіряють такі тести:

1. Коректність синхронізації (`mutex`, `channel`, `atomic`, `WaitGroup`).
2. Відсутність data race у shared state.
3. Стійкість до deadlock/live-lock сценаріїв.
4. Правильність завершення горутин (без витоків).
5. Дотримання інваріантів під конкурентним навантаженням.

#### Навіщо вони потрібні:

1. **Раннє виявлення конкурентних багів:**
   багато з них проявляються лише під тиском паралелізму.

2. **Зниження flaky-поведінки в продакшні:**
   тестами фіксують сценарії, де порядок подій недетермінований.

3. **Підтвердження архітектурних гарантій:**
   наприклад, що система не втрачає події і не порушує консистентність стану.

4. **Безпечніший рефакторинг:**
   конкурентні інваріанти залишаються захищеними регресійним набором.

#### Інструменти й практики в Go:

1. `go test -race` як обов'язковий рівень перевірки.
2. Паралельні сценарії через горутини, `t.Run`, `t.Parallel`.
3. Явні таймаути/`context` для запобігання зависанню тестів.
4. Стрес-прогони й багаторазові запуски для підвищення шансів відтворення
   недетермінованих помилок.

#### Висновок:

Конкурентні тести — це не «додаткова розкіш», а необхідний елемент якості для
Go-сервісів. Вони перевіряють не лише функціональність, а й коректність
взаємодії горутин у реальних умовах паралелізму.

</details>

<details>
<summary>58. Навіщо в Go використовується `context.Context` і як він передається через дерево викликів функцій?</summary>

#### Go

`context.Context` у Go — це стандартний механізм керування життєвим циклом
запиту/операції: скасування, дедлайни, таймаути та метадані запиту. Він
дозволяє всім гілкам виконання бачити єдиний сигнал «зупинитися».

#### Для чого потрібен `Context`:

1. **Cancellation:** зупинити роботу, що вже не потрібна (клієнт відключився,
   сталася помилка в сусідній гілці, сервіс завершується).

2. **Deadline/timeout:** обмежити час виконання операцій (HTTP, БД, зовнішні
   API), щоб не зависати нескінченно.

3. **Request-scoped values:** передавати службові дані запиту (trace-id,
   auth-токен, tenant-id) між шарами.

#### Як він передається через дерево викликів:

1. `ctx` передають **першим параметром** у функцію, яка може блокуватися або
   робити I/O.

2. Кожен дочірній виклик отримує той самий `ctx` або похідний:
- `context.WithCancel`
- `context.WithTimeout`
- `context.WithDeadline`
- `context.WithValue`

3. Дочірні контексти формують дерево:
- скасування батьківського контексту скасовує всі нащадки;
- дедлайни успадковуються (або звужуються).

#### Практичні правила:

1. Не зберігати `Context` у структурі як поле довгого життя.
2. Не передавати `nil`-контекст (використовувати `context.Background()` або
   `context.TODO()`).
3. Не використовувати `WithValue` для бізнес-параметрів, які мають бути явними
   аргументами функції.

#### Висновок:

`context.Context` — «нервова система» запиту в Go. Він поширює контроль часу й
скасування по всьому дереву викликів, роблячи конкурентний код керованим,
економним і передбачуваним у продакшн-середовищі.

#### Приклад:

```go
func handler(w http.ResponseWriter, r *http.Request) {
	ctx := r.Context()
	if err := service.Do(ctx); err != nil {
		http.Error(w, err.Error(), 500)
	}
}

func (s *Service) Do(ctx context.Context) error {
	ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()
	return s.repo.Call(ctx)
}
```

</details>

<details>
<summary>59. Чи є `context.Context` незмінним (immutable) і що це означає на практиці?</summary>

#### Go

Так, `context.Context` концептуально є незмінним (immutable): після створення
наявний контекст не «редагують», а будують новий похідний контекст поверх
батьківського.

#### Що означає immutable у випадку `Context`:

1. Виклики `WithCancel`, `WithTimeout`, `WithDeadline`, `WithValue` не змінюють
   старий `ctx`.
2. Вони повертають **новий** контекст-нащадок.
3. Батьківський контекст лишається таким, яким був до цього.

#### Практичні наслідки:

1. **Безпечне поширення між горутинами:**
   один і той самий `ctx` можна передавати далі без ризику «прихованого
   перезапису» параметрів.

2. **Прозорий життєвий цикл:**
   дерево контекстів чітко відображає, хто від кого успадкував cancel/deadline.

3. **Прогнозована поведінка API:**
   функція, що отримала `ctx`, не може нишком «підкрутити» його для інших
   викликів; вона може лише створити локальний нащадок.

4. **Краща тестованість і дебаг:**
   легше простежити, де саме з'явився timeout/cancel/value, бо це окремі
   похідні вузли, а не мутації одного об'єкта.

#### Важливе уточнення:

Імм'ютабельність не означає, що всередині немає динаміки: cancel-сигнал і
deadline-стан можуть змінюватися в часі. Але це зміна **стану виконання** в межах
моделі контексту, а не мутація API-контракту переданого об'єкта «на місці».

#### Висновок:

`context.Context` у Go — функціонально-ланцюгова модель: не змінюємо існуюче, а
створюємо похідне. Це дає чисту композицію, безпечну конкурентність і
передбачуване керування життєвим циклом запитів.

</details>

<details>
<summary>60. Як використання `context.WithCancel` допомагає уникнути витоків горутин?</summary>

#### Go

`context.WithCancel` дає керований сигнал завершення для всіх горутин, що
працюють у межах одного дерева контексту. Саме це є ключем до запобігання
goroutine leak — ситуації, коли допоміжні горутини лишаються «вічно живими»
після втрати актуальності роботи.

#### Як виникає витік горутин:

1. Горутина чекає на канал/мережу/таймер без умови зупинки.
2. Запит уже завершився або став непотрібним, але worker про це не дізнався.
3. Такі «осиротілі» горутини накопичуються й споживають ресурси.

#### Роль `WithCancel`:

1. Створюється дочірній контекст: `ctx, cancel := context.WithCancel(parent)`.
2. У всіх робочих горутинах є `select` із гілкою `case <-ctx.Done():`.
3. Коли викликають `cancel()`, усі залежні горутини отримують сигнал зупинки.
4. Горутини завершуються контрольовано, звільняючи ресурси.

#### Практичні правила безпеки:

1. Завжди викликайте `cancel()` (часто через `defer cancel()`), навіть при
   успішному завершенні.
2. У кожному довгоживучому циклі/блокуючій операції перевіряйте `ctx.Done()`.
3. Пропускайте `ctx` через усі I/O-виклики, які підтримують cancellation.
4. Поєднуйте з `WaitGroup`/`errgroup`, щоб дочекатися фактичного завершення.

#### Що це дає системі:

1. Відсутність «завислих» фонових worker-ів.
2. Краща утилізація CPU/пам'яті під навантаженням.
3. Передбачуваний shutdown і стабільніша поведінка сервісу.

#### Висновок:

`context.WithCancel` — базовий антивитоковий механізм у Go-конкурентності:
один явний сигнал зупинки, який узгоджено завершує всі пов'язані горутини й
зберігає систему від ресурсного розростання.

</details>

<details>
<summary>61. Чому в Go для `context.WithValue` використовують нестандартні типи ключів (наприклад, `struct{}`) і як це запобігає колізіям?</summary>

#### Go

У `context.WithValue` ключ має бути порівнюваним, але найважливіше — він має
бути **унікальним у просторі вашого застосунку та залежностей**. Саме тому
рекомендовано використовувати власні (нестандартні) типи ключів, а не
загальновживані `string`.

#### Чому `string`-ключі небезпечні:

1. Різні пакети можуть випадково використати однаковий рядок (`"userID"`,
   `"request_id"` тощо).
2. Значення в контексті перезапишеться або «затіниться» іншим пакетом.
3. Отримаємо тихі, важковідтворювані помилки маршрутизації/автентифікації/логування.

#### Як нестандартний тип запобігає колізіям:

1. Створюється приватний тип ключа в пакеті, наприклад:
   `type ctxKey struct{}` або `type ctxKey int`.
2. Зовнішній код не може випадково використати той самий тип і значення ключа.
3. Таким чином namespace ключів стає ізольованим на рівні типової системи.

#### Чому часто беруть саме `struct{}`:

1. Легковаговий маркерний тип без payload.
2. Підкреслює, що важлива ідентичність ключа, а не його «дані».
3. Добре відповідає ідіомі «пакет-локальний унікальний ключ».

#### Практичне правило:

1. Оголошуйте ключі як неекспортовані змінні пакета.
2. Не використовуйте «голі» рядки як ключі для `WithValue`.
3. Зберігайте в `Context` лише request-scoped службові дані, а не бізнес-параметри.

#### Висновок:

Нестандартні типи ключів у `context.WithValue` — це механізм типобезпечного
іменного простору. Вони надійно знижують ризик колізій між пакетами й роблять
контекстні значення передбачуваними в великих кодових базах.

#### Приклад:

```go
type requestIDKey struct{}

func withRequestID(ctx context.Context, id string) context.Context {
	return context.WithValue(ctx, requestIDKey{}, id)
}

func requestID(ctx context.Context) (string, bool) {
	v, ok := ctx.Value(requestIDKey{}).(string)
	return v, ok
}
```

</details>

<details>
<summary>62. У чому різниця між `context.Value` та передачею параметрів через аргументи функції?</summary>

#### Go

`context.Value` і звичайні аргументи функції мають різне призначення. У
грамотному Go-дизайні вони не взаємозамінні: аргументи передають бізнес-дані,
а `context.Value` — службовий request-scoped метаконтекст.

#### Передача через аргументи:

1. **Явний контракт API:**
   усі потрібні дані видно в сигнатурі.

2. **Типобезпечність і читабельність:**
   компілятор допомагає контролювати коректність.

3. **Найкращий вибір для доменної логіки:**
   параметри предметної області мають бути передані прямо.

#### `context.Value`:

1. **Неявний канал службових даних:**
   trace-id, request-id, auth-claims, tenant, кореляційні метадані.

2. **Поширюється через шари без роздування сигнатур:**
   корисно для middleware, логування, observability.

3. **Менша прозорість:**
   залежність від значення неочевидна з підпису функції.

#### Чому не варто підміняти аргументи `context.Value`:

1. Падає ясність API (виникають «приховані» входи).
2. Зростає ризик runtime-помилок через assertion із `any`.
3. Ускладнюються тести та рефакторинг.

#### Практичне правило:

1. У `Context` — лише те, що належить життєвому циклу запиту й потрібне
   інфраструктурним шарам.
2. У параметрах функції — усе, що є суттю бізнес-операції.

#### Висновок:

Аргументи формують явний доменний контракт; `context.Value` несе службову
метаінформацію запиту. Змішування цих ролей погіршує архітектуру, тому в
професійному Go-коді межу між ними тримають чітко.

</details>

<details>
<summary>63. Як працює алокація на Stack vs Heap у Go?</summary>

#### Go

У Go розміщення даних у Stack або Heap визначає компілятор через escape analysis.
Розробник не обирає це вручну напряму, але може писати код так, щоб зменшувати
непотрібні heap-алокації.

#### Stack-алокація:

1. Дані живуть у межах виклику функції (або керовано ростучого стеку горутини).
2. Виділення та звільнення дуже дешеві.
3. Не створює прямого навантаження на GC.

#### Heap-алокація:

1. Дані потрібні поза межами поточного стек-фрейму.
2. Пам'ять керується garbage collector-ом.
3. Дає вищі накладні витрати (алокація + подальше збирання сміття).

#### Що вирішує, куди потрапить значення:

1. **Escape analysis компілятора:**
   якщо значення «втікає» за межі функції (повертається pointer, зберігається у
   довгоживучій структурі, захоплюється closure тощо), воно потрапляє в Heap.

2. **Контекст використання:**
   навіть локальна змінна може опинитися в Heap, якщо її життєвий цикл довший за
   поточний фрейм.

#### Чому це важливо:

1. Більше Heap-алокацій = більше роботи для GC.
2. У hot-path це впливає на latency і throughput.
3. Оптимізація алокацій часто дає відчутний приріст продуктивності сервісу.

#### Практичний висновок:

У Go ключ не в «ручному керуванні пам'яттю», а в розумінні escape-поведінки.
Ясний дизайн даних і мінімізація зайвих втеч у Heap допомагають писати швидкий і
стабільний продакшн-код.

</details>

<details>
<summary>64. Як мінімізувати алокації в купі за допомогою `sync.Pool`?</summary>

#### Go

`sync.Pool` — це механізм повторного використання тимчасових об'єктів, який
дозволяє зменшити частоту heap-алокацій у гарячих ділянках коду. Ідея проста:
не створювати короткоживучі об'єкти щоразу наново, а брати їх із пулу й
повертати назад після використання.

#### Базова схема:

1. Створити пул із `New`, що ініціалізує об'єкт за потреби.
2. На вході операції: `obj := pool.Get()`.
3. Перед використанням привести об'єкт до валідного стану.
4. Після завершення: очистити поля і `pool.Put(obj)`.

#### Чому це зменшує алокації:

1. Частина запитів отримує вже виділені об'єкти.
2. Менше нових алокацій у Heap.
3. Менше тиску на GC при високій частоті коротких операцій.

#### Де `sync.Pool` особливо доречний:

1. Буфери (`[]byte`, `bytes.Buffer`) у серіалізації/мережевих обробниках.
2. Тимчасові допоміжні структури в parse/encode/decode-шляхах.
3. Високонавантажені HTTP/RPC сервіси з повторюваними короткими операціями.

#### Важливі застереження:

1. `sync.Pool` — кеш, а не довгострокове сховище; елементи можуть бути
   очищені GC.
2. Об'єкт перед `Put` треба приводити до чистого стану, інакше можливий витік
   даних між запитами.
3. Пул не панацея: на холодних шляхах ускладнення коду може не окупитися.
4. Оптимізацію слід підтверджувати профілюванням, а не інтуїцією.

#### Висновок:

`sync.Pool` ефективний для повторного використання короткоживучих об'єктів у
гарячих шляхах, де критичні алокації й GC-пауза. Його сила — у зменшенні
алокаційної турбулентності, але застосовувати його треба вибірково й
профільовано.

</details>

<details>
<summary>65. Що означають змінні середовища `GOGC` і `GOMEMLIMIT` і як вони впливають на роботу garbage collector?</summary>

#### Go

`GOGC` і `GOMEMLIMIT` — ключові параметри керування поведінкою GC у Go. Вони
дозволяють балансувати між споживанням пам'яті, частотою збирання сміття та
продуктивністю сервісу.

#### `GOGC`:

1. Визначає цільовий темп росту heap перед наступним циклом GC (у відсотках).
2. Типове значення — `100` (дозволити heap приблизно подвоїтися відносно
   «живих» даних після попереднього GC).
3. Більше `GOGC`:
- рідші цикли GC;
- більше споживання пам'яті;
- потенційно менші GC-накладні витрати на CPU.
4. Менше `GOGC`:
- частіший GC;
- менший heap;
- вищі накладні витрати на збирач.

#### `GOMEMLIMIT`:

1. Задає м'яку верхню межу пам'яті, в межах якої runtime намагається тримати
   процес.
2. Коли пам'ять наближається до цієї межі, GC працює агресивніше, навіть якщо
   `GOGC` дозволяв би рідший збір.
3. Особливо корисно в контейнерах/оркестраторах із жорсткими memory-лімітами.

#### Як вони працюють разом:

1. `GOGC` задає загальну «жадібність» росту heap.
2. `GOMEMLIMIT` виступає запобіжником, що обмежує надмірний ріст пам'яті.
3. У продакшні саме комбінація обох параметрів дає найкращий контроль latency
   та OOM-ризиків.

#### Практичний підхід:

1. Починати з дефолтів.
2. Міряти `heap`, GC pause, CPU, tail-latency під реальним навантаженням.
3. Тюнити параметри поступово, фіксуючи вплив на SLA.
4. Для контейнерів обов'язково узгоджувати `GOMEMLIMIT` із платформним
   memory-limit.

#### Висновок:

`GOGC` керує частотою GC через ціль росту heap, а `GOMEMLIMIT` обмежує пам'ять
зверху. Разом вони формують практичний інструмент тонкого налаштування
runtime-поведінки Go-сервісів.

</details>

<details>
<summary>66. Що таке `runtime.SetFinalizer` і чи використовується він у стандартній бібліотеці?</summary>

#### Go

`runtime.SetFinalizer` — це механізм прив'язки функції-фіналізатора до об'єкта,
яка може бути викликана GC перед остаточним звільненням об'єкта. Важливо:
фіналізатор не дає строгих гарантій часу виконання і не є надійною заміною
явного `Close`/`Dispose`.

#### Що робить `SetFinalizer`:

1. Реєструє callback для конкретного heap-об'єкта.
2. Коли об'єкт стає недосяжним, runtime **може** запустити фіналізатор.
3. Після цього об'єкт буде зібрано в одному з наступних циклів GC.

#### Ключові обмеження:

1. **Немає гарантії «коли саме» виконається фіналізатор.**
2. **Немає гарантії, що він виконається до завершення процесу.**
3. Фіналізатори ускладнюють reasoning про життєвий цикл і можуть створювати
   приховані витрати/затримки.

#### Практичне правило:

1. Для ресурсів (файли, сокети, дескриптори, зовнішні підключення) завжди
   використовуйте явне закриття (`defer obj.Close()`).
2. Фіналізатор допустимий лише як «страхувальна сітка» від помилок використання,
   а не основний шлях керування ресурсом.

#### Чи використовується у стандартній бібліотеці:

Так, використовується точково в окремих низькорівневих місцях як допоміжний
механізм безпеки/діагностики, але не як базова модель керування ресурсами.
Загальна філософія стандартної бібліотеки — явний життєвий цикл і явне закриття.

#### Висновок:

`runtime.SetFinalizer` — спеціалізований інструмент із м'якими гарантіями.
У продакшн-Go його застосовують обережно й рідко; основою надійного коду
залишається явне керування ресурсами.

</details>

<details>
<summary>67. Як знайти витік пам'яті за допомогою `pprof`?</summary>

#### Go

Пошук витоку пам'яті в Go через `pprof` ґрунтується на порівнянні профілів heap у
часі: якщо «живі» об'єкти стабільно ростуть без повернення до базового рівня,
маємо ознаку leak або неконтрольованого утримання посилань.

#### Базова стратегія діагностики:

1. Увімкнути профілювання (`net/http/pprof`) у сервісі.
2. Зняти кілька heap-профілів:
- на старті;
- під робочим навантаженням;
- після періоду «затишшя».
3. Порівняти профілі (`go tool pprof`, diff-режим), щоб знайти типи/стеки, які
   продовжують рости.

#### На що дивитися в `pprof`:

1. **`inuse_space` / `inuse_objects`** — що реально лишається в пам'яті.
2. **Топ алокаторів** і їхні call stacks.
3. **Граф викликів (`web`)** — де саме утримуються довгоживучі об'єкти.
4. Динаміку після кількох GC-циклів: справжній leak не «здувається».

#### Типові джерела витоків:

1. Глобальні map/cache без eviction-політики.
2. Неочищені буфери/черги/канали.
3. Горутини, що не завершуються і тримають посилання на великі структури.
4. Невдало спроєктовані пули або «вічні» колекції метрик/лейблів.

#### Практичні прийоми:

1. Запускати профілі під репрезентативним workload.
2. Додавати порівняльні знімки до/після фіксу.
3. Паралельно дивитися goroutine-профіль (`goroutine`) — витоки горутин часто
   корелюють із витоками пам'яті.

#### Висновок:

`pprof` дозволяє знайти витік пам'яті не «на око», а доказово: через зростання
`inuse`-метрик і конкретні стеки утримання. Ключ до успіху — часове порівняння
профілів у стабільному, відтворюваному навантаженні.

</details>

<details>
<summary>68. Як знайти hot paths і виміряти throughput?</summary>

#### Go

`Hot paths` — це ділянки коду, де програма проводить найбільше часу або ресурсів.
Щоб знайти їх коректно, потрібна не інтуїція, а профілювання під реальним або
наближеним до реального навантаження.

#### Як знайти hot paths:

1. **CPU-профілювання (`pprof`):**
   показує, де процесорний час витрачається найбільше.

2. **Heap/alloc-профілі:**
   допомагають знайти «гарячі» алокаційні шляхи, що часто стають причиною
   непрямої деградації через GC.

3. **Trace (`go tool trace`):**
   дає картину планувальника, блокувань, затримок між горутинами та I/O.

4. **Flame graph / top / call graph:**
   візуалізують, які функції формують основний cost.

#### Як виміряти throughput:

1. Визначити бізнес-метрику пропускної здатності:
- req/s, msg/s, jobs/s, rows/s тощо.

2. Провести контрольоване навантажувальне тестування:
- фіксовані вхідні дані;
- відомий профіль конкурентності;
- стабільне середовище запуску.

3. Знімати метрики одночасно:
- throughput;
- latency (p50/p95/p99);
- CPU, memory, GC, lock contention.

4. Порівнювати «до/після» змін за однакових умов (і бажано з кількома прогонами).

#### Практичні принципи:

1. Оптимізувати лише те, що підтверджено профайлером.
2. Не покращувати throughput ціною неконтрольованого росту tail-latency.
3. Після оптимізації повторно профілювати, аби переконатися, що вузьке місце
   справді зникло, а не змістилося.

#### Висновок:

Пошук hot paths і вимірювання throughput — це єдиний цикл: **профілювання →
гіпотеза → зміна → повторне вимірювання**. У Go цей підхід добре підтримується
стандартним tooling і дає інженерно надійні результати.

</details>

<details>
<summary>69. Як оптимізувати роботу з рядками за допомогою `strings.Builder`? Чому не можна конкатенувати в циклі?</summary>

#### Go

У Go рядки є immutable. Це означає, що кожна операція конкатенації створює новий
рядок. Тому повторне `s += part` у циклі часто породжує лавину алокацій і
копіювань.

#### Чому конкатенація в циклі неефективна:

1. На кожній ітерації створюється новий рядок.
2. Старий вміст копіюється знову і знову.
3. Загальна вартість може рости до квадратичної для великих обсягів.
4. Зростає тиск на GC через короткоживучі проміжні об'єкти.

#### Як допомагає `strings.Builder`:

1. `Builder` накопичує дані у внутрішньому буфері.
2. Записи (`WriteString`, `WriteByte`, `WriteRune`) мінімізують зайві копії.
3. Фінальний рядок формується один раз через `String()`.
4. За потреби можна викликати `Grow(n)`, щоб попередньо зарезервувати місткість
   і зменшити reallocation.

#### Практичні переваги:

1. Менше алокацій.
2. Кращий throughput у гарячих шляхах форматування/генерації тексту.
3. Стабільніша latency-поведінка під навантаженням.

#### Коли особливо варто застосовувати:

1. Генерація великих payload-ів (JSON/SQL/HTML/лог-рядки).
2. Конструювання рядків у циклах.
3. Будь-які операції, де рядок формується з багатьох фрагментів.

#### Висновок:

Конкатенація в циклі дорога через повторні алокації й копіювання immutable-рядків.
`strings.Builder` — ідіоматичний та ефективний інструмент для побудови рядків у
Go, особливо в продуктивно чутливих місцях.

#### Приклад:

```go
var b strings.Builder
b.Grow(1024)

for _, part := range parts {
	b.WriteString(part)
}

result := b.String()
```

</details>

<details>
<summary>70. Як оптимізувати серіалізацію?</summary>

#### Go

Оптимізація серіалізації в Go — це передусім робота з алокаціями, форматом
даних, повторним використанням буферів і зменшенням рефлексії в гарячих шляхах.
Найкращий результат дає лише профільований підхід, а не «сліпі» мікрооптимізації.

#### Практичні стратегії оптимізації:

1. **Вибір формату під задачу:**
- JSON зручний і універсальний, але важчий за CPU;
- Protobuf/MessagePack часто швидші та компактніші для міжсервісного трафіку.

2. **Зменшення алокацій:**
- повторно використовувати `bytes.Buffer` / `[]byte` через `sync.Pool`;
- уникати зайвих проміжних об'єктів під час marshal/unmarshal.

3. **Потокова серіалізація:**
- використовувати `Encoder/Decoder` для великих потоків, щоб не тримати весь
  payload у пам'яті одночасно.

4. **Оптимізація структури даних:**
- прибирати непотрібні поля;
- використовувати коректні теги (`omitempty`, короткі ключі за потреби);
- уникати надмірно вкладених структур, якщо це не потрібно бізнес-логіці.

5. **Уникнення зайвої рефлексії в hot-path:**
- у критичних місцях розглядати code generation або ручну оптимізовану
  (де)серіалізацію.

6. **Керування розміром payload:**
- стискання доречне лише після вимірювань, бо воно додає CPU-витрати;
- іноді вигідніше передавати менше даних, ніж «краще» стискати.

#### Як оцінювати ефект:

1. Бенчмарки (`go test -bench`) до/після.
2. Профілі CPU/alloc (`pprof`).
3. Метрики продакшну: throughput, p95/p99 latency, heap, GC.

#### Висновок:

Оптимальна серіалізація — це баланс формату, алокацій і складності коду.
У Go найкраща практика: профілювати, прибирати зайві копії, перевикористовувати
буфери та обирати формат, який відповідає вимогам конкретної системи.

</details>

<details>
<summary>71. Як оптимізувати роботу з файлами?</summary>

#### Go

Оптимізація файлового I/O в Go полягає в правильному виборі патерну читання/
запису, розміру буферів, рівня конкурентності та стратегії роботи з диском.
Головна мета — зменшити системні виклики, зайві копії та блокування.

#### Ключові практики:

1. **Буферизований I/O (`bufio.Reader/Writer`):**
   зменшує кількість дрібних `read/write` і підвищує throughput.

2. **Пакетна обробка замість по-байтного доступу:**
   читати/писати блоками значно ефективніше, ніж дрібними операціями.

3. **Потокова обробка великих файлів:**
   не завантажувати весь файл у пам'ять, якщо можна обробляти частинами.

4. **Правильне керування дескрипторами:**
   `defer file.Close()` одразу після відкриття — базова гігієна для уникнення
   витоків FD.

5. **Контроль конкурентності:**
   паралелізм корисний лише в межах пропускної здатності диска/FS; надмірні
   паралельні I/O-операції можуть погіршити latency.

6. **Мінімізація зайвих копій:**
   використовувати `io.Copy` та перевикористання буферів, де це доречно.

7. **Профілювання перед оптимізацією:**
   вимірювати, чи bottleneck у диску, CPU, серіалізації або синхронізації.

#### Додаткові інженерні поради:

1. Для журналів/подій враховувати flush-політику (часті flush = нижчий
   throughput).
2. Для великих пайплайнів розділяти читання, обробку й запис у керовані етапи.
3. Для критичних сценаріїв перевіряти файлову систему й налаштування контейнера/
   хоста (I/O quota, volume type, network storage).

#### Висновок:

Ефективна робота з файлами в Go — це дисципліна буферизації, потоковості,
контрольованого паралелізму та вимірювань. Оптимізація має спиратися на
профіль реального навантаження, а не на загальні припущення.

</details>

<details>
<summary>72. Як працює batching і коли він доречний?</summary>

#### Go

`Batching` — це об'єднання багатьох дрібних операцій у більші пакети (batch),
щоб зменшити накладні витрати на кожну окрему дію. У високонавантажених системах
це один із найдієвіших способів підвищити throughput.

#### Як працює batching:

1. Події/записи накопичуються в буфері.
2. Batch відправляється за одним із тригерів:
- досягнуто розмір `N`;
- минув таймаут `T`;
- отримано сигнал завершення/flush.
3. Операція виконується одним «пакетним» викликом (БД, мережа, диск, черга).

#### Чому це ефективно:

1. **Менше системних викликів і round-trip-ів.**
2. **Краще завантаження I/O-каналу** (мережі, диска, БД).
3. **Менші накладні витрати на синхронізацію** для великої кількості дрібних
   задач.

#### Коли batching доречний:

1. Масові однотипні операції (логування, телеметрія, bulk insert/update).
2. Сценарії, де важливіший throughput, ніж мінімально можлива одинична latency.
3. Інтеграції, у яких зовнішня система добре працює з пакетними запитами.

#### Коли batching може шкодити:

1. Жорсткі вимоги до затримки окремої операції.
2. Невдала конфігурація batch-size/timeout, що збільшує tail latency.
3. Високий ризик втрати великого блоку даних без правильної retry/flush-логіки.

#### Практичні правила:

1. Налаштовувати **і розмір, і час** (`N` + `T`) одночасно.
2. Мати явний flush при shutdown.
3. Забезпечити retry/backoff для часткових або повних збоїв batch-запитів.
4. Вимірювати баланс throughput ↔ latency на реальному навантаженні.

#### Висновок:

Batching — це архітектурний мультиплікатор продуктивності для масових операцій.
Його сила розкривається там, де зменшення per-request overhead важливіше за
миттєву відповідь кожної одиничної події.

</details>

<details>
<summary>73. Коли code generation (`go generate`) краще ніж reflection?</summary>

#### Go

`Code generation` і `reflection` вирішують схожі задачі метапрограмування, але
мають різну ціну. У Go генерація коду часто виграє там, де потрібні швидкість,
типобезпечність і передбачуваність у продакшні.

#### Коли `go generate` кращий за reflection:

1. **Hot-path продуктивність критична:**
   згенерований код працює без runtime-рефлексії, отже зазвичай швидший і з
   меншими алокаціями.

2. **Потрібна сильна типобезпечність:**
   помилки виявляються на етапі компіляції, а не під час виконання.

3. **Високі вимоги до latency/throughput:**
   serialization, mapping, RPC-кодеки, валідація в масових запитах.

4. **Стабільний контракт даних:**
   коли схеми відомі наперед і рідко змінюються.

5. **Потрібна прозора відлагоджуваність:**
   згенеровані виклики можна профілювати й аналізувати як звичайний Go-код.

#### Коли reflection виправдана:

1. Схема динамічна й визначається лише в runtime.
2. Потрібен швидкий прототип або універсальна бібліотечна гнучкість.
3. Невисокі вимоги до продуктивності, де простіше прийняти runtime-overhead.

#### Компроміси `go generate`:

1. Додає крок у build/workflow.
2. Потрібно підтримувати шаблони/генератори.
3. Генерований код збільшує обсяг репозиторію.

#### Практичний висновок:

Якщо система чутлива до продуктивності й типова модель стабільна, `go generate`
зазвичай кращий за reflection. Reflection доречна там, де головна цінність —
динамічність, а не максимальна ефективність виконання.

</details>

<details>
<summary>74. Що таке Escape Analysis і як його перевірити прапорцями компілятора?</summary>

#### Go

`Escape Analysis` — це аналіз компілятора Go, який визначає, чи може значення
залишатися на стеку, чи мусить бути алоковане в купі (heap), бо «втікає» за межі
поточного стек-фрейму.

#### Навіщо це важливо:

1. Stack-алокації дешевші.
2. Heap-алокації збільшують тиск на GC.
3. Розуміння escape-поведінки допомагає оптимізувати гарячі шляхи.

#### Типові причини escape:

1. Повернення вказівника на локальне значення.
2. Збереження значення у довгоживучій структурі.
3. Захоплення змінної closure-ом.
4. Передача значення у контексти, де компілятор не може гарантувати локальний
   життєвий цикл.

#### Як перевірити прапорцями компілятора:

Найуживаніший спосіб:

1. `go build -gcflags="-m" ./...`
2. Для детальнішого виводу:
   `go build -gcflags="-m -m" ./...`

У повідомленнях шукають фрази на кшталт:

- `moved to heap`
- `escapes to heap`

Це прямий індикатор, що значення не залишилося на стеку.

#### Практичний процес:

1. Запустити бенчмарк/профіль і знайти гарячий фрагмент.
2. Перевірити escape-вивід компілятора для цієї ділянки.
3. Рефакторити локально (без погіршення читабельності).
4. Повторно виміряти ефект (`bench`, `pprof`, allocs/op).

#### Висновок:

Escape Analysis — це компіляторний «радар» алокаційної поведінки. Через
`-gcflags="-m"` можна побачити, де дані тікають у heap, і приймати обґрунтовані
рішення щодо оптимізації пам'яті та продуктивності.

</details>

<details>
<summary>75. Чому `panic` і `recover` — не заміна нормальному error handling?</summary>

#### Go

У Go `panic/recover` призначені для виняткових, аварійних ситуацій, а не для
звичайного керування помилками бізнес-логіки. Нормальний шлях обробки помилок —
це явне повернення `error` і контрольований потік виконання.

#### Чому `panic/recover` не замінюють `error handling`:

1. **Порушують явність контракту:**
   з `error` сигнатура функції прямо показує, що може піти не так; із `panic`
   помилка стає неявною.

2. **Ускладнюють контроль потоку:**
   panic розмотує стек, що робить поведінку менш передбачуваною для викликача.

3. **Гірше тестуються:**
   перевірка panic-сценаріїв складніша й менш природна, ніж перевірка повернених
   помилок.

4. **Погіршують надійність сервісів:**
   неперехоплена panic у горутині може зруйнувати процес або важливий контур
   обробки.

5. **`recover` має локальну природу:**
   працює лише в `defer` тієї ж горутини, тому не є універсальним механізмом
   помилок між компонентами.

#### Коли `panic` виправдана:

1. Порушення внутрішніх інваріантів, що означає програмну помилку.
2. Неможливі за контрактом стани («це не повинно трапитись ніколи»).
3. Критичні збої ініціалізації, коли продовжувати роботу некоректно.

#### Коли потрібен `error`:

1. Очікувані збої зовнішніх систем (мережа, БД, I/O).
2. Валідаційні та доменні помилки.
3. Будь-які ситуації, де викликач має право вибору, як реагувати.

#### Висновок:

У зрілому Go-коді `error` — це основний інструмент керованої обробки помилок.
`panic/recover` — аварійний механізм для виняткових випадків, а не повсякденна
альтернатива стандартному error handling.

</details>

<details>
<summary>76. Як у Go працюють `errors.Is` і `errors.As` при error wrapping і в чому між ними різниця?</summary>

#### Go

У сучасному Go помилки часто «обгортають» (wrapping), додаючи контекст через
`fmt.Errorf("...: %w", err)`. `errors.Is` і `errors.As` дозволяють коректно
працювати з таким ланцюжком помилок, не втрачаючи первинну причину.

#### Як працює `errors.Is`:

1. Перевіряє, чи є в ланцюжку помилок конкретна цільова помилка.
2. Використовується переважно для sentinel-помилок (`io.EOF`, `context.Canceled`
   тощо).
3. Семантика: **"чи це (або обгорнута версія) саме ця помилка?"**

#### Як працює `errors.As`:

1. Шукає в ланцюжку помилку певного типу.
2. Якщо знаходить — записує її у переданий target (вказівник).
3. Семантика: **"чи можна витягти з ланцюжка помилку цього типу?"**

#### Ключова різниця:

1. `errors.Is` — перевірка **ідентичності/еквівалентності** помилки.
2. `errors.As` — перевірка **типу** і доступ до типоспецифічних полів/методів.

#### Практичний патерн використання:

1. Спершу `errors.Is` для відомих sentinel-кейсів.
2. Потім `errors.As`, якщо потрібні деталі custom-типу (код, метадані, контекст).
3. Не порівнювати wrapped-помилки через `==`, бо так втрачається коректність у
   ланцюжку обгортань.

#### Висновок:

`errors.Is` відповідає на питання «це та сама помилка?», а `errors.As` — «це
помилка такого типу?». Разом вони формують правильну й надійну модель роботи з
error wrapping у Go.

#### Приклад:

```go
if err := repo.Save(ctx, x); err != nil {
	return fmt.Errorf("save user: %w", err)
}

if errors.Is(err, sql.ErrNoRows) {
	// перевірка sentinel-помилки
}

var ve *ValidationError
if errors.As(err, &ve) {
	// доступ до полів конкретного типу помилки
}
```

</details>

<details>
<summary>77. Коли варто використовувати custom error type замість sentinel error і які практичні наслідки цього вибору для архітектури?</summary>

#### Go

`Sentinel error` і `custom error type` — це різні інструменти моделювання
помилок. Sentinel підходить для простого бінарного сигналу, а custom type —
коли помилка несе структурований контекст і впливає на поведінку кількох шарів
системи.

#### Коли достатньо sentinel error:

1. Потрібен лише факт конкретної категорії помилки.
2. Немає потреби передавати додаткові поля.
3. Вистачає перевірки через `errors.Is`.

#### Коли варто custom error type:

1. Потрібні **структуровані деталі**:
- код помилки;
- доменна причина;
- ідентифікатор ресурсу;
- retryability;
- HTTP/gRPC mapping.

2. Різні шари мають приймати різні рішення на основі цих полів.
3. Потрібна стійка еволюція контракту помилок без хаотичних string-перевірок.

#### Архітектурні наслідки вибору:

1. **Sentinel error**
- простіший старт;
- менше коду;
- але слабша виразність і ризик «розростання» неявних правил обробки.

2. **Custom error type**
- чіткіший доменний контракт;
- краща інтеграція між transport/service/domain шарами;
- вища тестованість політик обробки;
- але потребує дисципліни дизайну й versioning-підходу.

#### Рекомендована практика:

1. Для простих global-сигналів — sentinel.
2. Для доменно значущих помилок — custom type + `errors.As`.
3. Обгортати нижчі помилки через `%w`, не втрачаючи причинно-наслідковий ланцюг.

#### Висновок:

Вибір між sentinel і custom type — це вибір рівня виразності архітектури
помилок. Коли помилка впливає на маршрутизацію рішень у системі, custom error
type дає значно міцніший і масштабованіший контракт.

</details>

<details>
<summary>78. Як поводиться `defer` усередині циклу і які можуть бути наслідки для пам'яті та виконання?</summary>

#### Go

`defer` у Go виконується не наприкінці ітерації циклу, а в момент виходу з
оточувальної функції. Тому `defer` усередині циклу накопичується і спрацьовує
лише після завершення всієї функції.

#### Як це працює:

1. Кожна ітерація додає новий відкладений виклик у стек defer-ів.
2. До кінця функції ці виклики не виконуються.
3. Під час виходу вони запускаються у зворотному порядку (LIFO).

#### Потенційні наслідки:

1. **Затримане звільнення ресурсів:**
   файли, сокети, транзакції, блокування можуть залишатися відкритими довше, ніж
   потрібно.

2. **Ріст споживання пам'яті:**
   багато defer-записів у довгому циклі збільшують накладні витрати.

3. **Погіршення продуктивності:**
   у гарячих циклах надмірні defer-и додають runtime-overhead.

4. **Ризик вичерпання ресурсів:**
   наприклад, «too many open files», якщо `defer file.Close()` стоїть у великому
   циклі читання.

#### Коли це безпечно:

1. Невелика кількість ітерацій.
2. Короткий життєвий цикл функції.
3. Ресурси не є дефіцитними.

#### Краща практика для циклів:

1. Виносити тіло ітерації в окрему функцію й ставити `defer` там.
2. Або закривати/звільняти ресурс явно в кінці кожної ітерації.
3. Для lock-ів особливо уважно контролювати час утримання критичної секції.

#### Висновок:

`defer` у циклі — інструмент, що потребує дисципліни: він спрощує код, але може
непомітно накопичувати ресурси й накладні витрати. Якщо ітерацій багато, краще
забезпечити звільнення ресурсів у межах кожного кроку.

</details>

<details>
<summary>79. Як працює функція `init` і чи можна покладатися на порядок її виконання?</summary>

#### Go

`init` у Go — спеціальна функція пакета, яка виконується автоматично під час
ініціалізації програми (до `main`). Вона використовується для початкового
налаштування, яке має відбутися один раз перед стартом основної логіки.

#### Як працює ініціалізація:

1. Спочатку ініціалізуються імпортовані залежності.
2. Потім ініціалізуються змінні пакета.
3. Після цього викликаються `init`-функції пакета.
4. Лише після завершення всього дерева ініціалізації запускається `main`.

#### Чи можна покладатися на порядок:

1. **Між пакетами**: так, у межах залежностей порядок визначений —
   спочатку залежності, потім пакет-споживач.

2. **У межах одного пакета**:
- порядок ініціалізації змінних визначається залежностями між ними;
- для кількох `init` у різних файлах одного пакета покладатися на «випадковий»
  текстовий порядок файлів — погана ідея з погляду дизайну.

3. Висновок: базові гарантії є, але архітектурно краще не будувати критичну
   бізнес-логіку на складних неявних `init`-ланцюжках.

#### Ризики надмірного використання `init`:

1. Неявні побічні ефекти.
2. Важчий дебаг і тестування.
3. Складніший контроль порядку в великих кодових базах.

#### Практична рекомендація:

1. Тримати `init` мінімальним і передбачуваним.
2. Для важливих ініціалізацій використовувати явні конструктори/`Setup`-функції.
3. Залежності й порядок запуску фіксувати явно в композиційному шарі.

#### Висновок:

`init` у Go виконується автоматично і має формальні гарантії порядку на рівні
графа імпортів. Проте для читабельної, тестованої архітектури критичні
ініціалізації краще робити явними, а не покладатися на приховані ефекти `init`.

</details>

<details>
<summary>80. Чому варто уникати глобальних змінних та `init`-функцій у бібліотеках?</summary>

#### Go

У бібліотечному коді глобальні змінні та «важкі» `init`-функції часто створюють
неявну поведінку, яка ускладнює інтеграцію, тестування й передбачуваність
застосунку. Для reusable-пакетів це особливо критично.

#### Чому глобальні змінні шкідливі в бібліотеках:

1. **Прихований shared mutable state:**
   споживач бібліотеки може не знати, що десь існує глобальний стан, який
   впливає на поведінку.

2. **Проблеми конкурентності:**
   глобалі легко стають джерелом race/контеншну.

3. **Складне тестування:**
   тести починають залежати від порядку запуску й побічних ефектів попередніх
   кейсів.

4. **Погана композиційність:**
   важко мати кілька незалежних інстансів бібліотеки з різними налаштуваннями.

#### Чому «важкий» `init` небажаний:

1. **Неявні побічні ефекти при імпорті:**
   достатньо `import`, і код вже виконується.

2. **Немає явного контролю часу ініціалізації:**
   складно керувати порядком/умовами запуску в великому застосунку.

3. **Погіршений observability/debuggability:**
   помилки старту та побічні дії важче локалізувати.

#### Що краще замість цього:

1. Явні конструктори (`New(...)`) і конфігураційні структури.
2. Інстанс-орієнтований дизайн без глобального mutable state.
3. Явний `Setup/Start/Close` життєвий цикл там, де це потрібно.
4. Мінімальний `init` лише для дій без побічних ефектів.

#### Висновок:

Бібліотека має бути передбачуваною та керованою споживачем. Відмова від
глобальних станів і надмірного `init` — це інвестиція в тестованість,
масштабованість і архітектурну чистоту Go-коду.

</details>

<details>
<summary>81. Що буде, якщо серіалізувати в JSON структуру з полями, що починаються з малої літери?</summary>

#### Go

У Go поля структури, що починаються з малої літери, є неекспортованими
(`unexported`). Пакет `encoding/json` не має до них рефлексивного доступу як до
публічних полів, тому під час серіалізації вони ігноруються.

#### Що станеться при `json.Marshal`:

1. У JSON потраплять лише експортовані поля (з великої літери).
2. Поля з малої літери будуть пропущені.
3. Теги `json:"..."` на неекспортованих полях не «примушують» їх серіалізувати.

#### Наслідки на практиці:

1. Неочікувано «порожній» або неповний JSON.
2. Втрата важливих даних у відповідях API.
3. Складні для дебагу помилки, якщо розробник не врахував правило експорту.

#### Що з десеріалізацією (`json.Unmarshal`):

1. Аналогічно, `encoding/json` не запише дані в неекспортовані поля напряму.
2. Для контролю процесу потрібні кастомні `MarshalJSON` / `UnmarshalJSON`,
   окремі DTO або інші явні механізми трансформації.

#### Практичне правило:

1. Для полів, що мають потрапляти в JSON, використовуйте експортовані назви.
2. Доменно чутливі внутрішні дані тримайте неекспортованими свідомо.
3. Розділяйте внутрішні моделі й транспортні DTO, коли потрібен тонкий контроль
   публічного контракту.

#### Висновок:

У Go JSON-серіалізація працює лише з експортованими полями структури. Поля з
малої літери в стандартному `encoding/json` не серіалізуються, навіть якщо для
них указано теги.

</details>

<details>
<summary>82. Які є способи діставати дані з JSON у Go?</summary>

#### Go

У Go немає єдиного «правильного» способу роботи з JSON: підхід обирають за
стабільністю схеми, вимогами до продуктивності та рівнем типобезпеки.

#### Основні способи:

1. **Декодування у структуру (`struct`)**
- найтиповіший і найнадійніший варіант для відомої схеми;
- дає типобезпечність, зрозумілі контракти й кращу підтримуваність.

2. **Декодування у `map[string]any`**
- зручно для частково динамічних payload-ів;
- гнучко, але менш безпечно: потрібні assertion-и та перевірки типів.

3. **Потокове читання через `json.Decoder`**
- підходить для великих JSON або потоків (HTTP body, файли);
- дозволяє працювати без завантаження всього документа в пам'ять.

4. **`json.RawMessage` для відкладеного/часткового парсингу**
- корисно, коли частина схеми залежить від поля-«дискримінатора»;
- дає контроль над етапами декодування.

5. **Кастомні `UnmarshalJSON` / `MarshalJSON`**
- для нестандартних форматів, валідації або спеціальної бізнес-семантики.

6. **Треті бібліотеки / codegen**
- доречно для high-performance або специфічних вимог сумісності.

#### Практичний вибір:

1. Стабільний API-контракт → `struct`.
2. Динамічний або частково невідомий JSON → `map` + `RawMessage`.
3. Великі обсяги даних → `Decoder` (streaming).
4. Критичний performance/pathological JSON → профілювання + codegen/альтернативи.

#### Висновок:

Оптимальний спосіб «діставати» JSON-дані в Go залежить від природи схеми.
У більшості продакшн-випадків базовим вибором є typed-структури, а динамічні
механізми (`map`, `RawMessage`, кастомний unmarshal) — для складніших сценаріїв.

</details>

<details>
<summary>83. Яка різниця між `json.Marshal` і `json.Encoder`?</summary>

#### Go

`json.Marshal` і `json.Encoder` виконують схожу задачу серіалізації, але мають
різну модель роботи з пам'яттю та I/O. Вибір залежить від того, чи потрібен вам
готовий `[]byte`, чи потоковий запис напряму в `io.Writer`.

#### `json.Marshal`:

1. Повертає серіалізований JSON як `[]byte`.
2. Зручно, коли треба:
- отримати байтовий масив для подальшої обробки;
- логувати/підписувати/стискати payload перед відправкою;
- працювати з JSON у пам'яті.

3. Мінус: для великих об'єктів може вимагати більше пам'яті, бо результат
   спершу повністю формується в буфері.

#### `json.Encoder`:

1. Пише JSON одразу в `io.Writer` (`http.ResponseWriter`, файл, сокет).
2. Підходить для потокового сценарію й великих відповідей.
3. Часто зручніший у HTTP-handlers, бо зменшує проміжні буфери.
4. `Encode` додає символ нового рядка в кінці (це важливо враховувати).

#### Практичне правило вибору:

1. Потрібен JSON як значення в коді → `json.Marshal`.
2. Потрібно одразу писати в потік/відповідь → `json.NewEncoder(w).Encode(...)`.

#### Висновок:

`Marshal` — «сформуй JSON у пам'яті», `Encoder` — «запиши JSON у потік».
Функціонально вони близькі, але з погляду ресурсів і архітектури I/O різниця
принципова.

#### Приклад:

```go
// Marshal: отримуємо JSON у []byte
payload, err := json.Marshal(resp)
if err != nil { return err }
_ = payload

// Encoder: пишемо JSON одразу у HTTP-відповідь
w.Header().Set("Content-Type", "application/json")
if err := json.NewEncoder(w).Encode(resp); err != nil {
	return err
}
```

</details>

<details>
<summary>84. Що таке `json.RawMessage` і коли воно корисне?</summary>

#### Go

`json.RawMessage` — це тип (по суті `[]byte`) з пакета `encoding/json`, який
дозволяє зберегти фрагмент JSON «як є» без негайного розбору в конкретну
структуру.

#### Що це дає:

1. **Відкладений парсинг:**
   можна спочатку розібрати лише «обгортку» повідомлення, а складне поле —
   пізніше, коли відомий потрібний тип.

2. **Часткове декодування:**
   розбираємо тільки ті частини payload, які реально потрібні в цьому кроці.

3. **Прозора ретрансляція:**
   фрагмент JSON можна передати далі без втрати оригінального представлення.

#### Коли це особливо корисно:

1. **Поліморфні payload-и:**
   коли тип поля залежить від `type/kind/version`-дискримінатора.

2. **Event-driven системи:**
   обгортка події стабільна, а тіло події має різні схеми.

3. **Інтеграційні шлюзи:**
   потрібно прочитати метадані маршрутизації і передати «body» далі майже без
   змін.

4. **Оптимізація продуктивності:**
   уникнення зайвого повного unmarshal для великих або частково непотрібних
   об'єктів.

#### На що зважати:

1. `RawMessage` не валідовує семантику автоматично — перевірка лишається на
   вашій логіці при подальшому `Unmarshal`.
2. Відкладений розбір ускладнює код, якщо застосовувати без реальної потреби.

#### Висновок:

`json.RawMessage` — інструмент керованого «пізнього зв'язування» JSON-даних.
Він особливо цінний у поліморфних і багатоформатних протоколах, де тип
внутрішнього payload визначається лише під час виконання.

</details>

<details>
<summary>85. Як реалізувати кастомний маршалер для JSON?</summary>

#### Go

Кастомний маршалер у Go реалізують через метод `MarshalJSON() ([]byte, error)`
на вашому типі. Це дозволяє повністю контролювати, як об'єкт серіалізується в
JSON: формат полів, валідацію, обчислювані значення, маскування тощо.

#### Базовий підхід:

1. Додати метод:
   `func (t MyType) MarshalJSON() ([]byte, error)`.
2. Усередині сформувати проміжне представлення (часто alias/DTO-структуру).
3. Викликати `json.Marshal` для цього представлення.
4. Повернути байти або помилку.

#### Навіщо це роблять:

1. **Нестандартний формат виводу:**
   наприклад, перетворення часу, enum, decimal, полів-масок.

2. **Сумісність із зовнішнім контрактом:**
   коли API вимагає специфічної схеми або naming-конвенцій.

3. **Кероване приховування даних:**
   не виводити чутливі поля або формувати редаговану версію.

4. **Обчислювані/похідні поля:**
   включати в JSON значення, яких нема як «сирих» полів структури.

#### Типова техніка без рекурсії:

Щоб уникнути нескінченного виклику `MarshalJSON`, використовують alias-тип
(`type alias MyType`) і маршалять alias або окремий DTO.

#### Важливі поради:

1. Тримати логіку маршалінгу детермінованою та простою.
2. Писати тести на edge-cases і backward compatibility JSON-контракту.
3. Якщо потрібна симетрія, реалізувати також `UnmarshalJSON`.

#### Висновок:

Кастомний `MarshalJSON` — це інструмент точного контролю над публічним
представленням даних. У продакшні його застосовують тоді, коли стандартних тегів
недостатньо для контракту, безпеки або доменної семантики.

</details>

<details>
<summary>86. Як парсити різнотипний JSON, якщо вхідні дані або якісь з полів можуть бути або масивом `[...]`, або об'єктом `{...}`?</summary>

#### Go

Коли JSON-поле має «плаваючу» форму (інколи масив, інколи об'єкт), найнадійніший
підхід у Go — відкладене декодування через `json.RawMessage` або кастомний
`UnmarshalJSON` із розпізнаванням фактичного типу.

#### Канонічна стратегія:

1. Декодувати проблемне поле у `json.RawMessage`.
2. Подивитися на перший значущий байт:
- `[` → це масив;
- `{` → це об'єкт.
3. Залежно від форми виконати `json.Unmarshal` у відповідний цільовий тип.
4. Нормалізувати результат у внутрішню єдину модель (щоб далі код не залежав від
   зовнішньої «плинної» схеми).

#### Альтернатива: кастомний `UnmarshalJSON`:

1. Реалізувати метод на власному типі.
2. Усередині методу спробувати розбір у `[]T`, а якщо не підходить — у `T`
   (або навпаки).
3. Зберегти в уніфікованому представленні, наприклад завжди як `[]T`.

#### Чому це важливо:

1. Зовнішні API часто непослідовні між версіями/ендпойнтами.
2. Прямий `Unmarshal` у жорстку структуру дає помилки типу
   `cannot unmarshal object into Go value of type []...`.
3. Нормалізація на вході різко спрощує решту бізнес-логіки.

#### Практичні поради:

1. Чітко документувати допустимі форми вхідного JSON.
2. Логувати аномальні payload-и для діагностики контрактних збоїв.
3. Покривати тестами обидві форми (`{}` і `[]`) + edge-cases (null, порожні
   значення, некоректний тип).

#### Висновок:

Для різнотипного JSON у Go найкраще працює патерн «RawMessage → детекція форми →
цільовий Unmarshal → нормалізація». Це дає стабільну обробку навіть за
нестабільного зовнішнього контракту.

</details>

<details>
<summary>87. Як у Go тестувати серіалізацію (XML/JSON), коли порядок ключів у мапі не детермінований?</summary>

#### Go

Коли порядок ключів у `map` недетермінований, тести не можна будувати на
буквальному порівнянні «сирих» рядків серіалізації. Правильний підхід —
порівнювати зміст, а не випадковий порядок представлення.

#### Надійні стратегії для JSON:

1. **Round-trip порівняння структури:**
- серіалізувати;
- десеріалізувати назад у тип/нормалізовану модель;
- порівнювати дані як структуру.

2. **Канонізація перед порівнянням:**
- розібрати JSON у проміжну модель;
- відсортувати ключі/колекції;
- порівнювати канонічний вигляд.

3. **Semantic assertions замість string equality:**
- перевіряти конкретні поля й інваріанти.

#### Для XML:

1. Подібний принцип: порівнювати дерево елементів/атрибутів, а не сирий рядок.
2. Нормалізувати пробіли, форматування, порядок атрибутів (якщо контракт це
   дозволяє).
3. Перевіряти смислову еквівалентність parsed-структур.

#### Коли потрібен golden-файл:

1. Формуйте **детермінований output**:
- сортуйте ключі перед серіалізацією;
- або серіалізуйте не `map`, а структуру/впорядкований список пар.

2. Golden-тест має падати лише на семантичних змінах контракту, а не на
   випадковому порядку ключів.

#### Практичний висновок:

У тестах серіалізації для `map` порівнюють не «текст один-в-один», а
еквівалентність даних. Детермінізм треба або вводити явно (сортування), або
застосовувати semantic-level перевірки.

</details>

<details>
<summary>88. У чому переваги та недоліки Protobuf порівняно з JSON? Як відрізняється серіалізація в Protobuf?</summary>

#### Go

Protobuf і JSON — це два різні класи форматів: JSON орієнтований на
людинозчитуваність та універсальність, а Protobuf — на компактність, швидкість і
контрактність машинної взаємодії.

#### Переваги Protobuf над JSON:

1. **Компактніший розмір payload:**
   бінарне кодування зазвичай істотно менше за текстовий JSON.

2. **Вища продуктивність серіалізації/десеріалізації:**
   менше парсингових витрат і краща пропускна здатність у міжсервісному трафіку.

3. **Строгий schema-first контракт (`.proto`):**
   чітка типова модель, codegen і контроль еволюції полів.

4. **Краща backward/forward сумісність за правилом полів і тегів.**

#### Недоліки Protobuf:

1. **Менш читабельний «на око»:**
   бінарний формат не зручний для ручного дебагу без інструментів.

2. **Додаткова інфраструктура:**
   `.proto`, генерація коду, керування версіями схем.

3. **Поріг входу вищий, ніж у JSON.**

#### Переваги JSON:

1. Простота інтеграції й швидкий старт.
2. Людинозчитуваність і зручність ручного аналізу.
3. Широка сумісність у веб-екосистемі.

#### Як відрізняється серіалізація в Protobuf:

1. Дані кодуються не іменами полів, а числовими тегами (`field numbers`).
2. Формат бінарний, із чіткими типами wire-level.
3. Структури генеруються з `.proto` (code generation), а не відбиваються
   рефлексією як у типовому JSON-потоці.
4. Еволюція контракту вимагає дисципліни:
- не перевикористовувати старі теги;
- обережно змінювати типи/optional/repeated поля.

#### Висновок:

JSON кращий для відкритих, людиноорієнтованих API та швидкої інтеграції.
Protobuf — для високопродуктивних міжсервісних систем із чітким схемним
контрактом, де критичні розмір payload, latency і стабільність еволюції.

</details>

<details>
<summary>89. Чому `http.Client` варто перевикористовувати замість створювати новий на кожен запит?</summary>

#### Go

У Go `http.Client` і його транспорт (`http.Transport`) керують пулом TCP-з'єднань,
keep-alive, TLS-сесіями та іншими мережевими оптимізаціями. Якщо створювати
новий клієнт на кожен запит, ці переваги втрачаються.

#### Чому перевикористання важливе:

1. **Connection pooling:**
   повторне використання вже відкритих з'єднань знижує latency.

2. **Менше накладних витрат на handshake:**
   менше TCP/TLS встановлень для кожного запиту.

3. **Краща пропускна здатність:**
   стабільніший throughput у high-load сценаріях.

4. **Контроль ресурсів:**
   масове створення нових клієнтів/транспортів може збільшити кількість сокетів і
   призвести до виснаження системних ресурсів.

#### Що відбувається при «client per request»:

1. Гірша утилізація keep-alive.
2. Більше короткоживучих з'єднань.
3. Вищі затримки та зайвий тиск на мережу/CPU.

#### Рекомендована практика:

1. Мати довгоживучий `http.Client` (часто один на сервіс або на клас політик).
2. Налаштовувати таймаути й параметри `Transport` явно під workload.
3. Для різних SLA/маршрутів — окремі перевикористовувані клієнти, але не
   «новий клієнт на кожен виклик».

#### Висновок:

`http.Client` у Go слід перевикористовувати, бо це дає мережеву ефективність,
нижчу latency і кращу стабільність під навантаженням. Створення нового клієнта
на кожен запит — типова антипрактика для продакшн-систем.

</details>

<details>
<summary>90. Чому потрібно обов'язково закривати `resp.Body` після HTTP-запиту?</summary>

#### Go

`resp.Body` у Go — це потоковий ресурс, пов'язаний із мережевим з'єднанням.
Якщо його не закривати, клієнт не зможе коректно повернути з'єднання в пул або
звільнити системні ресурси, що призводить до деградації сервісу.

#### Чому це критично:

1. **Витік ресурсів:**
   незакриті body утримують дескриптори й сокети.

2. **Погіршення connection reuse:**
   keep-alive працює гірше, зростає кількість нових з'єднань.

3. **Зростання latency та помилок під навантаженням:**
   можливе виснаження пулу з'єднань і системних лімітів.

4. **Нестабільна поведінка клієнта:**
   «зависання», таймаути, неочікувані збої в високочастотних викликах.

#### Правильний патерн:

1. Після перевірки помилки від `Do` одразу робити:
   `defer resp.Body.Close()`.

2. За потреби максимального reuse-з'єднань:
- дочитати body до кінця (або коректно обмежити читання),
- і потім закрити.

#### Практичний висновок:

Закриття `resp.Body` — не формальність, а обов'язкова умова коректної роботи
HTTP-клієнта в Go. Це напряму впливає на продуктивність, стабільність і ресурсну
ефективність сервісу.

#### Приклад:

```go
resp, err := client.Do(req)
if err != nil {
	return err
}
defer resp.Body.Close()

body, err := io.ReadAll(resp.Body)
if err != nil {
	return err
}
_ = body
```

</details>

<details>
<summary>91. Як `http.DefaultServeMux` відрізняється від кастомного `ServeMux`?</summary>

#### Go

`http.DefaultServeMux` — це глобальний маршрутизатор «за замовчуванням».
Кастомний `ServeMux` — окремий явно створений екземпляр маршрутизатора, яким ви
керуєте локально в межах конкретного сервера.

#### `http.DefaultServeMux`:

1. **Глобальний стан пакета `net/http`:**
   реєстрація через `http.Handle` / `http.HandleFunc` пише саме туди.

2. **Швидкий старт:**
   зручно для простих прикладів і невеликих утиліт.

3. **Ризики в більших проєктах:**
   неявні реєстрації з різних пакетів, складніший контроль залежностей і тестів.

#### Кастомний `ServeMux`:

1. **Явна композиція:**
   `mux := http.NewServeMux()` і передача його в `http.Server{Handler: mux}`.

2. **Ізоляція маршрутів:**
   кожен сервер/тест/інстанс може мати власну таблицю хендлерів.

3. **Краща тестованість і підтримуваність:**
   менше глобальних побічних ефектів, легше робити незалежні інтеграційні тести.

4. **Безпечніша архітектура для монолітів і мікросервісів:**
   маршрутизація стає частиною явного bootstrap-коду.

#### Практичний вибір:

1. Для продакшн-коду майже завжди краще кастомний `ServeMux`.
2. `DefaultServeMux` доречний переважно для дуже простих сценаріїв або
   навчальних прикладів.

#### Висновок:

Різниця між ними — у рівні явності й контролю. `DefaultServeMux` зручний, але
глобальний; кастомний `ServeMux` дає ізольовану, керовану й архітектурно чистішу
маршрутизацію.

</details>

<details>
<summary>92. Як у Go правильно реалізувати graceful shutdown HTTP-сервера і фонового воркера?</summary>

#### Go

`Graceful shutdown` у Go — це контрольоване завершення сервісу без втрати
запитів і без «осиротілих» горутин. Ідея проста: припинити прийом нового
навантаження, дати завершитися активній роботі, коректно зупинити фон і закрити
ресурси в передбачуваній послідовності.

#### Канонічна послідовність:

1. Перехопити сигнали завершення (`SIGTERM`, `SIGINT`).
2. Створити `context` із таймаутом для shutdown-фази.
3. Викликати `server.Shutdown(ctx)`:
- нові з'єднання більше не приймаються;
- активні запити отримують час завершитися.
4. Скасувати контекст/сигналізувати фоновим воркерам про зупинку.
5. Дочекатися завершення воркерів (`WaitGroup`/`errgroup`).
6. Закрити зовнішні ресурси (БД, черги, продюсери, файли).

#### Як зупиняти фоновий воркер:

1. Воркер працює в циклі з `select`, де є гілка `case <-ctx.Done(): return`.
2. На shutdown основний процес викликає cancel-функцію.
3. Воркер завершує поточний безпечний крок, робить flush/cleanup і виходить.

#### Критичні практики:

1. **Таймаути обов'язкові:** graceful не має перетворюватися на вічне очікування.
2. **Idempotent shutdown:** повторні сигнали не ламають логіку зупинки.
3. **Спостережуваність:** логувати стадії зупинки й метрики тривалості.
4. **Чіткий порядок:** спершу stop intake, потім drain in-flight, далі cleanup.

#### Типові помилки:

1. Зупиняти процес «жорстко» без `Shutdown`.
2. Не передавати `ctx` у воркери/зовнішні виклики.
3. Не чекати завершення горутин.
4. Забути про flush буферів/черг перед exit.

#### Висновок:

Правильний graceful shutdown у Go — це orchestration через сигнал, `context`,
`server.Shutdown` і явне дочекання всіх фонових задач. Такий підхід гарантує
цілісність запитів, передбачуваний вихід і надійність експлуатації.

</details>

<details>
<summary>93. Чому `time.Time` порівнювати через `.Equal()`, а не `==`?</summary>

#### Go

У Go `time.Time` варто порівнювати через `t1.Equal(t2)`, бо `==` перевіряє
структуру значення «біт-до-біта», включно з допоміжними внутрішніми компонентами
(зокрема локацією й, за певних умов, монотонною частиною часу), а не лише момент
часу на часовій шкалі.

#### Чому `==` може дати хибний результат:

1. Два `time.Time` можуть представляти той самий інстант, але мати різні
   location-представлення.
2. Внутрішні службові дані можуть відрізнятися, хоча календарний момент однаковий.
3. Отже, `t1 == t2` може бути `false`, навіть коли часовий момент еквівалентний.

#### Що робить `.Equal()`:

1. Порівнює саме часовий інстант (семантику моменту), а не внутрішню
   репрезентацію структури.
2. Це правильна бізнес-логічна перевірка «чи це той самий час?».

#### Коли `==` усе ж доречний:

1. Для перевірки на нульове значення:
   `t == (time.Time{})`.
2. Для кейсів, де справді потрібно порівняти повну структурну тотожність, а не
   лише інстант.

#### Практичний висновок:

У прикладній логіці часу використовуйте `.Equal()`. Оператор `==` для `time.Time`
легко породжує помилки, бо порівнює більше, ніж зазвичай мається на увазі при
перевірці еквівалентності моментів.

</details>

<details>
<summary>94. Як працюють індекси? Як обирати індекси для таблиць?</summary>

#### Go

Індекс у СУБД — це допоміжна структура даних (найчастіше B-tree-подібна), яка
прискорює пошук рядків за певними полями без повного сканування таблиці.
Фактично індекс зберігає впорядковане представлення ключів і посилання на рядки.

#### Як індекси працюють:

1. Запит із `WHERE/JOIN/ORDER BY` може використати індекс, щоб швидко знайти
   релевантний діапазон ключів.
2. Замість `Seq Scan` (повного читання таблиці) оптимізатор обирає
   `Index Scan/Bitmap Scan`, якщо це вигідно.
3. Індекси також можуть підтримувати унікальність (`UNIQUE`).

#### Ціна індексів:

1. Кожен індекс займає дисковий простір.
2. `INSERT/UPDATE/DELETE` стають дорожчими, бо потрібно оновлювати індекси.
3. Надлишкові індекси сповільнюють запис і ускладнюють підтримку.

#### Як обирати індекси правильно:

1. **Відштовхуватися від реальних запитів**, а не «про всяк випадок».
2. Індексувати поля, що часто стоять у:
- `WHERE`
- `JOIN ON`
- `ORDER BY`
- `GROUP BY` (за потреби)

3. Для composite-індексів враховувати порядок колонок (leftmost-prefix правило):
- найселективніші/найчастіші умови — на початку.

4. Дивитися `EXPLAIN (ANALYZE, BUFFERS)` і підтверджувати, що індекс реально
   використовується й дає виграш.

5. Регулярно переглядати неефективні/невикористовувані індекси.

#### Практичний підхід:

1. Визначити топ повільних запитів.
2. Додати мінімально потрібні індекси.
3. Перевірити plan до/після.
4. Виміряти вплив на read/write баланс під реальним навантаженням.

#### Висновок:

Індекс — це інструмент прискорення читання ціною дорожчого запису. Правильний
вибір індексів завжди query-driven: тільки під конкретні шаблони доступу й лише
після план- та performance-валідації.

#### Приклад:

```sql
-- Перевіряємо план до індексу
EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM orders
WHERE tenant_id = 42
  AND created_at >= now() - interval '7 days'
ORDER BY created_at DESC
LIMIT 100;

-- Додаємо індекс під реальний патерн запиту
CREATE INDEX CONCURRENTLY idx_orders_tenant_created_at
  ON orders (tenant_id, created_at DESC);
```

</details>

<details>
<summary>95. Що таке Materialized View і чим він відрізняється від звичайного View?</summary>

#### Go

`View` і `Materialized View` обидва представляють збережений запит, але
принципово відрізняються способом зберігання результату та вартістю читання.

#### Звичайний `View`:

1. Це логічна «віртуальна таблиця» на основі SQL-запиту.
2. Дані фізично не зберігаються окремо.
3. Кожен запит до view фактично виконує базовий SQL наново.

#### `Materialized View`:

1. Це фізично збережений результат запиту.
2. Читання зазвичай значно швидше, бо не треба щоразу перераховувати складні
   join/aggregate.
3. Дані можуть бути застарілими до моменту `REFRESH`.

#### Ключова різниця:

1. `View` = завжди актуальні дані, але вища вартість обчислення.
2. `Materialized View` = швидке читання, але компроміс щодо свіжості даних.

#### Коли обирати `Materialized View`:

1. Важкі аналітичні запити й агрегації.
2. Часто читані звіти з рідшими оновленнями.
3. Сценарії, де допустима контрольована затримка актуальності.

#### Коли достатньо звичайного `View`:

1. Потрібні максимально актуальні дані в реальному часі.
2. Запит не надто дорогий.
3. `View` використовується як логічна абстракція доступу, а не як кеш.

#### Практичний висновок:

`Materialized View` — це по суті керований кеш результату SQL із явним
оновленням; звичайний `View` — це чиста логічна проєкція без зберігання даних.
Вибір між ними — баланс між свіжістю та швидкодією.

#### Приклад:

```sql
CREATE MATERIALIZED VIEW mv_daily_sales AS
SELECT date_trunc('day', created_at) AS day,
       sum(amount) AS total
FROM payments
GROUP BY 1;

-- Оновлення знімка даних
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_daily_sales;
```

</details>

<details>
<summary>96. Що таке ACID? Прокоментуйте, як ACID реалізований у PostgreSQL.</summary>

#### Go

`ACID` — це чотири базові властивості транзакційних систем, що гарантують
коректність даних навіть за збоїв, конкуренції та високого навантаження:
Atomicity, Consistency, Isolation, Durability.

#### Розшифрування ACID:

1. **Atomicity (атомарність):**
   транзакція виконується або повністю, або не виконується зовсім.

2. **Consistency (узгодженість):**
   після коміту дані залишаються валідними відносно визначених правил і
   обмежень.

3. **Isolation (ізоляція):**
   паралельні транзакції не повинні некоректно впливати одна на одну.

4. **Durability (довговічність):**
   підтверджені зміни зберігаються навіть після збою процесу/системи.

#### Як PostgreSQL реалізує ACID:

1. **Atomicity:**
- транзакційний журнал змін + механізми rollback;
- у разі помилки всі зміни транзакції відкотяться як єдине ціле.

2. **Consistency:**
- обмеження (`PRIMARY KEY`, `UNIQUE`, `CHECK`, `FOREIGN KEY`) і тригери;
- коміт можливий лише якщо інваріанти не порушені.

3. **Isolation:**
- MVCC (Multi-Version Concurrency Control): читачі бачать узгоджені версії
  рядків без грубого блокування читань;
- підтримка рівнів ізоляції (`Read Committed`, `Repeatable Read`,
  `Serializable`) з різним балансом продуктивності й строгості.

4. **Durability:**
- WAL (Write-Ahead Logging): перед комітом зміни спочатку фіксуються в журналі;
- після збою відновлення відбувається за WAL, що зберігає committed-стан.

#### Практичний висновок:

У PostgreSQL ACID забезпечується не «однією кнопкою», а комбінацією MVCC,
WAL, транзакційного менеджера, блокувань та constraint-механізмів. Саме це
робить PostgreSQL надійною СУБД для критичних транзакційних систем.

#### Приклад:

```sql
BEGIN;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

COMMIT; -- або ROLLBACK при помилці
```

</details>

<details>
<summary>97. Яка різниця між BASE та ACID?</summary>

#### Go

`ACID` і `BASE` — це дві різні філософії консистентності та надійності в
розподілених/транзакційних системах. Вони відображають різні архітектурні
пріоритети: строгість і миттєву узгодженість проти доступності та масштабування.

#### ACID:

1. **Atomicity, Consistency, Isolation, Durability**.
2. Орієнтований на строгі транзакційні гарантії.
3. Перевага — передбачувана коректність даних після кожного коміту.
4. Типово застосовується в фінансових, облікових, критично консистентних
   сценаріях.

#### BASE:

1. **Basically Available, Soft state, Eventual consistency**.
2. Орієнтований на високу доступність і горизонтальне масштабування.
3. Допускає тимчасову неузгодженість між вузлами.
4. Консистентність досягається «з часом», а не обов'язково миттєво.

#### Ключова різниця:

1. **ACID**: «краще зачекати, але зберегти строгі гарантії».
2. **BASE**: «краще відповідати швидко й бути доступними, навіть якщо узгодженість
   не миттєва».

#### Практичні наслідки для архітектури:

1. ACID спрощує reasoning про інваріанти, але може коштувати дорожче за
   latency/масштабування в розподілених умовах.
2. BASE дає стійкість і доступність на великих масштабах, але вимагає
   компенсаційних механізмів, ідемпотентності та продуманого доменного дизайну.

#### Висновок:

ACID і BASE — не «добре/погано», а різні компроміси. Вибір залежить від того,
що критичніше для системи: негайна строгість інваріантів чи доступність і
масштабування за ціни eventual consistency.

</details>

<details>
<summary>98. Назвіть рівні ізоляції транзакцій.</summary>

#### Go

Рівні ізоляції визначають, наскільки «видимими» є зміни паралельних транзакцій
одна для одної. Чим вищий рівень ізоляції, тим менше аномалій, але зазвичай
вища ціна в продуктивності та конкурентності.

#### Класичні рівні ізоляції (SQL):

1. **Read Uncommitted**
- найслабший рівень;
- допускає читання незафіксованих змін (dirty read).

2. **Read Committed**
- читаються лише committed-дані;
- dirty read заборонено;
- можливі non-repeatable read і phantom read.

3. **Repeatable Read**
- повторне читання тих самих рядків у межах транзакції дає той самий результат;
- зменшує частину аномалій, але залежно від СУБД можуть лишатися phantom-сценарії.

4. **Serializable**
- найсуворіший рівень;
- гарантує результат, еквівалентний послідовному виконанню транзакцій;
- максимальний захист від аномалій, але дорожчий за конкуренцією.

#### Практичний висновок:

Вибір рівня ізоляції — це баланс коректності й продуктивності. У продакшні його
визначають від доменних інваріантів: де достатньо `Read Committed`, а де
потрібен `Repeatable Read` або `Serializable`.

#### Приклад:

```sql
BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SELECT balance FROM accounts WHERE id = 1;
-- ... інші операції в межах тієї ж транзакції

COMMIT;
```

</details>

<details>
<summary>99. Для чого потрібні графові бази даних?</summary>

#### Go

Графові бази даних потрібні там, де головна цінність — не окремі записи, а
зв'язки між ними та швидкий обхід багатокрокових відношень.

#### Що моделює графова БД:

1. **Вузли (nodes)** — сутності.
2. **Ребра (edges)** — відношення між сутностями.
3. **Властивості** вузлів і ребер — атрибути доменної моделі.

#### Для яких задач вони особливо корисні:

1. **Соціальні графи:** друзі, підписки, рекомендації.
2. **Fraud detection:** нетривіальні ланцюжки транзакцій і підозрілих зв'язків.
3. **Knowledge graph / семантичний пошук:** зв'язане представлення знань.
4. **Network/IT topology:** залежності сервісів, маршрути, вплив інцидентів.
5. **Role/permission моделі:** складні політики доступу з наслідуванням ролей.

#### Чому не завжди достатньо реляційної БД:

1. У багатокрокових join-сценаріях запити можуть ставати важкими й громіздкими.
2. Графовий рушій оптимізований саме під traversal-path запити.
3. Модель «зв'язки як сутність першого класу» робить складні relationship-кейси
   природнішими.

#### Коли графова БД не обов'язкова:

1. Якщо зв'язки прості й рідко запитуються глибоко.
2. Якщо домінують класичні CRUD/OLTP-сценарії без складних traversal.
3. Якщо команда й інфраструктура вже ефективно працюють із реляційним стеком.

#### Висновок:

Графові БД потрібні тоді, коли бізнес-цінність лежить у структурі зв'язків і
багатокроковій навігації по них. Це спеціалізований інструмент для relationship-
centric доменів, де join-орієнтований підхід стає неефективним або надто складним.

</details>

<details>
<summary>100. Якщо дані прив'язані до часу, які бази даних варто використовувати?</summary>

#### Go

Якщо дані мають виразну часову природу (метрики, логи, події, телеметрія),
доцільно обирати СУБД за профілем навантаження: частота запису, тип запитів,
період зберігання, вимоги до агрегацій і latency.

#### Типові варіанти:

1. **Time-series DB (TSDB)**
- приклади: Prometheus (для метрик), VictoriaMetrics, InfluxDB, TimescaleDB;
- сильні сторони: висока швидкість ingestion, запити за часовими вікнами,
  downsampling/retention-політики.

2. **PostgreSQL + time-oriented підхід**
- коли потрібні транзакційність, SQL-екосистема й складні join-запити разом із
  часовими даними;
- часто комбінується з партиціюванням за часом.

3. **Columnar OLAP-сховища**
- для аналітики великих обсягів історичних подій (ClickHouse тощо);
- сильні в агрегатах і скануванні великих часових діапазонів.

#### Критерії вибору:

1. **Write-heavy telemetry** → TSDB.
2. **Операційні транзакції + час** → PostgreSQL (з партиціюванням/індексами).
3. **Масштабна історична аналітика** → columnar/OLAP-підхід.
4. **Retention і cost-модель**: гарячі дані в швидкому шарі, холодні — в
   дешевшому сховищі.

#### Практичний висновок:

Для time-bound даних «універсальної» БД немає: оптимальною є комбінація
інструментів під конкретний workload. У більшості систем працює стратегія
гарячий TSDB/OLTP-шар + окремий аналітичний шар для довгої історії.

</details>

<details>
<summary>101. Як працює master-slave реплікація?</summary>

#### Go

Master-slave (primary-replica) реплікація — це модель, у якій один вузол
приймає записи, а один або кілька вузлів-реплік відтворюють ці зміни для
масштабування читання, резервування та підвищення відмовостійкості.

#### Базовий принцип:

1. **Master (primary)** обробляє `INSERT/UPDATE/DELETE`.
2. Зміни фіксуються в журналі транзакцій (WAL/binlog залежно від СУБД).
3. **Slave (replica)** читає журнал і застосовує зміни у своїй копії даних.
4. Читання часто розносять на репліки, записи лишають на primary.

#### Режими реплікації:

1. **Асинхронна**
- primary не чекає підтвердження від replica перед комітом;
- нижча latency запису;
- можливе replication lag і тимчасова неузгодженість.

2. **Синхронна/квазі-синхронна**
- primary частково або повністю чекає підтвердження реплік;
- вища узгодженість;
- потенційно більша затримка запису.

#### Що це дає:

1. Масштабування read-навантаження.
2. Резервні копії даних для failover.
3. Розділення OLTP-записів і heavy-read сценаріїв.

#### Типові ризики:

1. **Replication lag** (читач може бачити «старі» дані).
2. Складність failover/failback і ролей вузлів.
3. Ризик split-brain у некоректно організованих сценаріях переключення.

#### Практичний висновок:

Master-slave реплікація — це баланс між доступністю, масштабуванням і
консистентністю. Вона ефективна для read-scaling, але потребує дисципліни
моніторингу lag, продуманого failover і чіткої політики маршрутизації запитів.

</details>

<details>
<summary>102. Що таке шардинг і які його види?</summary>

#### Go

Шардинг — це горизонтальне розбиття даних на кілька незалежних вузлів (shard-ів),
щоб масштабувати систему за межі одного сервера за обсягом даних, навантаженням
і пропускною здатністю.

#### Навіщо застосовують шардинг:

1. Зняти обмеження одного вузла (CPU/RAM/диск/I/O).
2. Підвищити write/read throughput через паралельну роботу шард.
3. Локалізувати «гарячі» набори даних і зменшити конкуренцію за ресурси.

#### Основні види шардингу:

1. **Range-based sharding**
- дані діляться за діапазонами ключа (наприклад, за датою або ID-інтервалом);
- простий для time-series сценаріїв;
- ризик «гарячих» діапазонів.

2. **Hash-based sharding**
- shard визначається хешем ключа;
- рівномірніше розподіляє навантаження;
- складніше робити range-запити.

3. **Directory / Lookup-based sharding**
- окрема таблиця/сервіс мапить ключ → shard;
- гнучка маршрутизація і міграції;
- додаткова складність і залежність від lookup-шару.

4. **Geo / Tenant-based sharding**
- дані діляться за регіоном або клієнтом (tenant);
- добре для ізоляції, комплаєнсу і multi-tenant архітектур;
- можливий дисбаланс між shard-ами.

#### Архітектурні виклики шардингу:

1. Ребалансування даних під час росту.
2. Крос-шард запити, join-и й транзакції.
3. Ускладнення backup/restore і failover.
4. Підвищена складність observability та операційної підтримки.

#### Висновок:

Шардинг — це інструмент масштабування, який дає значний виграш у продуктивності,
але ціною архітектурної складності. Вибір типу шардингу має спиратися на патерн
доступу до даних, доменну модель і план еволюції системи.

#### Приклад:

```go
func shardForUser(userID int64, shards int) int {
	if shards <= 0 {
		return 0
	}
	return int(userID % int64(shards)) // hash/range-логіку змінюють під домен
}
```

</details>

<details>
<summary>103. Розкажіть про ваш досвід оптимізації бази даних. Які інструменти використовували?</summary>

#### Go

Для співбесіди це питання зазвичай очікує **структуровану кейс-розповідь**:
контекст → проблема → дії → інструменти → метрики «до/після». Нижче — зразок
сильної відповіді, який можна адаптувати під власний реальний досвід.

#### Приклад:

1. **Контекст**
- у сервісі з високим read/write-навантаженням спостерігали деградацію p95/p99
  latency в пікові години.

2. **Симптоми**
- повільні запити;
- ріст CPU на БД-вузлі;
- збільшення lock wait і черг запитів.

3. **Що зробили**
- зібрали топ повільних запитів;
- проаналізували execution plans;
- додали/перебудували індекси під реальні `WHERE/JOIN/ORDER BY`;
- усунули N+1 і перевели частину важких операцій у batch;
- для гарячих read-кейсів додали кешування;
- оптимізували схему (типи полів, партиціювання за часом, архівацію старих
  даних).

4. **Інструменти**
- `EXPLAIN (ANALYZE, BUFFERS)` / `EXPLAIN ANALYZE`;
- статистика запитів (`pg_stat_statements` або аналог);
- профайлінг застосунку (`pprof`) для відділення DB-bottleneck від app-layer;
- метрики й дашборди (Prometheus/Grafana);
- навантажувальні тести до/після змін.

5. **Результат (приклад формулювання)**
- p95 зменшили умовно на 40–60%;
- throughput зріс без додаткових DB-вузлів;
- стабілізували пікові періоди й знизили lock-contention.

#### Як відповідати найпереконливіше:

1. Говорити мовою вимірювань, а не загальних фраз.
2. Пояснювати trade-off: що прискорили і якою ціною.
3. Підкреслювати відтворюваний процес: «спочатку виміряли, потім змінили, потім
   перевірили».

#### Висновок:

Сильна відповідь про оптимізацію БД — це доказовий інженерний кейс із
метриками та інструментами. Саме така структура демонструє зрілість і
практичну компетентність.

</details>

<details>
<summary>104. Як `pgx` відрізняється від `lib/pq` щодо продуктивності та функціональності?</summary>

#### Go

`lib/pq` і `pgx` — обидва працюють із PostgreSQL, але належать до різних поколінь
Go-екосистеми. У сучасних продакшн-сценаріях `pgx` зазвичай вважають
практичнішим вибором.

#### Головна різниця:

1. **`lib/pq`**
- класичний драйвер для `database/sql`;
- стабільний, але функціонально консервативний;
- менше сучасних оптимізацій і PostgreSQL-специфічних можливостей.

2. **`pgx`**
- сучасний драйвер/інструментарій для PostgreSQL;
- може працювати і як native API, і через `database/sql`-сумісний шар;
- багатший набір фіч і часто краща продуктивність у реальному навантаженні.

#### Продуктивність:

1. `pgx` нерідко показує кращий throughput і lower latency, особливо в
   high-load сценаріях.
2. Причини: ефективніша робота з протоколом PostgreSQL, кращі можливості
   батчингу/копіювання, гнучкіша робота з типами.
3. Остаточний висновок завжди роблять бенчмарком вашого workload.

#### Функціональність:

1. `pgx` надає ширший доступ до PostgreSQL-специфіки:
- розширена типова система;
- batch/Copy-примітиви;
- тонший контроль поведінки з'єднань і запитів.

2. `lib/pq` здебільшого лишається «мінімально достатнім» драйвером для базових
   задач через `database/sql`.

#### Коли що обирати:

1. **`pgx`** — для нових проєктів, високого навантаження, потреби в сучасних
   PostgreSQL-фічах і кращому контролі.
2. **`lib/pq`** — переважно legacy-код, де міграція поки не виправдана.

#### Висновок:

`pgx` зазвичай виграє і за функціональністю, і за потенціалом продуктивності.
`lib/pq` історично важливий, але для більшості нових Go/PostgreSQL систем
переважним вибором є саме `pgx`.

</details>

<details>
<summary>105. Як писати unit-тести в Go?</summary>

#### Go

Unit-тест у Go перевіряє невелику ізольовану одиницю поведінки (функцію/метод)
з чіткими вхідними даними й очікуваним результатом. Сила підходу — у
детермінованості, швидкості та прозорості причин падіння.

#### Базові принципи якісного unit-тесту:

1. **Одна поведінка — один тестовий намір.**
2. **Ізоляція від зовнішніх систем** (БД, мережа, час, файлова система).
3. **Детермінованість**: однакові умови мають давати однаковий результат.
4. **Читабельність і діагностичність** повідомлень про помилки.

#### Ідіоматична структура в Go:

1. Файл `*_test.go`.
2. Функції вигляду `func TestXxx(t *testing.T)`.
3. Патерн Arrange → Act → Assert.
4. Для множинних кейсів — table-driven tests.

#### Що обов'язково покривати:

1. Позитивні сценарії (happy path).
2. Негативні сценарії та помилки.
3. Граничні випадки (порожні дані, нулі, великі значення, некоректний ввід).
4. Інваріанти, які не мають порушуватися за жодних умов.

#### Практичні інструменти:

1. Стандартний пакет `testing`.
2. `go test ./...` для регулярного прогону.
3. `-race` для конкурентних ділянок.
4. За потреби — `testify` (assert/require), але без надмірної магії.

#### Типові помилки:

1. Тести, що залежать від часу/мережі/порядку запуску.
2. Перевірка лише «без panic», без змістових assertions.
3. Надто великі інтеграційні сценарії під виглядом unit-тестів.

#### Висновок:

Писати unit-тести в Go — означає проєктувати перевірювану поведінку:
мінімальний обсяг, чіткий контракт, ізоляція від зовнішнього світу і надійні
assertions. Саме такий підхід забезпечує швидкий і стійкий регресійний захист.

#### Приклад:

```go
func TestSum(t *testing.T) {
	tests := []struct {
		name string
		a, b int
		want int
	}{
		{"pos", 2, 3, 5},
		{"zero", 0, 7, 7},
	}

for _, tc := range tests {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			got := Sum(tc.a, tc.b)
			if got != tc.want {
				t.Fatalf("got %d, want %d", got, tc.want)
			}
		})
	}
}
```

</details>

<details>
<summary>106. Яка різниця між `t.Error` і `t.Fatal` у тестах?</summary>

#### Go

`t.Error` і `t.Fatal` обидва позначають тест як невдалий, але мають різну
поведінку щодо продовження виконання.

#### `t.Error`:

1. Логує помилку і позначає тест як failed.
2. **Не зупиняє** виконання поточного тесту.
3. Підходить, коли хочемо зібрати кілька незалежних перевірок в одному прогоні.

#### `t.Fatal`:

1. Логує помилку і позначає тест як failed.
2. **Негайно зупиняє** поточний тест (`FailNow`).
3. Підходить, коли без цієї передумови подальші перевірки не мають сенсу або
   можуть спричинити шум/паніку.

#### Практичне правило:

1. Використовуйте `t.Fatal`, якщо зламана базова передумова (наприклад, не
   вдалося створити тестовий об'єкт, отримали `nil` там, де далі йде dereference).
2. Використовуйте `t.Error`, якщо хочете перевірити кілька незалежних
   постумов і побачити всі відхилення одразу.

#### Висновок:

Різниця проста й принципова: `t.Error` — «зафіксувати і продовжити»,
`t.Fatal` — «зафіксувати і негайно зупинити». Вибір залежить від того, чи
залишається тест осмисленим після конкретної помилки.

</details>

<details>
<summary>107. Як `testify/assert` відрізняється від `testify/require` семантично?</summary>

#### Go

Семантична різниця між `assert` і `require` така сама, як між `t.Error` і
`t.Fatal` у стандартному `testing`: один дозволяє тесту йти далі, інший
зупиняє його негайно.

#### `testify/assert`:

1. При невдалому твердженні позначає тест як failed.
2. **Не перериває** виконання поточного тесту.
3. Корисний, коли хочете зібрати кілька незалежних невідповідностей за один
   прогін.

#### `testify/require`:

1. При невдалому твердженні позначає тест як failed.
2. **Негайно зупиняє** поточний тест (fail now).
3. Потрібний для перевірок-передумов, без яких наступні кроки некоректні.

#### Коли що обирати:

1. `require` — для критичних preconditions:
- об'єкт не `nil`;
- помилка відсутня перед подальшими діями;
- вхідні дані підготовлені коректно.

2. `assert` — для постумов і незалежних перевірок результату.

#### Практичний висновок:

`require` керує життєвим циклом тесту, `assert` — деталізацією діагностики.
Добрий тест зазвичай поєднує обидва: `require` для «стоп-умов», `assert` для
подальшого змістового контролю.

</details>

<details>
<summary>108. Як `t.Run` дозволяє запускати підтести і фільтрувати їх?</summary>

#### Go

`t.Run` дає змогу структурувати один тест у набір підтестів (subtests) із
іменами. Кожен підкейс виконується як окрема логічна одиниця, що спрощує
табличні тести, діагностику й вибірковий запуск.

#### Як працює `t.Run`:

1. У головному тесті викликають `t.Run(name, func(t *testing.T) { ... })`.
2. Кожен виклик створює окремий підтест із власним `t`.
3. Підтести можуть мати різні вхідні дані, асерти й налаштування.

#### Чому це зручно:

1. **Краща читабельність table-driven tests.**
2. **Точна діагностика:** видно, який саме кейс упав.
3. **Ієрархія тестів:** можна вкладати `t.Run` для групування сценаріїв.
4. **Контроль паралельності:** окремі підкейси можна запускати через
   `t.Parallel()`.

#### Як працює фільтрація:

1. `go test -run <pattern>` запускає тести, імена яких збігаються з патерном.
2. Для підтестів враховується шлях імен (наприклад, `TestXxx/case_name`).
3. Це дозволяє точково запускати один проблемний кейс без повного набору.

#### Практичний приклад мислення:

1. `TestParser` містить десятки кейсів через `t.Run`.
2. Під час дебагу запускають лише один:
   `go test -run 'TestParser/invalid_header'`.
3. Отримують швидкий feedback-loop і чистіший цикл виправлення.

#### Висновок:

`t.Run` перетворює монолітні тести на керовану систему підтестів із
гранулярним запуском і фільтрацією. Це один із ключових інструментів
підтримуваного тестового дизайну в Go.

</details>

<details>
<summary>109. Як тестувати HTTP-handlers?</summary>

#### Go

HTTP-handler-и в Go тестують ізольовано, без реального мережевого сокета, за
допомогою `httptest`. Мета — перевірити контракт HTTP-рівня: статус, заголовки,
тіло відповіді, обробку помилок і граничні сценарії.

#### Канонічний підхід:

1. Створити запит через `httptest.NewRequest(...)`.
2. Створити recorder через `httptest.NewRecorder()`.
3. Викликати handler: `handler.ServeHTTP(rec, req)`.
4. Перевірити:
- `rec.Code` (status code);
- headers;
- body (JSON/schema/повідомлення).

#### Що обов'язково покривати:

1. **Happy path** (коректний запит, очікувана відповідь).
2. **Валідаційні помилки** (неповний/некоректний payload, query params).
3. **Методи HTTP** (GET/POST/PUT/DELETE + 405, якщо метод не дозволений).
4. **Помилки залежностей** (сервіс/репозиторій повертає error).
5. **Контекстні сценарії** (timeout/cancel, якщо логіка це підтримує).

#### Архітектурні поради:

1. Виносити бізнес-логіку з handler у сервісний шар.
2. У handler-тестах мокати/фейкати залежності сервісу.
3. Тестувати саме HTTP-контракт, а не внутрішню реалізацію.

#### Практичний мінімум перевірок:

1. Коректний `Content-Type`.
2. Структура JSON-відповіді.
3. Відповідність статус-кодів доменним помилкам.
4. Відсутність витоку чутливої інформації в error-body.

#### Висновок:

Тест HTTP-handler у Go — це перевірка поведінки endpoint-а як чорної скриньки:
вхідний запит → чіткий HTTP-вихід. `httptest` дає швидкий, детермінований і
достатньо точний інструмент для такого контрактного тестування.

#### Приклад:

```go
req := httptest.NewRequest(http.MethodGet, "/health", nil)
rec := httptest.NewRecorder()

handler.ServeHTTP(rec, req)

if rec.Code != http.StatusOK {
	t.Fatalf("status=%d", rec.Code)
}
```

</details>

<details>
<summary>110. Як тестувати помилки?</summary>

#### Go

Тестування помилок у Go має перевіряти не лише факт «помилка є», а й її
семантику: тип, категорію, ланцюжок обгортань і очікувану реакцію системи.

#### Що саме перевіряти:

1. **Наявність/відсутність помилки** в конкретному сценарії.
2. **Категорію помилки** через `errors.Is` (sentinel-помилки).
3. **Тип помилки** через `errors.As` (custom error type з полями).
4. **Контекст обгортки** (чи не втрачено кореневу причину при `%w`).
5. **Поведінковий ефект**: правильний статус-код, retry/no-retry, rollback тощо.

#### Рекомендовані практики:

1. Уникати крихких перевірок повного тексту `err.Error()`.
2. Для стабільних контрактів використовувати `errors.Is/As`, а не `==` для
   wrapped-помилок.
3. У table-driven тестах явно вказувати очікуваний клас помилки та наслідок.

#### Що тестувати в негативних сценаріях:

1. Помилки валідації вхідних даних.
2. Помилки зовнішніх залежностей (БД, HTTP, черги).
3. Таймаути/скасування через `context`.
4. Граничні стани (порожні значення, некоректні формати, перевищені ліміти).

#### Архітектурний акцент:

1. Помилка має бути частиною API-контракту функції.
2. Тести повинні доводити, що обробка помилок детермінована й передбачувана.
3. Якщо система мапить доменні помилки на transport-рівень, тестуйте це
   відображення окремо.

#### Висновок:

Якісне тестування помилок у Go — це перевірка семантики, а не рядка повідомлення.
Саме така перевірка робить код стійким до рефакторингу й надійним у продакшні.

</details>

<details>
<summary>111. Як мокати зовнішні залежності без використання сторонніх фреймворків?</summary>

#### Go

У Go зовнішні залежності найчистіше мокають через інтерфейси і власні
test-double реалізації (stub/fake/spy), без потреби у важких mocking-фреймворках.
Це ідіоматичний підхід, який добре масштабується і лишається прозорим.

#### Базова схема:

1. Виділити мінімальний інтерфейс залежності в шарі споживача.
2. Продакшн-реалізація працює з реальною БД/HTTP/чергою.
3. У тесті підставити власну структуру, що реалізує той самий інтерфейс.

#### Типи test-double без сторонніх бібліотек:

1. **Stub** — повертає заздалегідь задані дані.
2. **Fake** — спрощена «робоча» реалізація (наприклад, in-memory repo).
3. **Spy** — фіксує виклики (аргументи, кількість, порядок).
4. **Manual mock** — керований сценарій із налаштовуваними відповідями/помилками.

#### Переваги такого підходу:

1. Повна типобезпечність компілятора.
2. Нульова магія runtime.
3. Краща читабельність тестів і передбачувана еволюція коду.
4. Відсутність зовнішніх залежностей у тестовому стеку.

#### Практичні рекомендації:

1. Робити інтерфейси малими (за поведінкою, а не «на всі методи»).
2. Мокати на межі модуля, а не всередині доменної логіки.
3. Для конкурентних сценаріїв захищати state test-double (`mutex`, атоміки).
4. Не дублювати продакшн-логіку в fake надмірно — інакше тести стають крихкими.

#### Висновок:

Мокання без фреймворків у Go — це насамперед про хороший дизайн залежностей:
малий інтерфейс + ручний test-double. Такий підхід простий, надійний і
архітектурно здоровий для довготривалої підтримки проєкту.

</details>

<details>
<summary>112. Як використовувати `TestMain` для налаштування тестового оточення?</summary>

#### Go

`TestMain(m *testing.M)` — це точка входу для всього тестового пакета. Вона
дозволяє виконати глобальну ініціалізацію перед тестами й гарантований cleanup
після них.

#### Коли `TestMain` доречний:

1. Потрібно один раз підняти спільне тестове оточення:
- тестову БД/контейнер;
- тимчасові директорії;
- глобальні конфігурації/секрети;
- фонові сервісні залежності.

2. Потрібен централізований teardown після завершення всіх тестів пакета.

#### Базовий життєвий цикл:

1. Виконується setup (ініціалізація ресурсів).
2. Запускаються тести через `code := m.Run()`.
3. Виконується cleanup.
4. Процес завершується через `os.Exit(code)`.

#### Важливі правила:

1. `m.Run()` має бути викликаний рівно один раз.
2. Повернений код треба передати в `os.Exit`, інакше статус тестів загубиться.
3. Cleanup має виконуватися навіть у разі помилок setup (наскільки це можливо).
4. Не робити в `TestMain` зайвої логіки, не пов'язаної з оточенням.

#### Практичні поради:

1. Для ізоляції тестів у межах пакета не покладатися лише на `TestMain` —
   локальний setup/teardown у конкретних тестах часто все одно потрібен.
2. Якщо можна, віддавайте перевагу легшим механізмам (`t.Cleanup`) на рівні
   тесту; `TestMain` використовуйте для справді пакетного контексту.
3. У паралельних тестах уважно контролюйте shared state, ініціалізований у
   `TestMain`.

#### Висновок:

`TestMain` — інструмент пакетного orchestration тестового середовища: один setup,
один запуск усіх тестів, один cleanup. Він доречний там, де потрібен контроль
життєвого циклу спільних ресурсів для всього пакета.

</details>

<details>
<summary>113. Як використовувати golden files?</summary>

#### Go

`Golden files` — це еталонні файли з очікуваним результатом, з якими тест
порівнює фактичний output. Підхід особливо корисний для форматерів, генераторів
коду, серіалізації та будь-якого текстового/структурного виводу.

#### Базовий workflow:

1. Згенерувати результат тестованою функцією.
2. Прочитати відповідний `.golden` файл.
3. Порівняти фактичний output з еталоном.
4. У разі різниці тест падає з дифом.

#### Типова структура:

1. Тестові вхідні дані (`testdata/input/...`).
2. Еталони (`testdata/golden/...`).
3. Table-driven тести, де кожен кейс має свій golden-файл.

#### Дуже корисна практика — режим оновлення:

1. Додати прапорець на кшталт `-update`.
2. Якщо він увімкнений, тест перезаписує golden-файли новим результатом.
3. Це пришвидшує підтримку еталонів при легітимній зміні поведінки.

#### На що звертати увагу:

1. **Детермінізм output:** перед порівнянням нормалізувати порядок даних,
   timestamps, випадкові значення.
2. **Якісний diff:** у падінні тесту має бути зрозуміло, що саме змінилося.
3. **Не зловживати:** golden-файли для великих «чорних ящиків» без семантичних
   перевірок можуть ускладнити діагностику.

#### Коли golden-файли найдоречніші:

1. Рендеринг/генерація тексту.
2. Трансформація JSON/XML/конфігів.
3. CLI-output.
4. Компілятори, парсери, кодогенератори.

#### Висновок:

Golden files — практичний інструмент контрактного тестування output-у.
За умови детермінізму та зручного update-процесу вони дають швидкий і наочний
захист від небажаних регресій у форматі результату.

</details>

<details>
<summary>114. Як правильно тестувати Go-код, що використовує `time.Now()`, щоб тести були детермінованими?</summary>

#### Go

`time.Now()` робить тести недетермінованими, бо повертає реальний поточний час.
Щоб тести були стабільними, час потрібно інжектувати, а не читати напряму всередині
бізнес-логіки.

#### Канонічний підхід:

1. Винести джерело часу в залежність:
- функція `now func() time.Time`;
- інтерфейс `Clock` із методом `Now()`.

2. У продакшні передавати реальний годинник (`time.Now`).
3. У тесті передавати фіксований час (fake clock).

#### Чому це працює:

1. Результат не залежить від моменту запуску тесту.
2. Зникають flaky-сценарії «інколи падає, інколи ні».
3. Легко перевіряти edge-cases: дедлайни, TTL, перехід дат, часові зони.

#### Додаткові практики:

1. Не порівнювати часові значення з «жорсткою» мілісекундною точністю, якщо це
   не вимога домену.
2. Для тестів із таймерами/ретраями використовувати контрольований clock або
   достатні буфери часу.
3. Фіксувати `Location/UTC` явно, щоб уникнути залежності від оточення.

#### Що не варто робити:

1. Лишати `time.Now()` у глибині доменної логіки без можливості підміни.
2. Рятуватися `time.Sleep`-ами в тестах — це уповільнює й не гарантує
   стабільності.

#### Висновок:

Детерміноване тестування часу в Go будується на інверсії залежності:
час — це вхід, а не глобальний side effect. Інжекція clock-джерела робить тести
швидкими, відтворюваними й архітектурно чистими.

</details>

<details>
<summary>115. Як `t.Parallel()` прискорює набір тестів і де він може їх зламати?</summary>

#### Go

`t.Parallel()` дозволяє тестам (або підтестам) виконуватися конкурентно, що
зазвичай скорочує загальний час прогону на багатоядерних середовищах. Але
паралельність без ізоляції легко перетворює стабільні тести на flaky.

#### Як це прискорює прогони:

1. Незалежні тести виконуються одночасно.
2. Краще використовується CPU та I/O-очікування.
3. Великий набір дрібних тестів проходить значно швидше в CI.

#### Де `t.Parallel()` може зламати тести:

1. **Shared mutable state:**
   глобальні змінні, спільні in-memory кеші, статичні конфіги без синхронізації.

2. **Спільні зовнішні ресурси:**
   одна БД-схема/таблиця, один порт, один файл, одна директорія тимчасових даних.

3. **Залежність від порядку виконання:**
   якщо тест неявно очікує, що інший уже відпрацював.

4. **Побічні ефекти середовища:**
   зміни env vars, time zone, робочої директорії без ізоляції.

5. **Помилки в table-driven підтестах:**
   захоплення змінної циклу без локальної копії в closure.

#### Як застосовувати безпечно:

1. Паралелити лише тести з повною ізоляцією.
2. Уникати глобального mutable state або захищати його синхронізацією.
3. Використовувати унікальні тимчасові ресурси (`t.TempDir`, окремі fixture-и).
4. Для БД-тестів — транзакційна ізоляція або окремий namespace/схема на тест.
5. Проганяти набір із `-race` для раннього виявлення проблем конкурентності.

#### Висновок:

`t.Parallel()` — потужний прискорювач тестів, але тільки за умови суворої
ізоляції кейсів. Якщо тести мають спільний стан чи приховані залежності, паралельність
викриє ці дефекти й зробить прогін нестабільним.

</details>

<details>
<summary>116. Як виміряти code coverage?</summary>

#### Go

У Go покриття коду вимірюється вбудованими інструментами `go test` через
інструментацію виконання тестів. Це дає метрики, які показують, яка частина
рядків/блоків коду була виконана під час тестового прогону.

#### Базові команди:

1. Загальне покриття по пакету:
   `go test -cover ./...`

2. Збір профілю покриття:
   `go test -coverprofile=coverage.out ./...`

3. Перегляд підсумкової статистики:
   `go tool cover -func=coverage.out`

4. HTML-звіт із підсвічуванням:
   `go tool cover -html=coverage.out`

#### Що важливо розуміти:

1. Coverage показує факт виконання, а не повноту перевірок інваріантів.
2. Високий відсоток не гарантує відсутності багів.
3. Низький відсоток — сигнал про сліпі зони тестування.

#### Практичні поради:

1. Аналізувати coverage разом із критичністю коду, а не гнатися за «100%».
2. Окремо покривати негативні й edge-case сценарії.
3. Використовувати coverage як індикатор прогалин, а не самоціль.
4. У CI зберігати профіль і відстежувати динаміку покриття між PR.

#### Висновок:

Code coverage у Go вимірюється стандартним tooling (`go test` + `go tool cover`)
і є корисною метрикою оглядової якості тестів. Найбільшу цінність вона дає в
поєднанні з семантичними перевірками та осмисленим тест-дизайном.

</details>

<details>
<summary>117. Що таке benchmarking і як його запускати? Як `testing.B` реалізує benchmark і що скидає `b.ResetTimer`?</summary>

#### Go

`Benchmarking` у Go — це вимірювання продуктивності коду (час, алокації,
throughput) у контрольованих умовах, щоб порівнювати реалізації та підтверджувати
ефект оптимізацій.

#### Як запускати benchmark:

1. Функції мають форму:
   `func BenchmarkXxx(b *testing.B)`.

2. Базовий запуск:
   `go test -bench=.`

3. Лише конкретний бенчмарк:
   `go test -bench=BenchmarkParse`

4. Вимір алокацій:
   `go test -bench=. -benchmem`

#### Як працює `testing.B`:

1. Runner сам підбирає `b.N` (кількість ітерацій), щоб отримати стабільний вимір.
2. Ваш код у benchmark-функції виконується в циклі `for i := 0; i < b.N; i++`.
3. У результаті тест ранжує продуктивність у `ns/op`, а з `-benchmem` ще й
   `B/op`, `allocs/op`.

#### Що робить `b.ResetTimer`:

1. Скидає накопичений таймер вимірювання.
2. Не враховує в підсумковому часі код підготовки, виконаний до виклику
   `ResetTimer`.
3. Використовується після setup-фази, щоб міряти лише «чисту» робочу частину.

#### Суміжні корисні методи:

1. `b.StopTimer()` / `b.StartTimer()` — тимчасово виключити/включити облік часу.
2. `b.ReportAllocs()` — примусово виводити статистику алокацій.

#### Практичний висновок:

Benchmark у Go — це не разовий запуск, а інструмент порівняння в однакових
умовах. `testing.B` автоматично масштабує ітерації, а `b.ResetTimer` відділяє
підготовку від реального виміру продуктивності.

#### Приклад:

```go
func BenchmarkParse(b *testing.B) {
	input := []byte(`{"x":1}`)
	b.ResetTimer()

for i := 0; i < b.N; i++ {
		var v map[string]int
		_ = json.Unmarshal(input, &v)
	}
}
```

</details>

<details>
<summary>118. Як запускати бенчмарки з контролем часу та кількості ітерацій?</summary>

#### Go

У Go бенчмарки можна запускати з керуванням тривалістю вимірювання та
фіксованою кількістю ітерацій через параметри `go test`. Це важливо для
відтворюваності й коректного порівняння результатів.

#### Основні прапорці:

1. **`-benchtime`**
- задає тривалість прогону бенчмарку (наприклад, `-benchtime=5s`);
- runner сам підбирає `b.N`, щоб працювати приблизно в цьому часовому вікні.

2. **`-benchtime=Nx`**
- фіксує точну кількість ітерацій (наприклад, `-benchtime=100000x`);
- зручно для відтворюваних A/B порівнянь за однаковим `N`.

3. **`-count`**
- кількість повторних запусків (наприклад, `-count=10`);
- допомагає оцінити стабільність і розкид результатів.

4. **`-bench`**
- вибір конкретних benchmark-функцій за патерном.

5. **`-benchmem`**
- додатково виводить алокації (`B/op`, `allocs/op`).

#### Практичні приклади сценаріїв:

1. Довший стабільний прогін:
   `go test -bench=. -benchtime=5s -benchmem`

2. Фіксований `N`:
   `go test -bench=BenchmarkFoo -benchtime=200000x -benchmem`

3. Кілька повторів для статистики:
   `go test -bench=BenchmarkFoo -benchtime=2s -count=10`

#### Навіщо це потрібно:

1. Зменшити шум коротких прогонів.
2. Порівнювати оптимізації в однакових умовах.
3. Отримувати статистично осмислені дані для `benchstat`-аналізу.

#### Висновок:

Контроль часу й ітерацій у Go-бенчмарках — обов'язкова умова якісного
performance-аналізу. `-benchtime` і `-count` дають стабільність вимірювань, а
`Nx`-режим забезпечує строгий контроль над кількістю виконань.

</details>

<details>
<summary>119. Як інструмент `benchstat` порівнює два набори результатів бенчмарків і як визначає значущість змін?</summary>

#### Go

`benchstat` порівнює два (або більше) набори benchmark-результатів і показує, чи
зміни в метриках (`ns/op`, `B/op`, `allocs/op`) є статистично значущими, а не
випадковим шумом прогону.

#### Як працює порівняння:

1. Збирають кілька прогонів «до» і «після» (зазвичай через `-count`).
2. `benchstat` групує результати за однаковими benchmark-іменами.
3. Обчислює центральні значення (зазвичай медіаноподібні/робастні оцінки) і
   відсоткову різницю.
4. Виконує статистичний тест і виводить `p-value`.

#### Як визначається значущість:

1. Якщо `p-value` нижче порогового рівня (типово 0.05), зміна вважається
   статистично значущою.
2. Якщо `p-value` вище порога, різниця може бути шумом середовища.
3. Тому важливо дивитися **і на delta, і на p-value** одночасно.

#### Що потрібно для коректного аналізу:

1. Однакові умови запуску (машина, навантаження, конфігурація).
2. Достатня кількість повторів (`-count`), інакше висновки крихкі.
3. Відсутність стороннього шуму (фонові процеси, термальний тротлінг, нестабільне
   оточення CI).

#### Практичне правило:

1. Не довіряти разовому `go test -bench`.
2. Збирати серії результатів до/після.
3. Аналізувати через `benchstat`, а потім перевіряти, чи зміна важлива для
   бізнес-метрик (latency/throughput/SLA), а не лише «красива» в таблиці.

#### Висновок:

`benchstat` перетворює сирі benchmark-цифри на статистично обґрунтоване
порівняння. Він допомагає відрізнити реальний performance-ефект від випадкового
розкиду і приймати інженерні рішення на основі даних.

</details>

<details>
<summary>120. Що таке fuzz testing?</summary>

#### Go

`Fuzz testing` — це метод автоматизованого тестування, коли система отримує велику
кількість напіввипадкових або мутованих вхідних даних, щоб виявити краш, panic,
некоректну обробку edge-case-ів і порушення інваріантів.

#### Як це працює в Go:

1. Задають fuzz-функцію (`func FuzzXxx(f *testing.F)`).
2. Додають seed-входи (початкові приклади).
3. Фаззер мутує ці входи та генерує нові комбінації.
4. Якщо знаходить падіння або порушення перевірок, зберігає «мінімальний»
   відтворюваний кейс.

#### Що fuzz-тестування знаходить найкраще:

1. Несподівані edge-cases парсерів/декодерів.
2. Паніки на некоректних або «зламаних» вхідних даних.
3. Логічні дефекти в обробці рядків, байтів, форматів, протоколів.

#### Чому це цінно:

1. Покриває простір входів значно ширше за ручні unit-кейси.
2. Добре виявляє дефекти безпеки в parser-like коді.
3. Додає стійкість API до «токсичних» payload-ів із зовнішнього світу.

#### Практичні рекомендації:

1. Формулювати чіткі інваріанти (що має бути істинним для будь-якого вводу).
2. Починати з критичних surface-ів: парсинг, десеріалізація, нормалізація.
3. Після знаходження кейсу додавати його як регресійний тест.
4. Поєднувати fuzzing із `-race` і звичайними unit/integration тестами.

#### Висновок:

Fuzz testing у Go — це системний спосіб «ламати» код вхідними даними, щоб
знайти дефекти, які майже неможливо передбачити вручну. Це один із найсильніших
інструментів підвищення надійності й безпеки обробки даних.

</details>

<details>
<summary>121. Які є способи запуску тестів із БД у CI (Testcontainers, docker-compose, GitHub Actions services)? Які переваги кожного підходу?</summary>

#### Go

Для інтеграційних тестів із БД у CI найчастіше використовують три підходи:
`Testcontainers`, `docker-compose` і `GitHub Actions services`. Вибір залежить
від потрібного рівня ізоляції, складності стеку та швидкості пайплайна.

#### 1) Testcontainers

**Суть:**
контейнери піднімаються програмно з тестів і живуть у межах тестового запуску.

**Переваги:**

1. Максимальна близькість до коду тесту (infra описана поруч із тестами).
2. Висока ізоляція кейсів і передбачуване оточення.
3. Гнучке керування життєвим циклом БД, версіями, init-скриптами.
4. Зручно для локального відтворення CI-сценаріїв.

#### 2) docker-compose

**Суть:**
сервіси (БД + залежності) описані в `docker-compose.yml`, підіймаються перед
тестами як єдина композиція.

**Переваги:**

1. Простий і наочний опис багатосервісного середовища.
2. Легко додати кеші, брокери, кілька БД одночасно.
3. Однакова модель для локального dev і CI.
4. Добрий вибір для інтеграційних/е2е наборів.

#### 3) GitHub Actions services

**Суть:**
контейнер БД оголошується прямо в workflow job як service-контейнер.

**Переваги:**

1. Найпростіший CI-native сценарій для базових потреб.
2. Мінімум коду в тестах і окремої оркестрації.
3. Швидкий старт для одного-двох сервісів (Postgres, Redis тощо).

#### Практичне порівняння:

1. **Гнучкість та ізоляція**: Testcontainers > docker-compose > services.
2. **Простота старту**: services > docker-compose > Testcontainers.
3. **Багатосервісні складні стенди**: docker-compose / Testcontainers.
4. **Лаконічний CI для простої БД**: GitHub Actions services.

#### Висновок:

Універсально «кращого» підходу немає. Для простого CI достатньо services; для
складного інтеграційного середовища доречний docker-compose; для максимально
керованих і відтворюваних тестів на рівні коду найсильніший підхід —
Testcontainers.

</details>

#### Go

`go vet` — це статичний аналізатор із стандартного toolchain Go, який шукає
підозрілі конструкції коду, що часто є логічними помилками, але можуть не
ловитися компілятором.

#### Що перевіряє `go vet`:

1. Невідповідність форматних рядків і аргументів (`Printf`-подібні виклики).
2. Підозрілі помилки з копіюванням lock-об'єктів.
3. Проблемні патерни роботи з `testing`, `atomic`, `struct tags` тощо.
4. Інші типові дефекти, що можуть пройти компіляцію, але зламати поведінку.

#### Чим `go vet` відрізняється від компілятора:

1. Компілятор перевіряє коректність синтаксису та типів.
2. `vet` перевіряє «підозрілі наміри» й антипатерни.
3. Тобто це не заміна тестам, а додатковий рівень якості.

#### Як запускати:

1. Для поточного пакета:
   `go vet`
2. Для всього модуля:
   `go vet ./...`

#### Практична роль у проєкті:

1. Регулярно запускати локально перед комітом.
2. Додавати в CI як обов'язковий quality gate.
3. Розглядати попередження `vet` як сигнал до уважного code review.

#### Висновок:

`go vet` — це інструмент раннього виявлення підступних багів. Він підвищує
надійність коду, доповнюючи компілятор і тести, особливо у великих командних
Go-кодових базах.

</details>

<details>
<summary>123. Як профілювати Go-додаток (`pprof`)?</summary>

#### Go

`pprof` — стандартний інструмент профілювання Go, який показує, куди йдуть CPU,
пам'ять, алокації, блокування та час очікування. Це базовий спосіб знайти
реальні bottleneck-и перед оптимізаціями.

#### Що можна профілювати:

1. **CPU profile** — де витрачається процесорний час.
2. **Heap / allocs** — хто алокує пам'ять і що лишається «живим».
3. **Goroutine profile** — стан і кількість горутин.
4. **Block / mutex profile** — контеншн, блокування, затримки синхронізації.

#### Як підключити в сервісі:

1. Імпортувати `net/http/pprof` (зазвичай через side-effect import).
2. Відкрити debug endpoint (часто окремий порт або захищений маршрут).
3. Зняти профіль під реальним/репрезентативним навантаженням.

#### Типовий workflow аналізу:

1. Зібрати CPU/heap профіль.
2. Відкрити через `go tool pprof` (top/list/web).
3. Знайти hot paths/алокаційні вузли.
4. Внести точкову зміну.
5. Повторити профілювання й порівняти «до/після».

#### Практичні команди (загальна ідея):

1. Збір профілю з endpoint-а.
2. Локальний аналіз:
   `go tool pprof <profile>`
3. Візуалізація графа/флейм-подібного подання через web-режим.

#### Важливі принципи:

1. Не оптимізувати «на відчуттях» — лише за даними профілю.
2. Профілювати під умовами, близькими до продакшну.
3. Перевіряти, чи оптимізація не погіршила інші метрики (tail-latency, memory).

#### Висновок:

`pprof` — головний інструмент доказової оптимізації Go-додатків: він показує
реальну картину витрат і дозволяє приймати інженерні рішення на основі вимірювань,
а не інтуїції.

</details>

<details>
<summary>124. Як працює `go build` і крос-компіляція?</summary>

#### Go

`go build` компілює пакети/програми Go у бінарний файл (або перевіряє
збірність), використовуючи модульні залежності, кеш збірки й поточні параметри
цільової платформи.

#### Як працює `go build`:

1. Читає `go.mod` і резолвить залежності.
2. Компілює потрібні пакети (з урахуванням build tags та умовних файлів).
3. Використовує build cache для прискорення повторних збірок.
4. Лінкує фінальний виконуваний файл для цільової ОС/архітектури.

#### Що таке крос-компіляція:

Крос-компіляція — це збірка бінарника під іншу платформу, ніж та, на якій ви
запускаєте компілятор.

#### Основні параметри:

1. `GOOS` — цільова операційна система (наприклад, `linux`, `darwin`, `windows`).
2. `GOARCH` — цільова архітектура (`amd64`, `arm64` тощо).

#### Приклад:

1. Працюєте на macOS.
2. Хочете бінарник для Linux/amd64.
3. Збираєте з відповідними `GOOS/GOARCH`, отримуєте артефакт для деплою в Linux.

#### Практичні нюанси:

1. Для pure-Go коду крос-компіляція зазвичай проста.
2. Для `cgo`-залежностей потрібен сумісний cross-toolchain (C-компілятор для
   цільової платформи).
3. У CI часто роблять matrix-build для набору `GOOS/GOARCH`.

#### Висновок:

`go build` — це стандартизована збірка з кешуванням і модульною резолюцією.
Крос-компіляція в Go природно підтримується через `GOOS/GOARCH`, що робить мову
дуже зручною для multi-platform релізів.

</details>

<details>
<summary>125. Як контейнеризувати Go-додаток у Docker?</summary>

#### Go

Контейнеризація Go-додатка — це збірка бінарника й упаковка його в Docker-образ
для передбачуваного запуску в будь-якому середовищі (локально, CI, Kubernetes,
хмара).

#### Канонічний підхід:

1. Використати multi-stage Dockerfile:
- stage build: компіляція Go-бінарника;
- stage runtime: мінімальний образ для запуску.

2. На build-стадії:
- скопіювати `go.mod/go.sum`, завантажити залежності;
- скопіювати код;
- зібрати бінарник (`go build`).

3. На runtime-стадії:
- покласти лише фінальний бінарник і необхідні runtime-файли;
- задати `ENTRYPOINT/CMD`.

#### Чому це правильно:

1. Менший розмір фінального образу.
2. Краща безпека (менше зайвих пакетів у runtime).
3. Відтворювані збірки в CI/CD.
4. Швидший деплой і холодний старт.

#### Практичні рекомендації:

1. Додати `.dockerignore`, щоб не тягнути зайві файли в контекст збірки.
2. Запускати процес під non-root користувачем у runtime-образі.
3. Явно налаштувати `EXPOSE`, healthcheck (за потреби) і змінні оточення.
4. Використовувати pinned base image/tag для передбачуваності.

#### Типовий життєвий цикл:

1. `docker build` → отримали образ.
2. `docker run` → перевірили локально.
3. Пуш у registry → деплой у цільове середовище.

#### Висновок:

Контейнеризація Go-додатка в Docker найкраще працює через multi-stage підхід:
компіляція окремо, виконання окремо. Це дає компактний, безпечний і
операційно-зручний продакшн-образ.

</details>

<details>
<summary>126. Як зменшити розмір Docker-образу для Go-застосунку (multi-stage build)?</summary>

#### Go

Найефективніший спосіб зменшити образ Go-застосунку — multi-stage build:
компілювати в «важкому» build-образі, а запускати в максимально мінімальному
runtime-образі лише з фінальним бінарником.

#### Ключові кроки оптимізації:

1. **Multi-stage Dockerfile**
- stage 1: `golang` для збірки;
- stage 2: slim runtime (`distroless`/`scratch`/мінімальний base).

2. **Копіювати в runtime тільки необхідне**
- бінарник;
- за потреби CA-certs / timezone data / конфіг.

3. **Статичний бінарник (де доречно)**
- зменшує runtime-залежності;
- добре підходить для мінімальних образів.

4. **Оптимізувати сам бінарник**
- linker flags (`-ldflags="-s -w"`) для зменшення службової інформації.

5. **Грамотний `.dockerignore`**
- прибрати тести, `.git`, артефакти, локальні кеші з build-context.

6. **Кешування залежностей у build-стадії**
- окремо копіювати `go.mod/go.sum` перед копіюванням всього коду.

#### Додаткові практики:

1. Пінити базові образи за digest/tag для відтворюваності.
2. Працювати під non-root користувачем.
3. Регулярно перевіряти розмір і вразливості образу в CI.

#### Чого уникати:

1. Runtime на повному `golang`-образі без потреби.
2. Копіювання вихідного коду у фінальний шар.
3. Зайві інструменти дебагу у продакшн-образі.

#### Висновок:

Компактний Go-образ — це наслідок правильної сегрегації build/runtime-шарів.
Multi-stage + мінімальний runtime + чистий контекст збірки дають найкращий
баланс розміру, безпеки й швидкості деплою.

</details>

<details>
<summary>127. Які інструменти зазвичай використовують для збору метрик і логів? Як працює Prometheus?</summary>

#### Go

У сучасних системах зазвичай поєднують кілька класів інструментів:
метрики, логи, трейсинг, візуалізація та алертинг. Це дає цілісну картину
поведінки сервісу й пришвидшує діагностику інцидентів.

#### Типовий стек інструментів:

1. **Метрики**
- Prometheus, VictoriaMetrics, Graphite (рідше в нових системах).

2. **Візуалізація**
- Grafana (дашборди, SLO, кореляція метрик).

3. **Логи**
- Loki, Elasticsearch/OpenSearch + Kibana, Fluent Bit/Fluentd, Vector.

4. **Трейсинг**
- OpenTelemetry + Jaeger/Tempo/Zipkin.

5. **Алертинг**
- Alertmanager (часто у зв'язці з Prometheus).

#### Як працює Prometheus:

1. **Pull-модель збору:**
   Prometheus періодично «scrape»-ить HTTP endpoint-и сервісів (зазвичай
   `/metrics`) і забирає поточні значення метрик.

2. **Time-series storage:**
   кожна метрика з набором label-ів зберігається як часовий ряд.

3. **Запити через PromQL:**
   агрегування, rate-функції, percentile-подібна аналітика, кореляції.

4. **Rule engine:**
- recording rules для попередніх обчислень;
- alerting rules для генерації алертів.

5. **Інтеграція з Alertmanager:**
   дедуплікація, маршрутизація, групування і нотифікації (Slack, email, PagerDuty).

#### Чому Prometheus популярний:

1. Простий операційний model (pull + файли конфігурації).
2. Потужний PromQL.
3. Велика екосистема exporter-ів.
4. Добра інтеграція з Kubernetes і cloud-native середовищем.

#### Висновок:

Для метрик і логів у продакшні зазвичай використовують комбінований стек:
Prometheus + Grafana для метрик, окрему log-платформу для логів, і трейсинг для
міжсервісної діагностики. Prometheus у цьому стеку виконує роль ядра
time-series моніторингу та алертингу.

</details>

<details>
<summary>128. Яка різниця між мікросервісами та монолітом? Які переваги та недоліки?</summary>

#### Go

Моноліт і мікросервіси — це не «мода», а різні стратегії декомпозиції системи.
Вибір між ними визначається масштабом команди, складністю домену, вимогами до
автономності релізів і операційною зрілістю.

#### Моноліт:

**Суть:**
один застосунок, єдина кодова база (або щільно пов'язаний runtime), зазвичай
одна точка деплою.

**Переваги:**

1. Простий старт і нижча операційна складність.
2. Легший локальний дебаг і транзакційна цілісність усередині процесу.
3. Швидша розробка для невеликих команд/продуктів на ранній стадії.

**Недоліки:**

1. Складніше масштабувати окремі «гарячі» модулі незалежно.
2. З ростом коду збільшується зв'язаність і ризик повільних релізів.
3. Один великий деплой ускладнює часті незалежні зміни.

#### Мікросервіси:

**Суть:**
система розбита на автономні сервіси з власними межами відповідальності,
API-контрактами й незалежним життєвим циклом.

**Переваги:**

1. Незалежні релізи команд і сервісів.
2. Точкове масштабування окремих компонентів.
3. Технологічна гнучкість на рівні сервісів (за наявності governance).

**Недоліки:**

1. Висока операційна складність (мережа, discovery, observability, security).
2. Розподілена консистентність і складні міжсервісні транзакції.
3. Дорожчий дебаг через мережеву взаємодію та більшу кількість рухомих частин.

#### Практичний висновок:

Моноліт часто є найкращим стартом і може бути цілком ефективним довго.
Мікросервіси виправдані, коли масштаб домену й організації реально потребує
автономії команд, незалежного масштабування і чіткої сервісної декомпозиції.

</details>

<details>
<summary>129. Як реалізувати аутентифікацію в мікросервісній архітектурі?</summary>

#### Go

У мікросервісах аутентифікацію зазвичай будують навколо централізованого
Identity Provider (IdP) і токен-орієнтованої моделі (найчастіше OAuth2/OIDC +
JWT). Це дозволяє масштабувати доступ без дублювання login-логіки в кожному
сервісі.

#### Канонічна схема:

1. Клієнт проходить login в IdP (або auth-сервісі).
2. Отримує access token (і, за потреби, refresh token).
3. Передає access token у запитах до API Gateway/сервісів.
4. Сервіси валідують токен (підпис, термін дії, issuer, audience, scopes).

#### Де виконувати перевірку:

1. **На API Gateway**
- первинна валідація токена й відсікання неавторизованого трафіку.

2. **У кожному сервісі (defense in depth)**
- повторна перевірка критичних claims/прав доступу;
- не покладатися лише на периметр.

#### Що має бути в токені:

1. Ідентифікатор користувача/суб'єкта (`sub`).
2. Ролі/скоупи/права (мінімально необхідні).
3. `iss`, `aud`, `exp`, `iat` для безпечної валідації контексту.

#### Ключові безпекові практики:

1. Короткий TTL для access token.
2. Регулярна ротація ключів підпису (JWKS).
3. TLS усюди (north-south і east-west трафік).
4. Принцип least privilege для scopes/roles.
5. Чітке розділення аутентифікації (хто ти) та авторизації (що тобі можна).

#### Для service-to-service:

1. Використовувати окремі машинні креденшіали (client credentials, mTLS, service identity).
2. Не прокидати користувацькі токени без потреби вглиб системи.

#### Висновок:

Надійна аутентифікація в мікросервісах — це централізований IdP, токени з
коректною валідацією на всіх критичних межах і дисципліна безпеки (TTL, ротація
ключів, least privilege, TLS, defense in depth).

#### Приклад:

```go
func AuthMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		tok := strings.TrimPrefix(r.Header.Get("Authorization"), "Bearer ")
		claims, err := verifyJWT(tok)
		if err != nil {
			http.Error(w, "unauthorized", http.StatusUnauthorized)
			return
		}

ctx := context.WithValue(r.Context(), userClaimsKey{}, claims)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}
```

</details>

<details>
<summary>130. Як спроєктувати та реалізувати API Gateway у мікросервісній архітектурі і які задачі він має вирішувати?</summary>

#### Go

API Gateway — це єдина зовнішня точка входу в мікросервісну систему. Його
завдання — стандартизувати периметр: безпеку, маршрутизацію, політики трафіку,
спостережуваність і частково orchestration запитів.

#### Які задачі має вирішувати Gateway:

1. **Маршрутизація** до потрібних сервісів (path/host/method rules).
2. **Аутентифікація й базова авторизація** на периметрі.
3. **Rate limiting / throttling** і захист від перевантаження.
4. **TLS termination**, CORS, базові security headers.
5. **Request/response трансформації** (за потреби) та версіонування API.
6. **Observability**: централізовані логи, метрики, tracing-контекст.
7. **Resilience-політики**: timeout, retry (обережно), circuit breaker.

#### Ключові принципи проєктування:

1. **Тонкий Gateway:** не переносити в нього важку бізнес-логіку.
2. **Явний ownership контрактів:** хто відповідає за endpoint-и й політики.
3. **Безпека за замовчуванням:** deny-by-default, least privilege.
4. **Ідемпотентність і контроль retries:** щоб уникати дублювання побічних дій.
5. **План деградації:** fallback/помилки мають бути передбачуваними для клієнта.

#### Реалізаційна модель:

1. Вибрати технологію (ingress/API gateway-продукт або власний edge-сервіс).
2. Визначити policy-as-code (rate limits, auth rules, routing tables).
3. Налаштувати інтеграцію з service discovery і сертифікатами.
4. Впровадити end-to-end tracing (correlation IDs).
5. Додати SLO/алерти для gateway-рівня (latency, error rate, saturation).

#### Типові помилки:

1. «Товстий» gateway як новий моноліт.
2. Відсутність узгодженої error-моделі.
3. Надмірні трансформації на периметрі, що ускладнюють дебаг.
4. Єдина точка відмови без HA-конфігурації.

#### Висновок:

Сильний API Gateway — це не «місце для всього», а дисциплінований периметровий
шар: безпека, політики трафіку, спостережуваність і керована маршрутизація.
Бізнес-логіка при цьому має залишатися в доменних сервісах.

#### Приклад:

```yaml
routes:
  - path: /api/orders/*
    upstream: orders-service
    auth: required
    rateLimit:
      requestsPerMinute: 600
    timeoutMs: 2000
```

</details>

<details>
<summary>131. Як працює service discovery у мікросервісній архітектурі і як сервіси знаходять один одного без статичних IP/хостів?</summary>

#### Go

`Service discovery` — це механізм динамічного пошуку доступних інстансів сервісу
в умовах, коли IP/поди постійно змінюються (автоскейлінг, rolling update,
перезапуски).

#### Базовий принцип:

1. Інстанс сервісу реєструється в реєстрі discovery (або автоматично
   публікується оркестратором).
2. Клієнт або проміжний проксі запитує актуальні endpoints сервісу.
3. Запит маршрутизується до живого інстансу за правилами балансування.

#### Як сервіси «знаходять» один одного:

1. **DNS-based discovery**
- сервіс звертається до стабільного імені (`service-name.namespace`), а DNS
  повертає актуальні IP.

2. **Registry-based discovery**
- окремий service registry (або platform API) надає список healthy-інстансів.

3. **Service mesh / sidecar**
- застосунок звертається локально, а sidecar вирішує discovery, retry,
  load balancing і TLS.

#### Client-side vs server-side discovery:

1. **Client-side**
- клієнт сам отримує список інстансів і обирає ціль.

2. **Server-side**
- клієнт звертається до stable endpoint (LB/proxy), а вибір інстансу робить
  інфраструктурний шар.

#### Критичні елементи надійності:

1. Health checks і швидке виключення «мертвих» інстансів.
2. TTL/кешування з контролем застарівання записів.
3. Observability discovery-шару (latency, failure rate, churn).

#### Висновок:

Service discovery усуває потребу в статичних IP/хостах, надаючи динамічну
адресацію сервісів через реєстр, DNS або mesh. Це фундаментальна умова
масштабованості та еластичності мікросервісної системи.

#### Приклад:

```go
// У Kubernetes сервіс звертається за DNS-іменем, а не за статичним IP.
resp, err := http.Get("http://orders-service.default.svc.cluster.local/health")
if err != nil {
	return err
}
defer resp.Body.Close()
```

</details>

<details>
<summary>132. Як у мікросервісній архітектурі уникнути tight coupling, щоб система залишалась масштабованою і легко змінюваною?</summary>

#### Go

`Tight coupling` у мікросервісах виникає тоді, коли зміна одного сервісу
примушує змінювати інші. Щоб система лишалася масштабованою й еволюційною,
потрібні чіткі контракти, автономні межі домену і контроль залежностей.

#### Основні практики декуплінгу:

1. **Bounded contexts і чіткий service ownership**
- кожен сервіс відповідає за свій домен і свої дані;
- уникати «спільної» бази як каналу інтеграції.

2. **Контракт-орієнтована взаємодія**
- версіоновані API/схеми;
- backward compatibility як обов'язкова політика.

3. **Подієва інтеграція там, де можливо**
- publish/subscribe зменшує синхронну залежність «запит-відповідь».

4. **Anti-corruption layer**
- адаптери між доменами, щоб чужі моделі не «просочувалися» у ваш сервіс.

5. **Стабільні інтерфейси, нестабільна реалізація**
- внутрішні зміни сервісу не мають ламати споживачів.

6. **Ідемпотентність і ретраєстійкість**
- для асинхронних сценаріїв це ключ до слабшого зв'язування.

#### Організаційні та технічні запобіжники:

1. Consumer-driven contract testing.
2. API governance (правила еволюції контрактів).
3. Чітка observability між сервісами (trace-id, метрики залежностей).
4. Обмеження на fan-out і глибину синхронних ланцюжків.

#### Чого уникати:

1. Спільних таблиць/схем між командами.
2. «Розумного» API Gateway, що інкапсулює бізнес-логіку багатьох сервісів.
3. Невизначених контрактів і неявних залежностей через внутрішні поля payload.

#### Висновок:

Уникнення tight coupling — це дисципліна меж, контрактів і еволюції. Сервіси
мають бути автономними в даних і релізах, інтегруватися через стабільні
контракти та витримувати зміни сусідів без каскадних поломок.

</details>

<details>
<summary>133. Як організувати backward compatibility?</summary>

#### Go

`Backward compatibility` означає, що нова версія сервісу/API не ламає наявних
клієнтів. У розподілених системах це критично, бо споживачі оновлюються не
одночасно.

#### Базові принципи сумісності:

1. **Ніколи не ламати чинний контракт різко.**
2. **Additive changes over breaking changes:**
   додавати нові поля/ендпойнти без видалення старих.

3. **Стабільна семантика існуючих полів:**
   не змінювати значення/тип поля під тією ж назвою.

4. **Явна політика версіонування:**
   URL/version header/schema version.

#### Практичні техніки:

1. Додаткові поля робити optional з безпечними дефолтами.
2. Для видалення старого функціоналу застосовувати deprecation-період.
3. Підтримувати паралельно old+new контракти на час міграції.
4. Використовувати feature flags для контрольованого rollout.

#### Для подій і схем:

1. Схеми мають еволюціонувати адитивно.
2. Консюмери повинні ігнорувати невідомі поля.
3. Заборонити повторне використання «старих» ідентифікаторів полів
   (актуально для schema-based протоколів).

#### Контроль якості сумісності:

1. Consumer-driven contract tests.
2. Schema compatibility checks у CI.
3. Канарейкові релізи та моніторинг помилок клієнтів.

#### Висновок:

Організація backward compatibility — це поєднання технічних правил і релізної
дисципліни: адитивна еволюція контрактів, керована депрекація, автоматичні
перевірки сумісності та поетапний rollout.

</details>

<details>
<summary>134. Як у Go-застосунках реалізують оновлення конфігурації «на льоту» без перезапуску сервісу?</summary>

#### Go

Оновлення конфігурації «на льоту» (hot reload) у Go зазвичай будують як
керований процес: виявити зміну джерела, валідовано завантажити нову
конфігурацію, атомарно перемкнути активний снапшот і безпечно поширити його в
робочі компоненти.

#### Типова архітектурна схема:

1. **Джерело конфігурації**
- файл (watcher), env-provider, config service, KV-store.

2. **Loader + validator**
- читає нову версію;
- перевіряє схему, межі значень і міжпараметричні інваріанти.

3. **Atomic publish**
- новий конфіг-снапшот публікується через `atomic.Value` або інший
  thread-safe механізм.

4. **Споживачі конфігурації**
- читають поточний снапшот без блокуючих гонок.

#### Ключові інженерні вимоги:

1. **Атомарність перемикання**
- або вся нова конфігурація, або стара; без «напівстанів».

2. **Валідність перед застосуванням**
- некоректну версію не можна робити активною.

3. **Rollback-ready**
- у разі помилки застосування сервіс має лишитися на попередній робочій
  конфігурації.

4. **Observability**
- лог події reload, версія конфігурації, метрики успішних/провалених оновлень.

#### Що зазвичай можна міняти «на льоту»:

1. Ліміти, таймаути, фічефлаги, параметри retry/backoff.
2. Рівні логування.
3. Некритичні routing-політики.

#### Що часто НЕ варто міняти без рестарту:

1. Базові мережеві binding-параметри.
2. Критичні ініціалізаційні залежності, що не підтримують live reconfigure.
3. Параметри, зміна яких порушує поточні інваріанти стану.

#### Висновок:

Hot reload у Go — це не «магія watcher-а», а дисципліна безпечної публікації
конфігурації: validate → atomically swap → observe → rollback on failure.
Такий підхід дозволяє змінювати поведінку сервісу без downtime і без втрати
керованості.

</details>

<details>
<summary>135. Як у Go-сервісі реалізувати throttling (обмеження частоти запитів) для захисту системи від перевантаження?</summary>

#### Go

`Throttling` у Go-сервісі — це кероване обмеження інтенсивності запитів, щоб
захистити CPU, БД, зовнішні API та критичні ресурси від перевантаження й
каскадної деградації.

#### Основні моделі throttling:

1. **Token Bucket / Leaky Bucket**
- дозволяє короткі burst-и в межах місткості;
- стабілізує середній rate.

2. **Fixed / Sliding Window**
- ліміти за часовими вікнами (per second/minute).

3. **Concurrency limit**
- обмеження кількості одночасно оброблюваних запитів (семафор/воркер-пул).

#### Де застосовувати:

1. На периметрі (gateway/ingress) — глобальний захист.
2. Усередині сервісу — захист дорогих handler-ів/операцій.
3. На викликах залежностей — локальний ліміт для БД/зовнішніх API.

#### Розрізи лімітування:

1. Глобально на сервіс.
2. Per-route / per-endpoint.
3. Per-client / per-API-key / per-tenant / per-user.

#### Практичні рішення в Go:

1. Middleware з лімітером (часто token bucket).
2. Для multi-instance середовища — централізований або розподілений ліміт
   (наприклад, через Redis).
3. Чітка відповідь клієнту:
- HTTP `429 Too Many Requests`;
- `Retry-After` і зрозумілий error payload.

#### Важливі нюанси:

1. Ліміт має бути узгоджений із реальними можливостями бекенду.
2. Потрібні метрики:
- відсоток відхилених запитів;
- queue depth;
- latency до/після throttling.
3. Варто мати policy для пріоритетного трафіку (наприклад, системні клієнти).

#### Висновок:

Throttling у Go — це не просто «рубильник 429», а частина стратегії стійкості:
ліміти по швидкості й конкуренції, прозора політика відмови та метрики для
адаптації параметрів під реальне навантаження.

</details>

<details>
<summary>136. Як у Go працює caching layer і яку проблему вирішує `singleflight.Group` при конкурентних запитах?</summary>

#### Go

`Caching layer` у Go — це проміжний шар між бізнес-логікою та «дорогим»
джерелом даних (БД, зовнішній API, обчислення), який повертає попередньо
збережений результат для повторних запитів і зменшує навантаження на backend.

#### Як працює типовий cache flow:

1. Прийшов запит із ключем `K`.
2. Перевірка кешу:
- **cache hit** → повертаємо значення швидко;
- **cache miss** → читаємо з джерела, кладемо в кеш, повертаємо результат.

3. TTL/інвалідація керують свіжістю даних.

#### Яка проблема виникає при конкуренції:

На popular key під час `cache miss` може одночасно прийти багато запитів.
Без додаткового контролю всі вони підуть у backend паралельно — це
`cache stampede` (thundering herd).

#### Що робить `singleflight.Group`:

1. Дедуплікує одночасні однакові запити за ключем.
2. Лише перший запит виконує «дорогу» функцію.
3. Інші конкурентні запити чекають і отримують той самий результат.

#### Яку проблему це вирішує:

1. Різко зменшує дубльовані запити до БД/API на miss.
2. Стабілізує latency під піковим навантаженням.
3. Захищає backend від сплесків при масових одночасних зверненнях.

#### Важливі практики:

1. Використовувати `singleflight` разом із кешем, а не замість кешу.
2. Обмежувати час очікування через `context`/timeout.
3. Акуратно працювати з помилками (щоб не розмножувати transient-failure).
4. Додавати jitter до TTL, щоб уникати синхронного протухання багатьох ключів.

#### Висновок:

Caching layer прискорює читання й зменшує тиск на джерела даних, а
`singleflight.Group` усуває stampede-ефект під конкурентним `cache miss`.
Разом вони дають значно стійкішу й ефективнішу поведінку сервісу.

</details>

<details>
<summary>137. Як у Go-сервісі спроєктувати multi-tenant архітектуру з ізоляцією даних між клієнтами?</summary>

#### Go

Multi-tenant архітектура означає, що одна платформа обслуговує багато клієнтів
(tenant-ів), але гарантує ізоляцію їхніх даних, доступів і ресурсів. Ключ до
успіху — зробити tenant-контекст обов'язковою частиною всього запитного шляху.

#### Базові моделі ізоляції даних:

1. **Shared DB, shared schema + tenant_id**
- найдешевший старт;
- обов'язкові жорсткі фільтри на кожен запит.

2. **Shared DB, separate schema per tenant**
- сильніша логічна ізоляція;
- складніша операційна підтримка.

3. **Database per tenant**
- максимальна ізоляція й комплаєнс;
- найвища інфраструктурна вартість.

#### Що потрібно закласти в Go-сервісі:

1. **Tenant context**
- витягувати tenant із auth-токена/заголовка;
- передавати через `context.Context` у всі шари.

2. **Enforcement-by-default**
- репозиторний шар не має виконувати запити без tenant-фільтра;
- «no tenant, no query» як інваріант.

3. **Авторизація**
- перевіряти, що користувач/ключ має право на конкретний tenant.

4. **Ізоляція кешу**
- ключі кешу обов'язково включають tenant-id.

5. **Ізоляція черг/подій**
- tenant-мітки в подіях, фільтрація споживачами, контроль маршрутизації.

#### Операційні аспекти:

1. Квоти й rate limits per tenant.
2. Метрики/логи/трейси з tenant-атрибутом.
3. Backup/restore стратегія з урахуванням меж tenant-а.
4. Механізми міграції між моделями ізоляції при рості (наприклад, від shared до
   dedicated для enterprise-клієнтів).

#### Практичний висновок:

Multi-tenant у Go — це не лише схема БД, а наскрізна дисципліна: tenant identity,
політики доступу, ізоляція кешу/подій і операційний контроль. Чим раніше це
вбудовано в архітектуру, тим легше масштабувати продукт без витоків між клієнтами.

</details>

<details>
<summary>138. Як правильно організувати обробку довготривалих задач (long-running tasks), щоб не блокувати HTTP-запити?</summary>

#### Go

Довготривалі задачі не варто виконувати синхронно в HTTP-handler-і, бо це
підвищує latency, знижує throughput і збільшує ризик таймаутів/обривів клієнта.
Правильний підхід — асинхронне виконання через чергу/воркери.

#### Канонічна архітектура:

1. HTTP endpoint приймає запит, валідує payload.
2. Створює job (із `job_id`, статусом, метаданими).
3. Кладе job у чергу (broker/таблиця задач).
4. Повертає клієнту швидку відповідь (`202 Accepted` + `job_id`).
5. Фонові воркери обробляють задачу поза HTTP-контекстом.

#### Що потрібно для продакшн-надійності:

1. **Idempotency**
- повторна доставка job не має ламати стан.

2. **Retry policy**
- backoff, max attempts, класифікація retriable/non-retriable помилок.

3. **Статуси задач**
- `queued`, `running`, `succeeded`, `failed`, `canceled`.

4. **Observability**
- метрики черги, час виконання, частка помилок, lag воркерів.

5. **Cancellation / timeout**
- контроль меж часу виконання і коректне скасування.

6. **Backpressure**
- обмеження конкуренції воркерів, щоб не перевантажити БД/залежності.

#### Як клієнт отримує результат:

1. Polling endpoint за `job_id`.
2. Webhook/callback.
3. Push-канал (SSE/WebSocket) — за потреби near-real-time UX.

#### Типові помилки:

1. Виконувати важку бізнес-операцію прямо в handler-і.
2. Не мати персистентного статусу job.
3. Відсутність retry та dead-letter сценарію.
4. Немає ліміту воркерів і контролю черги.

#### Висновок:

Щоб не блокувати HTTP-запити, long-running задачі треба декомпозувати на модель
`accept -> enqueue -> async process -> observe result`. Це дає стабільний API,
керований throughput і передбачувану експлуатацію під навантаженням.

#### Приклад:

```go
func (h *Handler) StartReport(w http.ResponseWriter, r *http.Request) {
	jobID := uuid.NewString()
	_ = h.queue.Publish(r.Context(), Job{ID: jobID, Type: "build_report"})

w.WriteHeader(http.StatusAccepted)
	_ = json.NewEncoder(w).Encode(map[string]string{"job_id": jobID})
}
```

</details>

<details>
<summary>139. Як побудувати міжсервісну транзакцію?</summary>

#### Go

У мікросервісах класична ACID-транзакція між кількома БД/сервісами зазвичай
непрактична. Тому міжсервісну «транзакцію» будують через узгоджену
бізнес-процедуру з компенсаціями та eventual consistency.

#### Основні підходи:

1. **Saga (найпоширеніший)**
- послідовність локальних транзакцій у сервісах;
- при збої запускаються компенсаційні дії.

2. **Orchestration Saga**
- центральний orchestrator керує кроками й відкатами.

3. **Choreography Saga**
- сервіси реагують на події один одного без центрального диригента.

4. **2PC/XA**
- теоретично можливо, але зазвичай у мікросервісах уникають через складність і
  деградацію доступності.

#### Канонічний дизайн міжсервісної транзакції:

1. Розбити процес на локальні атомарні кроки.
2. Для кожного кроку визначити компенсацію.
3. Забезпечити ідемпотентність команд і подій.
4. Реалізувати надійну доставку через outbox/inbox патерни.
5. Додати кореляційний `transaction/saga id` для трасування.

#### Критичні вимоги:

1. **Ідемпотентність** на всіх межах.
2. **Retry/backoff** для тимчасових збоїв.
3. **Дедуплікація** повторно доставлених подій.
4. **Timeout і dead-letter політики** для «завислих» кроків.
5. **Спостережуваність**: статуси саги, метрики, аудит.

#### Висновок:

Міжсервісна транзакція в мікросервісах — це не global ACID, а керований
процес консистентності: локальні транзакції + події + компенсації. Найпрактичніша
модель для цього — Saga з чіткими інваріантами та надійною обробкою збоїв.

#### Приклад:

```go
// Спрощений оркестратор Saga
func (s *Saga) Run(ctx context.Context, cmd CreateOrder) error {
	if err := s.reserveInventory(ctx, cmd); err != nil {
		return err
	}
	if err := s.chargePayment(ctx, cmd); err != nil {
		_ = s.compensateInventory(ctx, cmd)
		return err
	}
	return s.confirmOrder(ctx, cmd)
}
```

</details>

<details>
<summary>140. Які проблеми вирішує патерн Saga?</summary>

#### Go

Патерн `Saga` вирішує проблему узгодженої бізнес-операції, що охоплює кілька
мікросервісів із окремими БД, де неможливо або недоцільно застосувати одну
глобальну ACID-транзакцію.

#### Які саме проблеми закриває Saga:

1. **Відсутність distributed ACID між сервісами**
- замінює global transaction на послідовність локальних транзакцій.

2. **Потреба в компенсації при частковому збої**
- якщо один із кроків провалився, виконуються compensating actions.

3. **Керування eventual consistency**
- дозволяє досягати узгодженого бізнес-стану асинхронно.

4. **Зниження зв'язаності між сервісами**
- кроки можуть взаємодіяти через події/команди без жорсткого 2PC.

5. **Стійкість до тимчасових збоїв**
- retry/backoff і ідемпотентність роблять процес більш надійним.

#### Що Saga не «лікує» автоматично:

1. Не прибирає потребу в чіткому доменному моделюванні компенсацій.
2. Не скасовує складність observability й моніторингу стану процесу.
3. Не гарантує миттєву консистентність — лише керовану узгодженість у часі.

#### Де Saga особливо доречна:

1. Checkout/Order workflow (резерв товару, платіж, доставка).
2. Бронювання/відміна ресурсів у кількох системах.
3. Будь-які multi-step бізнес-процеси з крос-сервісними ефектами.

#### Висновок:

Saga вирішує центральну проблему мікросервісної консистентності: як провести
складну міжсервісну операцію без глобального lock-координатора, з контрольованим
відновленням через компенсації та прийнятною операційною стійкістю.

</details>

<details>
<summary>141. Що таке Event Sourcing?</summary>

#### Go

`Event Sourcing` — це підхід, у якому система зберігає не «поточний стан»
сутності, а послідовність подій (event-ів), що цей стан змінювали.
Поточний стан відтворюють шляхом програвання (replay) подій.

#### Ключова ідея:

1. Джерело істини — immutable журнал доменних подій.
2. Стан агрегата — похідний результат редукції цих подій у порядку часу.
3. Зміна стану відбувається через додавання нової події, а не через «перезапис».

#### Що дає Event Sourcing:

1. **Повний аудит-трейл**: видно, хто/коли/чому змінив доменний стан.
2. **Відтворюваність стану** на будь-який момент часу.
3. **Гнучкі проєкції** (read models) для різних сценаріїв читання.
4. **Природна інтеграція з event-driven архітектурою**.

#### Типові складові:

1. Event store (append-only).
2. Aggregate із правилами валідації команд.
3. Projection/read model builders.
4. Механізми версіонування подій і upcaster-и.

#### Важливі виклики:

1. Складність еволюції схем подій.
2. Потреба в snapshot-ах для швидкого відновлення довгих stream-ів.
3. Операційна складність консистентності між write/read моделями (часто CQRS).

#### Коли доречно:

1. Домени з високими вимогами до аудиту та історії змін.
2. Складні бізнес-процеси, де важлива причинно-наслідкова прозорість.
3. Системи, де події є природним контрактом інтеграції.

#### Висновок:

Event Sourcing — це модель «зберігай факти подій, а не фінальний стан». Вона
дає сильну історичну прозорість і архітектурну гнучкість, але вимагає зрілої
дисципліни моделювання подій, версіонування й операційної підтримки.

</details>

<details>
<summary>142. Сформулюйте CAP-теорему.</summary>

#### Go

CAP-теорема стверджує: у розподіленій системі під час мережевого розділення
(`Partition`) неможливо одночасно гарантувати і сильну узгодженість
(`Consistency`), і повну доступність (`Availability`) для всіх запитів.

#### Три властивості CAP:

1. **Consistency (C)**  
   усі вузли бачать один і той самий актуальний стан даних після операції
   запису.

2. **Availability (A)**  
   кожен запит отримує відповідь (успіх/помилка без нескінченного очікування).

3. **Partition tolerance (P)**  
   система продовжує працювати, навіть якщо між вузлами є мережеві розриви або
   затримки зв'язку.

#### Ключовий практичний акцент:

1. У реальних розподілених системах `P` майже завжди обов'язкова (мережа
   ненадійна за природою).
2. Тому в момент partition доводиться обирати пріоритет:
- **CP**: зберегти узгодженість, пожертвувавши частиною доступності;
- **AP**: зберегти доступність, погодившись на тимчасову неузгодженість.

#### Висновок:

CAP не каже «обери лише дві властивості назавжди». Вона каже: **коли стається
partition, одночасно максимальні C і A недосяжні**; архітектор має свідомо
визначити, чим система жертвує в аварійному режимі.

</details>

<details>
<summary>143. Розкажіть про алгоритм консенсусу Raft.</summary>

#### Go

Raft — це алгоритм консенсусу для реплікованого журналу (replicated log), який
дозволяє групі вузлів узгоджено зберігати однакову послідовність команд навіть
за часткових відмов мережі чи вузлів.

#### Головна ідея Raft:

1. У кластері є **один leader** і кілька followers.
2. Клієнтські записи приймає leader.
3. Leader реплікує записи у журнал followers.
4. Запис вважається committed після підтвердження більшістю (quorum).
5. Усі вузли застосовують committed-записи в однаковому порядку.

#### Ролі вузлів:

1. **Leader** — керує реплікацією й обробляє клієнтські команди.
2. **Follower** — пасивно приймає реплікацію від leader.
3. **Candidate** — роль під час виборів нового leader.

#### Вибори leader:

1. Час поділено на терми (`term`).
2. Якщо follower не отримує heartbeat, він стає candidate й ініціює вибори.
3. Вузол, що набрав більшість голосів, стає leader поточного терму.

#### Гарантії безпеки:

1. **Log matching** — однаковий індекс/терм означає однакову історію до цієї точки.
2. **Leader completeness** — committed-записи зберігаються в журналах майбутніх leader-ів.
3. **State machine safety** — команди застосовуються в узгодженому порядку на всіх вузлах.

#### Практичні аспекти:

1. Quorum-залежність означає: без більшості кластер не може комітити нові записи.
2. Для обмеження росту журналу використовують snapshot/log compaction.
3. Коректні таймаути heartbeat/election критичні для стабільності.

#### Висновок:

Raft забезпечує зрозумілу й надійну модель консенсусу: leader-based реплікацію,
вибори через quorum і сильні гарантії узгодженості журналу. Саме тому його
широко застосовують у системах конфігурації, координації та розподілених
stateful-сервісах.

</details>

<details>
<summary>144. Як організувати CI/CD для Go?</summary>

#### Go

Ефективний CI/CD для Go будується як послідовний конвеєр: швидка валідація коду,
відтворювана збірка, автоматизовані тести, безпечний деплой і контрольований
rollback.

#### Типова структура CI-пайплайна:

1. **Lint + static checks**
- `go vet`, лінтери, базові security checks.

2. **Unit tests**
- `go test ./...` (за потреби `-race` для критичних гілок).

3. **Integration tests**
- сервіси/БД у контейнерах або test-env.

4. **Build stage**
- відтворювана збірка артефакту (бінарник/контейнер).

5. **Artifact publishing**
- пуш образу в registry, тегування версією/комітом.

#### Типова структура CD:

1. Деплой у staging.
2. Автоматичні smoke/checks.
3. Промоут у production (manual gate або policy-based).
4. Постдеплойний моніторинг SLO/error-rate/latency.

#### Ключові практики надійності:

1. **Immutable artifacts** (не перебудовувати той самий реліз двічі).
2. **Pinning версій toolchain/dependencies**.
3. **Secrets management** через CI vault/secret store.
4. **Environment parity** між staging і prod.
5. **Canary/blue-green rollout** для зниження ризиків релізу.

#### Що важливо саме для Go:

1. Швидкі тести й збірка дозволяють короткий feedback loop.
2. Matrix-build для кількох `GOOS/GOARCH` за потреби.
3. Раннє виявлення конкурентних дефектів (`-race`) у релевантних джобах.

#### Висновок:

CI/CD для Go має бути швидким, відтворюваним і керованим ризиком: перевірити,
зібрати, протестувати, задеплоїти поетапно і мати гарантований шлях відкату.
Саме така дисципліна дає стабільні релізи без втрати швидкості розробки.

</details>

<details>
<summary>145. Як організувати rollback у CI/CD для Go-сервісу, щоб швидко і безпечно відкотити невдалий реліз?</summary>

#### Go

Надійний rollback — це не «план Б», а частина дизайну релізного процесу.
Щоб відкотити Go-сервіс швидко й безпечно, треба заздалегідь мати
відтворювані артефакти, контрольований rollout і чіткі тригери повернення.

#### Базові принципи rollback-ready процесу:

1. **Immutable artifacts**
- кожен реліз має унікальний тег/sha;
- rollback = перевидання попереднього перевіреного артефакту.

2. **Деплой без руйнівних кроків**
- зміни мають бути reversible;
- міграції БД — backward-compatible або з окремим планом відкату.

3. **Швидке переключення трафіку**
- canary/blue-green/rolling з можливістю миттєво зменшити або обнулити частку
  нового релізу.

#### Що має бути в CI/CD:

1. Автоматичні smoke/check-и після деплою.
2. SLO-гейти (error rate, p95/p99 latency, saturation).
3. Чітка команда/процедура rollback в один крок.
4. Алерти, що спрацьовують рано, а не після масового інциденту.

#### Стратегія rollback у production:

1. Виявили деградацію метрик.
2. Автоматично або вручну зупинили rollout.
3. Перемкнули трафік на попередню стабільну версію.
4. Перевірили відновлення SLO.
5. Зафіксували постмортем і причину регресії.

#### Критичний аспект — база даних:

1. Схеми змінювати за принципом expand/contract.
2. Уникати міграцій, що одразу ламають старий код.
3. Розділяти деплой коду і небезпечні DDL-кроки.

#### Висновок:

Швидкий і безпечний rollback у Go CI/CD можливий лише тоді, коли він
запроєктований наперед: immutable релізи, керований rollout, метрики-гейти,
reversible зміни та відпрацьована операційна процедура відкату.

</details>

<details>
<summary>146. Як працює blue-green deployment?</summary>

#### Go

`Blue-green deployment` — це стратегія релізу, де одночасно існують два
ідентичні продакшн-середовища:

1. **Blue** — поточна бойова версія.
2. **Green** — нова версія, підготовлена до прийому трафіку.

#### Як це працює покроково:

1. Нова версія деплоїться в `green`, не зачіпаючи `blue`.
2. У `green` виконують health checks, smoke tests, базову валідацію.
3. Після успішної перевірки трафік перемикають із `blue` на `green`
   (через LB/ingress/router).
4. Стара версія (`blue`) лишається доступною як «гарячий» rollback-варіант.

#### Переваги:

1. **Мінімальний downtime** при релізі.
2. **Швидкий rollback** — достатньо повернути трафік на попереднє середовище.
3. **Безпечна валідація до перемикання** без ризику для всіх користувачів.
4. **Чітка операційна модель** для керування релізами.

#### Ризики й обмеження:

1. Потрібні подвійні ресурси (два середовища одночасно).
2. Ускладнення при stateful-компонентах і міграціях БД.
3. Потрібна ретельна синхронізація конфігурації, секретів і зовнішніх залежностей.

#### Практичні рекомендації:

1. Поєднувати blue-green із автоматичними SLO-check перед cutover.
2. Для БД використовувати backward-compatible міграції (expand/contract).
3. Мати формалізовану процедуру rollback і перевірки після перемикання.

#### Висновок:

Blue-green deployment дає контрольований і швидкий реліз із майже миттєвим
відкатом. Це одна з найнадійніших стратегій для production, якщо система готова
до подвійного середовища й дисциплінованого керування станом.

</details>

golang-interview-questions

golang-interview-questions 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

golang-interview-questions

golang-interview-questions 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README