Senior Go Interview Prep

Analytics Pipeline

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Аналитический пайплайн принимает миллиарды событий в сутки от продуктовых SDK/бэкендов, буферизует их в Kafka, обрабатывает потоково (Flink/Spark Structured Streaming) и пакетно, складывает в колоночное OLAP-хранилище (ClickHouse/Druid/BigQuery) и обслуживает дашборды и ad-hoc аналитику. Ключевые оси решений: stream vs batch (latency vs полнота/точность), lambda vs kappa (две кодовые базы vs reprocess из лога), exactly-once vs at-least-once + дедупликация, raw vs pre-aggregated (rollups). Главная единица параллелизма — партиции Kafka; главные узкие места — skew/hot partition, конкуренция query vs ingest в OLAP и стоимость хранения/retention.

CAP теорема

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

CAP — это не «выбери 2 из 3». Сетевые партиции (P) случаются вне твоего контроля, поэтому реальный выбор делается только во время партиции: либо Consistency, либо Availability. В отсутствие партиции можно иметь и C, и A одновременно.
C в CAP — это linearizability (строгая согласованность по чтению, recency guarantee), а не буква C из ACID (consistency = соблюдение инвариантов/констрейнтов). Это разные понятия, которые путают чаще всего.
A в CAP — это «каждый запрос к работающему узлу получает (не-error) ответ». Это очень жёсткое определение: latency не учитывается, ответ должен прийти от любой ноды, не упавшей физически.
P (partition tolerance) — система продолжает работать при потере произвольного числа сообщений между узлами. Для распределённой системы это не опция, а данность.
CP: при партиции жертвуем доступностью (некоторые узлы отвечают ошибкой/таймаутом ради согласованности). Примеры: etcd, ZooKeeper, Consul, HBase, Spanner, традиционные RDBMS с синхронной репликацией.
AP: при партиции жертвуем линеаризуемостью (узлы отвечают возможно устаревшими данными). Примеры: Cassandra, DynamoDB, Riak, Voldemort.
PACELC дополняет CAP: при Partition выбираем между A/C, иначе (Else) — между Latency/Consistency. Это честнее описывает реальные системы.

Теория#

Формулировка и её точный смысл#

Теорему сформулировал Эрик Брюер (2000, conjecture), формально доказали Gilbert & Lynch (2002). Точная формулировка доказанной версии:

CI/CD: пайплайны, стадии, стратегии деплоя

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

CI (Continuous Integration) — на каждый push/PR автоматически прогоняются lint, тесты, сборка. Цель: ловить интеграционные проблемы рано, держать main всегда зелёным.
CD — двусмысленно: Continuous Delivery (автоматически готовим релиз, кнопка деплоя ручная) vs Continuous Deployment (каждый зелёный коммит в main автоматически едет в prod). На senior-собеседовании важно разделять эти два понятия.
Типичные стадии Go-пайплайна: lint → test (unit + race + coverage) → build (бинарь/Docker-образ) → scan (уязвимости) → publish (push в registry) → deploy.
Артефакт — иммутабельный результат сборки (Docker-образ по digest, бинарь, helm chart). Билдим один раз, продвигаем по окружениям (build once, deploy many). Не пересобираем для каждого env.
Версионирование: SemVer для библиотек/API, git SHA или git describe для сервисов. Образы тегируем и неизменяемым (sha-abc123), и плавающим (latest, v1.2) тегом.
Стратегии деплоя: rolling (по умолчанию в k8s), blue-green (мгновенное переключение + быстрый откат), canary (постепенный rollout на % трафика с метриками).

Теория#

Pipeline as Code#

Пайплайн описывается в репозитории (.github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile). Преимущества: версионируется вместе с кодом, review через PR, воспроизводимость. Конфиг в UI — антипаттерн (нет истории, нет review).

Grafana

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Middle+/Senior

TL;DR#

Grafana — слой визуализации и алертинга поверх множества источников данных (Prometheus, Loki, Tempo, и др.). Дашборд = набор panels, каждая панель выполняет запрос к data source и рендерит результат (time series, stat, gauge, table, heatmap). Сила Grafana — корреляция трёх сигналов: из метрики (Prometheus) по exemplar прыгнуть в трейс (Tempo), из трейса в логи (Loki) через derived fields. Templating ($variable) делает дашборды переиспользуемыми между сервисами/инстансами. Grafana Unified Alerting — отдельная подсистема (alert rules → notification policies → contact points), не путать с панельным «алертом». Senior-практика: дашборды как код (provisioning/Terraform/Grafonnet, не клики), иерархия overview → service → instance, аннотации деплоев, и осторожность с $__rate_interval, downsampling и вводящими в заблуждение average-панелями.

sync/atomic

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

sync/atomic даёт атомарные операции над одиночными словами (load/store/add/swap/CAS), реализованные аппаратными инструкциями (LOCK-префикс на x86, LL/SC или CASAL на ARM) без блокировок и парковки горутин. Go 1.19 ввёл типобезопасные обёртки atomic.Int64, atomic.Pointer[T], atomic.Bool и др., которые нельзя случайно скопировать и которые гарантируют выравнивание. Atomic — для простых счётчиков/флагов/указателей и lock-free структур; для составных инвариантов (несколько связанных полей) нужен мьютекс.

Теория#

Операции#

Load / Store — атомарное чтение/запись слова целиком (без «разорванной» записи).
Add — атомарный инкремент/декремент, возвращает новое значение.
Swap — атомарно записать новое и вернуть старое.
CompareAndSwap (CAS) — если текущее значение == old, записать new, вернуть успех. Фундамент lock-free алгоритмов.

var n atomic.Int64
n.Add(1)
v := n.Load()

// CAS-цикл (классический lock-free паттерн)
for {
 old := n.Load()
 next := compute(old)
 if n.CompareAndSwap(old, next) {
 break // успех: никто не вмешался между Load и CAS
 }
 // кто-то изменил n — повторяем
}

Типобезопасные обёртки (Go 1.19+)#

var (
 flag atomic.Bool
 cnt atomic.Uint64
 cfg atomic.Pointer[Config]
 val atomic.Value // для произвольного типа, тип фиксируется первым Store
)

Преимущества над старыми функциями atomic.AddInt64(&x, 1):

testify, assert/require и golden files

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

testify — самая популярная вспомогательная библиотека: assert (помечает fail и продолжает тест) и require (помечает fail и немедленно останавливает через t.FailNow). Используйте require для предусловий, без которых дальнейшие проверки бессмысленны/опасны (nil-разыменование), и assert для независимых проверок, где хочется увидеть все падения сразу. Стандартной библиотеки (if got != want { t.Errorf(...) }) часто достаточно — для простых сравнений она читаема и без зависимостей; testify окупается на множестве проверок и понятных дифф-сообщениях. Для больших/структурных выходов — golden files: эталон в testdata/*.golden, обновляемый флагом -update, сравнение через go-cmp.

Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

Аутентификация (AuthN) — «кто ты?» (проверка личности). Авторизация (AuthZ) — «что тебе можно?» (проверка прав). Это два независимых шага: сначала AuthN, потом AuthZ.
Сессии (stateful): server-side store + opaque cookie. Легко отозвать, но требует общего стора и липкости/репликации. JWT (stateless): self-contained подпись, масштабируется горизонтально, но невозможно мгновенно отозвать без денилиста. Не путайте «stateless токен» с «нет состояния вообще».
Cookie: всегда HttpOnly, Secure, SameSite. Защита от XSS (HttpOnly) и CSRF (SameSite/anti-CSRF token) — это разные угрозы, нужны оба слоя.
Пароли: только argon2id (предпочтительно) / bcrypt / scrypt с уникальной солью. Никогда plaintext/MD5/SHA-256 без KDF. Сравнение — constant-time.
RBAC (роли) для простых иерархий; ABAC (атрибуты + политики) для контекстных решений; ReBAC (Zanzibar/SpiceDB) для графов отношений («владелец документа», sharing).
API keys — для machine-to-machine: хранить только хэш, скоупить, ротировать. mTLS — взаимная аутентификация по сертификатам, типично в service mesh.
Секреты: не в git, не хардкодить. Env vars — минимум; Vault/Secrets Manager + ротация + encryption at rest — для прода. Принцип наименьших привилегий + defense in depth везде.

Теория#

1. Аутентификация (AuthN) vs Авторизация (AuthZ)#

Это самая базовая и самая часто путаемая пара понятий.

Конфликты, разногласия и работа со стейкхолдерами

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Behavioral · Уровень: Senior

TL;DR#

Senior не «избегает конфликтов» — он переводит их из эмоциональной плоскости в плоскость данных, рисков и trade-off’ов.
Технические споры решаются критериями, а не громкостью голоса: SLA, стоимость, сроки, поддерживаемость, обратимость решения.
Disagree and commit — ключевой навык: ты можешь быть против, но после принятия решения исполняешь его как своё и не саботируешь.
С легаси работаешь инкрементально и с измеримой ценностью, а не «давайте всё перепишем».
Со стейкхолдерами говоришь на их языке (деньги, риски, сроки, клиент), а не на языке стектрейсов.
Пушбэк на нереалистичные сроки — это не «нет», а «вот варианты scope/quality/time, выбирайте».

Теория / Подход#

Природа конфликта на senior-уровне#

Интервьюер проверяет не «бесконфликтность» (это red flag — значит человек либо избегает ответственности, либо врёт), а зрелость: умеешь ли ты не доводить разногласие до личного, отделять позицию человека от проблемы, и доводить ситуацию до решения, с которым команда может жить.

Механика defer в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

defer откладывает вызов функции до момента выхода из окружающей функции (return, паника или нормальное завершение). Аргументы отложенного вызова вычисляются в момент выполнения оператора defer, а сам вызов — позже, в порядке LIFO. Отложенные функции могут читать и модифицировать именованные возвращаемые значения, что лежит в основе паттерна recover. С Go 1.14 для статически известного и небольшого (≤8) числа defer без циклов компилятор применяет open-coded defer — почти нулевые накладные расходы; иначе используется _defer-запись в runtime.

Паттерны аллокаций и снижение давления на GC

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

Большинство «горячих» проблем производительности в Go — это не CPU, а аллокации: каждая аллокация в куче нагружает аллокатор и увеличивает работу GC (assist, mark, scan). Senior-разработчик умеет считать аллокации через -benchmem, предаллоцировать слайсы/мапы с учётом amortized growth, переиспользовать буферы (strings.Builder, bytes.Buffer, sync.Pool) и избегать неявного boxing в интерфейсах. Главное — измерять (pprof, -benchmem, escape analysis), а не угадывать.

Теория#

Стоимость аллокации и связь с GC#

В Go стоимость одной аллокации складывается из нескольких частей:

Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

Установка TCP+TLS соединения и форк backend-процесса в PostgreSQL — дорогая операция (десятки мс, мегабайты RAM на backend). Пул переиспользует физические соединения, амортизируя стоимость.
PostgreSQL — process-per-connection: каждое соединение это отдельный ОС-процесс. max_connections ограничен сверху, и реальная пропускная способность падает задолго до лимита из-за конкуренции за CPU, lock manager и shared buffers.
database/sql даёт встроенный пул: SetMaxOpenConns (жёсткий потолок), SetMaxIdleConns (сколько держать свободными), SetConnMaxLifetime (ротация), SetConnMaxIdleTime (закрытие простаивающих). Метрики — db.Stats().
pgx имеет два режима: native API (pgx.Conn, pgxpool.Pool) с extended-протоколом и кэшем prepared statements, и совместимый database/sql драйвер (stdlib).
pgxpool — production-grade пул pgx: MaxConns, MinConns, MaxConnLifetime, MaxConnIdleTime, HealthCheckPeriod, lifecycle-хуки.
PgBouncer — внешний пулер. В transaction mode ломаются: серверные prepared statements, session-level advisory locks, SET, LISTEN/NOTIFY, temp tables, WITH HOLD cursors. Лечится DefaultQueryExecMode = simple protocol или statement_cache_capacity=0 (на новых PgBouncer >= 1.21 есть серверный prepared statement support).
Размер пула считается, а не «ставится побольше». Базовая формула: connections ≈ ((core_count * 2) + effective_spindle_count). Больше соединений почти всегда хуже из-за context switching.
Утечки соединений — главный production-инцидент: незакрытые Rows, забытый Close() у транзакции, отсутствие context с таймаутом. Пул исчерпывается, запросы виснут на ожидании свободного соединения.

Теория#

Зачем вообще пул: цена соединения в PostgreSQL#

PostgreSQL использует модель process-per-connection. Каждое новое клиентское соединение приводит к тому, что главный процесс postmaster делает fork(), создавая отдельный backend-процесс. Это влечёт:

Пулы соединений: http.Transport, БД, утечки

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

Пул соединений переиспользует установленные TCP(+TLS) соединения, экономя дорогой handshake (RTT + TLS + slow start) и избегая исчерпания эфемерных портов / TIME_WAIT.
В Go HTTP-пул живёт в http.Transport: ключевые ручки — MaxIdleConns, MaxIdleConnsPerHost, MaxConnsPerHost, IdleConnTimeout.
Главный антипаттерн: создавать новый http.Client/Transport на каждый запрос — пул не переиспользуется, соединения не шарятся. Клиент должен быть один и переиспользуемый.
Утечки соединений: незакрытое resp.Body → соединение не возвращается в пул → рост FD, новые коннекты, деградация. То же для БД: незакрытые *sql.Rows.
Для БД (database/sql): SetMaxOpenConns, SetMaxIdleConns, SetConnMaxLifetime, SetConnMaxIdleTime. Lifetime критичен для DNS-failover и балансировки.

Теория#

Зачем пул#

Установка соединения дорогая: TCP handshake (1 RTT) + TLS handshake (1-2 RTT) + TCP slow start. На горячем пути это десятки-сотни мс. Пул держит idle-соединения готовыми к переиспользованию (keep-alive), убирая эти затраты и снижая TIME_WAIT/исчерпание портов.

Типовые алгоритмические задачи и паттерны

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Алгоритмы · Уровень: Middle+/Senior

TL;DR#

На senior live-coding дают задачи средней сложности: two pointers, sliding window, binary search, BFS/DFS, базовый DP, сортировки.
Ценят не «знание трюка», а распознавание паттерна по условию, корректные edge cases, чистый код и проговаривание сложности.
Большинство паттернов сводят O(n²) перебор к O(n) / O(n log n) за счёт инварианта (указатели, окно, отсортированность).
Всегда: уточнить вход (пустой? отсортирован? дубликаты? отрицательные?), назвать сложность, проверить границы.

Теория#

Паттерн 1: Two Pointers (два указателя)#

Два индекса, движущихся навстречу или в одном направлении. Часто требует отсортированного входа. Заменяет O(n²) на O(n).

Chat System

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Чат-система — это набор stateful WebSocket-коннектов поверх stateless-логики доставки. Главная боль: коннекты живут на конкретных серверах, а сообщение приходит «не туда». Решается через session registry (Redis: user_id → ws_node) и брокер для маршрутизации между нодами. Доставка — at-least-once + idempotency key + ACK, порядок — монотонный seq per channel (а не глобальный). Хранение горячего потока — wide-column (Cassandra/ScyllaDB) с ключом (channel_id, bucket) / seq. Offline — fallback на push (APNs/FCM) + полная синхронизация по seq при reconnect. Узкое место senior-уровня — не throughput сообщений, а миллионы одновременных stateful-коннектов, presence-стадо и hot groups.

Circuit Breaker

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Circuit breaker («предохранитель») оборачивает вызов нестабильной зависимости и при росте ошибок размыкает цепь — перестаёт слать запросы, мгновенно возвращая ошибку (fail fast).
Три состояния: Closed (запросы идут, считаем ошибки) → при превышении порога → Open (запросы блокируются, fail fast) → по таймауту → Half-Open (пропускаем пробные запросы) → успех → Closed, провал → снова Open.
Зачем: fail fast (не ждать таймаутов на мёртвый сервис), защита downstream от добивания нагрузкой во время деградации, дать сервису время восстановиться, предотвратить каскадные сбои.
Bulkhead — изоляция ресурсов (отдельные пулы соединений/семафоры на каждую зависимость), чтобы один тормозящий downstream не выел все воркеры/горутины.
В Go стандарт де-факто — github.com/sony/gobreaker: Settings{ReadyToTrip, OnStateChange, Interval, Timeout, MaxRequests}, cb.Execute(fn), Counts.
Fallback: вернуть кэш, дефолт или деградированный ответ вместо ошибки.
Circuit breaker ≠ retry. Retry борется с транзиентными сбоями повтором; breaker борется с устойчивыми сбоями прекращением запросов. Комбинация retry+breaker опасна — ретраи накручивают счётчик ошибок и раздувают нагрузку; порядок и настройка критичны.

Теория#

Проблема: каскадный сбой#

Сервис A зависит от B. B начинает тормозить (latency 5s вместо 50ms). Без предохранителя:

DNS: записи, резолвинг, кэширование, DNS в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

DNS — распределённая иерархическая система имён; резолвер рекурсивно идёт от root → TLD → authoritative, отдавая записи с TTL.
Типы записей: A/AAAA (IP), CNAME (алиас), MX (почта), TXT (метаданные/SPF), NS, SOA, SRV (сервис+порт), PTR (обратный), CAA.
Кэширование на каждом уровне по TTL — отсюда главные продовые боли: устаревшие записи, “залипший” резолв при деплое/failover.
В Go два резолвера: cgo (системный) и чистый Go; выбор влияет на поведение /etc/hosts, /etc/resolv.conf, кэширование (которого в Go-нет по умолчанию).
Прод-грабли: отсутствие кэша в Go → DNS на каждый запрос, негативное кэширование, TTL vs балансировка, DNS-таймауты как причина “медленных” сервисов.

Теория#

Иерархия и резолвинг#

 root (.)
 |
 TLD (.com, .org, .ru)
 |
 authoritative (example.com NS)

Recursive resolver (обычно у провайдера / 8.8.8.8 / внутренний) делает работу за клиента: спрашивает root → получает NS для TLD → спрашивает TLD → получает authoritative NS → получает финальный ответ.
Stub resolver — это сам клиент (getaddrinfo/Go), который шлёт запрос рекурсивному резолверу.
Транспорт: UDP/53 (дефолт), TCP/53 при truncation (флаг TC) или zone transfer. Современное: DoT (DNS over TLS, 853), DoH (DNS over HTTPS, 443).

Типы записей#

Тип	Назначение
A	hostname → IPv4
AAAA	hostname → IPv6
CNAME	алиас на другое имя (нельзя на apex-домене вместе с другими записями)
MX	почтовые серверы (+приоритет)
TXT	произвольный текст: SPF, DKIM, верификации
NS	делегирование зоны на name servers
SOA	параметры зоны (serial, refresh, TTL негатива)
SRV	`_service._proto` → host+port (service discovery)
PTR	обратный резолв IP → имя
CAA	какие CA могут выдавать сертификаты для домена

TTL и кэширование#

Каждая запись несёт TTL — сколько секунд её можно кэшировать.
Кэш на всех уровнях: stub, рекурсивный резолвер, ОС, иногда приложение.
Negative caching: NXDOMAIN тоже кэшируется (TTL берётся из SOA minimum) — поэтому только что созданная запись может “не находиться” какое-то время.
Trade-off TTL: низкий TTL → быстрый failover/смена IP, но больше нагрузки и латентности; высокий TTL → меньше запросов, но медленная пропагация изменений. Перед миграцией TTL заранее снижают.

CNAME-нюансы#

CNAME — алиас, требует доп. резолва на целевое имя.
На apex (корне зоны, example.com) CNAME запрещён стандартом (конфликт с SOA/NS) → провайдеры предлагают ALIAS/ANAME/CNAME flattening.
Цепочки CNAME увеличивают латентность резолва.

DNS в Go#

Go имеет два резолвера:

Escape Analysis: когда переменная убегает в кучу

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

Escape analysis — это анализ компилятора, определяющий, переживёт ли значение функцию, в которой оно создано. Если переживёт (или компилятор не может доказать обратное), значение размещается в куче; иначе — на стеке. Анализ консервативен: при неопределённости выбирается куча. Смотреть решения можно через go build -gcflags="-m" (или -m -m для подробностей). Типовые причины escape: возврат указателя, попадание значения в интерфейс, замыкания, захватывающие переменную по ссылке, слишком большой объект, отправка указателя в канал, передача в fmt.Println (через any).

Graceful Shutdown HTTP/gRPC сервера в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

Graceful shutdown — это управляемая остановка сервиса: перестать принимать новые соединения, дождаться завершения уже идущих запросов (в пределах таймаута), корректно закрыть ресурсы (БД, брокеры, пулы), и только потом завершить процесс. Цель — нулевой даунтайм при деплое и отсутствие оборванных запросов / потерянных данных.
В Go ловим сигналы через signal.NotifyContext (Go 1.16+): он отменяет context.Context при SIGTERM/SIGINT. SIGKILL (kill -9) и SIGSTOP перехватить нельзя — ОС убивает процесс мгновенно.
HTTP: srv.Shutdown(ctx) — мягко (дренаж активных запросов с таймаутом контекста), srv.Close() — жёстко (рвёт всё). ListenAndServe возвращает http.ErrServerClosed при штатной остановке.
gRPC: GracefulStop() — ждёт завершения RPC и дренирует стримы; Stop() — рвёт немедленно. На практике GracefulStop() оборачивают в таймаут с fallback на Stop().
Kubernetes: при удалении пода kubelet шлёт SIGTERM, ждёт terminationGracePeriodSeconds, затем SIGKILL. Главная проблема — race между удалением пода из Endpoints/EndpointSlice и остановкой сервера: трафик ещё долетает после SIGTERM. Решение — preStop hook со sleep + завал readinessProbe.
Правильный порядок: fail readiness → подождать, пока LB/kube-proxy уберут под из ротации → shutdown HTTP/gRPC → закрыть зависимости (БД, очереди).

Теория#

Зачем нужен graceful shutdown#

Когда процесс просто падает (os.Exit, паника, kill -9), все открытые TCP-соединения резко рвутся (RST), активные запросы недоисполняются, транзакции откатываются на стороне БД по таймауту, in-flight сообщения брокера могут потеряться или дублироваться. Для клиента это connection reset / 502 / EOF.

Асимптотическая сложность (Big-O)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Алгоритмы · Уровень: Middle+/Senior

TL;DR#

Big-O описывает асимптотический рост ресурсов (время/память) при росте входа n, отбрасывая константы и младшие члены.
Оцениваем отдельно время и память — оптимизация одного часто ухудшает другое (trade-off).
Амортизированная сложность — средняя стоимость операции на длинной серии (классика: append к слайсу = O(1) амортизированно).
В Go важно знать: append может реаллоцировать и копировать (амортизированно O(1)), доступ к map — O(1) в среднем, сортировка sort.Slice — O(n log n).
На senior ждут не «знаю определение», а умения вывести сложность по коду, заметить скрытые копирования и аллокации, обсудить worst/average/best case.

Теория#

Что такое Big-O формально#

O(f(n)) — множество функций, ограниченных сверху c·f(n) начиная с некоторого n₀. На практике: «как растёт ресурс при стремлении n к бесконечности».

Бенчмарки в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

Бенчмарк — функция BenchmarkXxx(b *testing.B), в которой измеряемый код крутится b.N раз; рантайм сам подбирает b.N, увеличивая его, пока время прогона не станет статистически осмысленным (по умолчанию ~1s, регулируется -benchtime). b.ResetTimer() отсекает дорогой setup, b.ReportAllocs() (или флаг -benchmem) добавляет аллокации/op и байты/op. Результаты нестабильны от прогона к прогону — сравнивать релизы нужно через benchstat по нескольким прогонам (-count), а не по одному числу. Главные ошибки измерений: мёртвый код, который выкидывает компилятор (нужен sink), setup внутри измеряемого цикла, шумная машина, и интерпретация одного прогона как истины.

Буферизованные vs небуферизованные каналы

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Middle+/Senior

TL;DR#

Небуферизованный канал (make(chan T)) — это rendezvous: отправка и приём происходят одновременно, давая строгую синхронизацию (happens-before). Буферизованный (make(chan T, n)) развязывает отправителя и получателя на n элементов, давая пропускную способность и backpressure при заполнении. Размер буфера — это про производительность и поток, не про корректность.

Теория#

Семантика синхронизации#

Небуферизованный: ch <- v завершается только когда другая горутина выполнила <-ch. Это точка синхронизации — гарантия, что приём начался. Memory model: запись отправителя до ch<-v видна получателю после <-ch.
Буферизованный: ch <- v завершается, как только значение положено в буфер (если есть место), не дожидаясь получателя. Happens-before связывает k-ю отправку с (k+cap)-м приёмом (классическое правило из Go Memory Model для ограниченной семафорной семантики).

done := make(chan struct{}) // unbuffered = сигнал «готово»
go func() {
 work()
 done <- struct{}{} // дождётся, пока main прочитает → синхронизация
}()
<-done

Гарантии Go Memory Model (дословно по смыслу)#

Отправка в канал happens-before завершения соответствующего приёма.
Закрытие канала happens-before приёма, вернувшего нулевое значение из-за закрытия.
Для небуферизованного: приём happens-before завершения отправки (приём «начинается раньше»).
k-я отправка в канал ёмкости C happens-before завершения (k+C)-го приёма.

Правило 3 уникально для небуферизованного — поэтому он сильнее как примитив синхронизации.

Взаимоблокировки (Deadlocks) в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

Deadlock — циклическое ожидание блокировок: транзакция A держит ресурс 1 и ждёт ресурс 2, транзакция B держит ресурс 2 и ждёт ресурс 1. Никто не может продвинуться.
PostgreSQL автоматически обнаруживает deadlock через deadlock detector, который запускается, если транзакция ждёт блокировку дольше deadlock_timeout (по умолчанию 1 секунда).
Детектор выбирает одну транзакцию-жертву (victim), откатывает её и возвращает ошибку SQLSTATE 40P01 (deadlock_detected). Остальные продолжают работу.
Главная причина — разный порядок захвата блокировок в разных транзакциях. Главная профилактика — единый порядок (например, всегда блокировать строки ORDER BY id).
Инструменты: единый порядок блокировок, короткие транзакции, SELECT ... FOR UPDATE с ORDER BY, lock_timeout, NOWAIT, SKIP LOCKED.
Диагностика: pg_locks (кто что держит и кто чего ждёт), pg_stat_activity (что выполняет бэкенд, wait_event_type = 'Lock'), а также сообщение в логе PostgreSQL с деталями цикла.
В приложении на Go deadlock — ожидаемая ситуация при конкуренции; правильная реакция — детектировать 40P01 и повторить транзакцию (retry с backoff), а не падать.

Теория#

Что такое deadlock и почему он возникает#

Deadlock (взаимоблокировка) — ситуация, когда две или более транзакций образуют цикл ожидания: каждая держит блокировку, которая нужна другой, и ни одна не может завершиться. Это фундаментальное свойство любой системы с блокировками, а не баг PostgreSQL.

Встраивание структур и интерфейсов (Embedding)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Встраивание (embedding) — это включение анонимного поля типа (структуры, интерфейса, указателя на структуру или любого именованного типа) в другую структуру. Go продвигает (promote) поля и методы встроенного типа во внешний, давая синтаксический сахар, но это композиция, а не наследование: внешний тип не является подтипом внутреннего, динамической диспетчеризации между ними нет, а конфликты имён разрешаются по глубине вложенности. Понимание того, что под капотом это просто доступ к вложенному полю по сгенерированному компилятором пути, снимает почти все вопросы о method promotion, shadowing и неоднозначности.

Как проходит senior-интервью: этапы, оценка, оффер

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Behavioral · Уровень: Senior

TL;DR#

Типичная воронка: рекрутерский скрининг → техническое (coding) → system design → behavioral/leadership → team fit / hiring manager → оффер.
На senior оценивают не «знаешь ли синтаксис», а глубину, trade-off-мышление, влияние на команду и продукт.
System design и behavioral на senior+ часто весят больше, чем алгоритмическая секция.
Вопросы кандидата работодателю — это часть оценки: senior проверяет компанию так же, как компания проверяет его.
Переговоры об оффере — нормальная и ожидаемая часть; не называй цифру первым, опирайся на рынок и весь компенсационный пакет.
Red flags бывают с обеих сторон — умей их читать.

Теория / Подход#

Общая структура воронки#

Конкретика зависит от компании, но скелет почти всегда такой:

Метрики: RED, USE, Golden Signals

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Middle+/Senior

TL;DR#

Три методологии «что мерить»: RED (Rate / Errors / Duration — для request-driven сервисов, Tom Wilkie), USE (Utilization / Saturation / Errors — для ресурсов: CPU, память, диск, пулы, очереди; Brendan Gregg) и Four Golden Signals (Latency / Traffic / Errors / Saturation — Google SRE). RED отвечает «как сервису», USE — «как ресурсу». Для латенси нельзя использовать average: среднее скрывает хвост, чувствительно к выбросам и не композируется. Нужны перцентили (p50/p99/p99.9) и понимание tail amplification (при fan-out на 100 бэкендов p99 каждого задевает почти каждый запрос). Перцентили считают через histogram (histogram_quantile по агрегированным бакетам), потому что готовые квантили нельзя усреднять между инстансами. И сквозная тема — labels/cardinality: лейблы только bounded, иначе взрыв рядов.

Облака (AWS / GCP) для бэкендера

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

Compute — спектр от «управляй сам» до «не думай о серверах»: VM (EC2 / Compute Engine) → контейнеры-оркестратор (ECS, EKS / GKE) → serverless-контейнеры (Fargate, Cloud Run) → FaaS (Lambda / Cloud Functions). Чем правее, тем меньше операционки и тем дороже за единицу вычислений, но дешевле при низкой/рваной нагрузке.
Storage — объектное хранилище S3 / GCS (для файлов, бэкапов, статики, data lake), блочное (EBS / Persistent Disk) для дисков VM. Объектное — не файловая система: нет частичной перезаписи, eventual/strong consistency-нюансы, оплата за объём + запросы + трафик.
Managed DB — RDS / Aurora (AWS), Cloud SQL / AlloyDB / Spanner (GCP). Облако берёт на себя бэкапы, патчи, реплики, failover. Вы платите за удобство и теряете часть контроля (версии, расширения, суперюзер).
Очереди/события — SQS (очередь) + SNS (pub/sub fan-out) в AWS; Pub/Sub в GCP (и то, и другое в одном). Для бэкендера это основа асинхронной обработки, развязки сервисов, ретраев и DLQ.
IAM — кто (principal) может делать что (action) с чем (resource) при каких условиях. Принцип наименьших привилегий. Для сервисов — роли/service accounts, а не статичные ключи; короткоживущие креды через assume-role / Workload Identity.

Теория#

Спектр compute#

Уровень	AWS	GCP	Операционка	Когда
VM	EC2	Compute Engine	вы патчите ОС, масштабируете	legacy, специфичные требования, GPU
Контейнеры + оркестратор	EKS, ECS	GKE	управляете кластером/нодами	микросервисы, сложная маршрутизация
Serverless-контейнеры	Fargate, App Runner	Cloud Run	только образ, без нод	HTTP-сервисы, рваная нагрузка
FaaS	Lambda	Cloud Functions	только функция	события, glue-логика, cron

Для Go-бэкендера типичный выбор сегодня — Cloud Run (GCP) или ECS/Fargate / EKS (AWS): пушишь Docker-образ, платформа крутит и масштабирует.

Docker для Go-разработчика

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

Docker-образ — это набор read-only слоёв (union filesystem, OverlayFS) + JSON-манифест. Каждая инструкция RUN/COPY/ADD создаёт новый слой; ENV/WORKDIR/CMD создают слои-метаданные нулевого размера.
Для Go используйте multistage build: stage сборки на golang:1.x, финальный образ — scratch или gcr.io/distroless/static. Итог: 5–15 МБ вместо 800+ МБ.
Статическая линковка: CGO_ENABLED=0 даёт полностью статический бинарь, который работает в scratch. С CGO нужен glibc/musl в рантайме.
Кэш слоёв ломается на первом изменившемся слое и всех последующих. Поэтому COPY go.mod go.sum и go mod download идут ДО COPY . ..
.dockerignore обязателен: исключает .git, node_modules, локальные бинарники из build context (ускоряет билд и уменьшает риск утечки секретов).
Безопасность: non-root USER, минимальный базовый образ, никаких секретов в слоях, multi-stage чтобы не тащить toolchain.

Теория#

Образы и слои#

Образ состоит из:

gRPC: типы RPC, интерсепторы, контекст, метаданные, error model

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

gRPC — RPC-фреймворк поверх HTTP/2, использующий Protocol Buffers как IDL и формат сериализации (бинарный, schema-first). Один TCP-коннект мультиплексирует множество параллельных стримов (нет head-of-line blocking на уровне приложения).
4 типа RPC: unary (1→1), server streaming (1→N), client streaming (N→1), bidirectional streaming (N→M, полнодуплексный).
Интерсепторы = middleware. Отдельные типы для unary/stream и для client/server. Цепочки строятся через grpc.ChainUnaryInterceptor / ChainStreamInterceptor. Типичные: logging, auth, recovery (panic→codes.Internal), metrics, tracing.
Контекст и дедлайны: context.WithTimeout на клиенте → дедлайн сериализуется в заголовок grpc-timeout → сервер получает его в ctx → дедлайн распространяется по цепочке при дальнейших вызовах. Отмена клиента доходит до сервера (ctx.Done()).
Метаданные (metadata.MD) — пары ключ/значение (≈HTTP-заголовки). FromIncomingContext (чтение на сервере), NewOutgoingContext (отправка с клиента). Различают headers (до тела) и trailers (после тела, для стримов критично).
Error model: ошибки = status.Status с codes.Code + message + опциональные details (google.rpc.*, напр. ErrorInfo, BadRequest). status.Errorf(codes.NotFound, ...). Есть стандартный маппинг codes ↔ HTTP.
gRPC vs REST: gRPC — для внутренних сервис-сервис вызовов (производительность, строгий контракт, streaming); REST/JSON — для публичных/браузерных API. Браузер не умеет gRPC напрямую → gRPC-Web / gRPC-Gateway.

Теория#

1. Что такое gRPC#

gRPC — это контрактно-ориентированный (schema-first) RPC-фреймворк. Ключевые составляющие:

OpenTelemetry

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Senior

TL;DR#

OpenTelemetry (OTel) — это вендор-нейтральный стандарт и набор SDK для сбора телеметрии: traces, metrics, logs (три сигнала + появляющиеся profiles). Ключевая идея — разделить API (стабильный контракт, который вызывает код приложения и библиотеки) и SDK (реализация, которая семплирует, батчит и экспортирует). Данные текут через pipeline: Instrumentation → Provider → Processor → Exporter → Collector → Backend. Collector — отдельный процесс/демон, который принимает (receivers), обрабатывает (processors) и отправляет (exporters) телеметрию, отвязывая приложение от конкретного бэкенда. Context propagation через context.Context + W3C traceparent связывает спаны между сервисами. В Go главные грабли: не забыть Shutdown() (иначе теряются батчи), не плодить cardinality в метриках, прокидывать ctx сквозь весь стек.

Версии HTTP: 1.1, 2, 3

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

HTTP/1.1: текстовый, одно соединение = один запрос в момент времени; keep-alive переиспользует соединение; pipelining почти не работает (HoL blocking); параллелизм достигается множеством TCP-соединений (браузеры ~6 на хост).
HTTP/2: бинарный, мультиплексирование множества потоков по одному TCP, сжатие заголовков (HPACK), приоритеты, server push (по факту устарел). Решает HoL на уровне приложения, но НЕ на уровне TCP.
HTTP/3: HTTP поверх QUIC (UDP+TLS1.3). Убирает HoL на транспорте, быстрый handshake, миграция соединения.
Бэкендеру: gRPC требует HTTP/2; Go net/http сервер и клиент поддерживают h2 автоматически по TLS+ALPN; HTTP/3 — через quic-go/http3.

Теория#

HTTP/1.1#

Текстовый протокол, человекочитаемый, парсится построчно.
Persistent connections (keep-alive) — дефолт в 1.1: соединение не закрывается после ответа, переиспользуется. Управляется Connection: keep-alive/close и таймаутами.
Pipelining: можно отправить несколько запросов, не дожидаясь ответов, НО ответы должны прийти строго по порядку → head-of-line blocking: медленный первый ответ блокирует остальные. На практике pipelining отключён почти везде (баги прокси).
Параллелизм: реальная конкурентность достигается открытием нескольких TCP-соединений (браузеры ~6 на origin). Отсюда хаки вроде domain sharding.
Один запрос/ответ в момент времени на соединение → накладные расходы и затраты на handshake.

HTTP/2#

Бинарный протокол поверх одного TCP-соединения (обычно поверх TLS, ALPN h2):

Индексы в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

B-tree — дефолтный индекс, отсортированное сбалансированное дерево. Работает на =, <, >, BETWEEN, IN, IS NULL, LIKE 'prefix%', ORDER BY. Поддерживает уникальность. 90% случаев — это он.
Hash — только =. С PG 10 WAL-логируется и crash-safe. Чуть компактнее B-tree на равенстве, но без диапазонов и сортировки — почти всегда B-tree предпочтительнее.
GIN — для составных значений: jsonb, массивы (@>, &&), full-text (tsvector @@ tsquery), pg_trgm (LIKE/ILIKE/похожесть). Хранит «значение → список TID». Медленный на запись, очень быстрый на поиск; есть fastupdate (pending list).
GiST — обобщённое дерево для «перекрытий»: геоданные (PostGIS), диапазоны (tsrange &&), kNN (ORDER BY point <-> point), exclusion constraints. Lossy по природе.
SP-GiST — несбалансированные структуры (quadtree, radix), для непересекающихся данных (IP, точки).
BRIN — block range index. Крошечный, хранит min/max по блокам. Только для больших таблиц с физической корреляцией (timestamp append-only). Не точечный — даёт кандидатов на recheck.
Составной индекс: порядок колонок решает всё. Leftmost prefix rule. Equality-колонки слева, range — справа, по последней range-колонке возможен ORDER BY.
Partial (WHERE), covering/INCLUDE (index-only scan + visibility map), expression index (индекс по lower(email)).
Индекс не используется при низкой селективности, функции/каста над колонкой, type mismatch, OR (иногда), LIKE '%x', устаревшей статистике.
Каждый индекс — налог на каждый INSERT/UPDATE/DELETE. HOT-update спасает только если меняемые колонки не индексированы. Настраивай fillfactor, следи за bloat.

Теория#

Зачем индекс и общая модель#

Индекс — это вспомогательная структура данных, которая позволяет находить строки без полного сканирования таблицы (heap). В PostgreSQL индексы отделены от таблицы: индекс хранит ключ + указатель TID (ctid = (block, offset)), указывающий на физическое расположение версии строки в heap.

Канал vs Mutex: когда что выбрать

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

«Share memory by communicating» — это рекомендация, а не догма. Каналы хороши, когда вы передаёте владение данными между горутинами или координируете поток событий/жизненный цикл; мьютекс/atomic хороши, когда вы защищаете разделяемое состояние при коротких операциях. Канал внутри — это структура с мьютексом и очередью, так что он не «бесплатнее» мьютекса. Критерий простой: владение/передача/оркестрация → канал; разделяемое состояние/кэш/счётчик → мьютекс/atomic.

Теория#

Два девиза Go#

«Don’t communicate by sharing memory; share memory by communicating.» — каналы как основной способ координации.
Контр-цитата команды Go: «Use whichever is most expressive and/or most simple.» (Go wiki). Каналы — не самоцель.

Что такое канал на самом деле#

Канал (hchan) — это структура с мьютексом (lock), кольцевым буфером, очередями sendq/recvq парковки горутин. То есть канал реализован поверх блокировок и семафоров рантайма. Поэтому:

Консенсус и Raft: репликация состояния в присутствии отказов

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Консенсус — задача договориться о едином значении/порядке между несколькими узлами так, чтобы решение пережило отказы части узлов. Лежит в основе replicated state machine (RSM): одинаковый детерминированный лог команд -> одинаковое состояние на всех репликах.
FLP impossibility: в асинхронной сети (нет границ на задержки) невозможно гарантировать консенсус при наличии даже одного отказавшего узла, который нельзя отличить от медленного. Практика обходит это через частичную синхронность и таймауты (рандомизированные) — жертвуем гарантированной liveness, сохраняя safety.
Raft — алгоритм консенсуса, спроектированный как understandable альтернатива Paxos. Декомпозиция на три подзадачи: leader election, log replication, safety.
Роли: leader / follower / candidate. Время делится на terms (логические эпохи). В каждом term не более одного лидера; все записи идут только через лидера (leader-only writes).
Запись коммитится, когда её реплицировало большинство (кворум N/2+1). Поэтому нужно нечётное число нод — кворум тот же, а fault tolerance не теряется при чётности.
Применяется в etcd, Consul, CockroachDB (Raft per range), TiKV. ZooKeeper использует ZAB — близкий по духу leader-based atomic broadcast.

Теория#

Зачем нужен консенсус#

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

Лидерство и менторство

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Behavioral · Уровень: Senior

TL;DR#

Senior лидирует без формальной власти: через техническую репутацию, ясность аргументации и помощь другим, а не через приказы.
Менторство — это не «давать ответы», а поднимать самостоятельность: задавать вопросы, давать рамку, отпускать ответственность.
Code review — главный масштабируемый инструмент влияния. Тон, фокус на важном и обучающие комментарии важнее, чем количество найденных проблем.
Архитектурные решения senior принимает с обоснованием и обратимостью: ADR, прототип, понятный trade-off, путь отката.
Техническое влияние измеряется не «я был прав», а «решение приняли и оно сработало», и тем, что другие выросли рядом с тобой.

Теория / Подход#

Лидерство без формальной власти#

На senior у тебя обычно нет людей в подчинении, но есть ожидание, что ты двигаешь команду. Источники влияния:

Ошибки в Go: error, wrapping, errors.Is/As/Join

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

В Go ошибка — это обычное значение, реализующее интерфейс error с единственным методом Error() string. Ошибки конструируются (errors.New, fmt.Errorf), оборачиваются с сохранением причины через %w, образуя цепочку (или дерево при errors.Join/нескольких %w), и инспектируются через errors.Is (сравнение по идентичности/семантике) и errors.As (извлечение конкретного типа). panic предназначен для программных багов и неинвариантных состояний, а не для ожидаемых ошибок. Стандартные ошибки намеренно не несут stacktrace — это сознательный компромисс между стоимостью и информативностью.

Покрытие, -race и флаки-тесты

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

go test -cover показывает процент покрытых строк (точнее — операторов/блоков), -coverprofile=cover.out пишет профиль для go tool cover -html/-func. Покрытие говорит «этот код исполнялся в тестах», но НЕ «он протестирован»: высокий процент при отсутствии ассертов, непокрытые ветки ошибок, неучтённые конкурентные пути — всё это даёт ложную уверенность. go test -race включает детектор гонок (ThreadSanitizer): инструментирует доступы к памяти и ловит data race в рантайме на тех путях, что реально исполнились — обязателен в CI для конкурентного кода. Флаки-тесты (недетерминированно падающие) — следствие гонок, зависимости от времени/порядка/сети, общего состояния; их находят повторными прогонами (-count, -race, -shuffle) и устраняют, а не ретраят вслепую.

Сборщик мусора Go: concurrent tri-color mark-sweep

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

GC в Go — это конкурентный, неперемещающий (non-moving), tri-color mark-sweep сборщик с очень короткими STW-паузами (обычно sub-millisecond). Конкурентность корректна благодаря hybrid write barrier (Dijkstra insertion + Yuasa deletion), появившемуся в Go 1.8, который позволил убрать повторное STW-сканирование стеков. Темп сборки регулирует GC pacer, балансируя момент старта цикла так, чтобы heap не превысил цель GOGC (или мягкий лимит GOMEMLIMIT с 1.19); при отставании mark-фазы горутины-мутаторы платят mark assist. Аллокация идёт через многоуровневую иерархию mcache → mcentral → mheap с разбиением по size classes.

Структуры данных в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Алгоритмы · Уровень: Middle+/Senior

TL;DR#

Go аскетичен: из коробок — слайсы и map. Остальное (container/list, container/ring, container/heap) — в container/*, причём heap это интерфейс над вашим слайсом, а не готовый тип.
На live-coding 90% задач решаются слайсом + map. Stack/queue делаются на слайсе руками. Heap — через container/heap.
linked list, tree, trie, graph пишут вручную через структуры с указателями. Знать обходы и инварианты.
В Go 1.21+ есть slices и maps пакеты (generics) — slices.Sort, slices.Contains, maps.Keys и т.д.
Senior должен знать сложности всех операций, когда какая структура нужна, и подводные камни Go (shared backing array, nil map, random iteration).

Теория#

Массивы и слайсы#

Массив [N]T — фиксированный размер, value-тип (копируется при передаче). Редко используется напрямую. Слайс []T — header {ptr, len, cap} поверх массива; основная рабочая структура.

Фреймворк System Design интервью

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

System design интервью оценивает не «знание решения», а способ мышления: как ты переводишь размытые требования в конкретные числа, как обосновываешь выбор компонентов и где честно проговариваешь trade-offs. Senior-кандидата отличает не количество названных технологий, а умение управлять временем, задавать уточняющие вопросы и связывать решение с бизнес-ограничениями.

Работающий фреймворк на 45 минут:

requirements → estimations → API → data model → high-level → deep dive → scale → trade-offs
 (5') (5') (3') (3') (8') (12') (5') (4')

Главные провалы кандидатов: сразу рисуют боксы без требований, не считают цифры (QPS/storage), не делают deep dive, перечисляют технологии без обоснования и молчат про trade-offs. Senior всегда говорит «зависит от…» и явно называет, от чего именно.

GitHub Actions и GitLab CI

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

GitHub Actions: единица — workflow (.github/workflows/*.yml), внутри jobs, внутри steps. Шаги — это либо shell-команды (run), либо переиспользуемые actions (uses). Jobs по умолчанию параллельны, изолированы (разные раннеры), связываются через needs.
GitLab CI: единица — .gitlab-ci.yml, внутри jobs, сгруппированные по stages. Stages выполняются последовательно, jobs внутри одного stage — параллельно. Артефакты передаются между stages через artifacts/dependencies.
Кэширование обязательно для Go: кэшируем $GOMODCACHE (~/go/pkg/mod) и build cache (~/.cache/go-build). В GH Actions — actions/cache или setup-go с cache: true; в GitLab — cache: с ключом по go.sum.
Матрицы (strategy.matrix / parallel.matrix) гоняют один job по комбинациям (версии Go, ОС, arch).
Секреты: GH — Secrets (repo/org/environment) + OIDC для облаков без статичных ключей; GitLab — CI/CD variables (masked, protected, file). Никогда не печатать в лог.
Концептуально оба про одно: декларативный pipeline-as-code, изолированные раннеры, кэш, артефакты, секреты, матрицы.

Теория#

GitHub Actions: модель#

# .github/workflows/ci.yml
name: CI
on:
 push:
 branches: [main]
 pull_request:

# отмена устаревших запусков на тот же ref
concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

permissions:
 contents: read  # принцип наименьших привилегий для GITHUB_TOKEN

jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-go@v5
 with:
 go-version: '1.22'
 cache: true # кэширует mod cache + build cache по go.sum
 - run: go vet ./...
 - run: go test -race -coverprofile=cover.out ./...
 - uses: actions/upload-artifact@v4
 with:
 name: coverage
 path: cover.out

on — триггеры (push, pull_request, schedule (cron), workflow_dispatch (ручной), tags).
runs-on — тип раннера (GitHub-hosted или self-hosted).
jobs.<id>.needs — зависимости между job (DAG).
uses — переиспользуемый action (всегда пинить версию: @v4 или, безопаснее, по SHA коммита).
GITHUB_TOKEN — автогенерируемый токен; ограничивайте через permissions.

GitHub Actions: stages эмулируются через `needs`#

В GH нет явных stages. Последовательность задаётся графом needs:

JWT (JSON Web Token)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

JWT — это НЕ шифрование, а подпись. Формат header.payload.signature, каждая часть — base64url. Payload читается кем угодно (base64url -d). Никогда не кладите в payload секреты (пароли, PAN-карты, токены доступа к другим системам).
Подпись гарантирует целостность и аутентичность, а не конфиденциальность. Для конфиденциальности нужен JWE (encrypted), а не JWS (signed) — и в 99% случаев это не то, что вам нужно.
HS256 (HMAC) — симметричный, один секрет для подписи и проверки. RS256/ES256 (RSA/ECDSA) — асимметричный: приватным подписывают (auth-server), публичным проверяют (resource-servers). Микросервисы → почти всегда асимметрика + JWKS.
Валидация обязана: проверять подпись, exp/nbf/iat, iss, aud, и whitelisting алгоритма (защита от alg=none и algorithm confusion).
JWT stateless ⇒ отозвать нельзя без внешнего состояния. Решения: короткий TTL access-токена + refresh-токен с ротацией и reuse-detection, либо denylist (Redis) / token version в БД.
Хранение на клиенте: httpOnly+Secure+SameSite cookie, а не localStorage (XSS читает localStorage тривиально).

Теория#

1. Структура#

JWT (а точнее — самая частая его форма, JWS Compact Serialization) состоит из трёх частей, разделённых точками:

Notification Service

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Notification Service — это асинхронный шлюз доставки сообщений пользователям по разным каналам (push, email, SMS, in-app, webhook). Ключевая идея: разделить приём запроса (быстрый, синхронный) и доставку (медленную, ненадёжную, зависящую от внешних провайдеров) через очереди. Senior-сложность сосредоточена не в «отправить письмо», а в:

идемпотентности (один логический event не должен породить два письма даже при ретраях и at-least-once семантике брокера);
ретраях с exponential backoff + jitter и DLQ для poison-сообщений;
rate limiting на провайдера (APNs/SES/Twilio имеют жёсткие квоты, превышение = throttling/бан);
fan-out (один event → миллионы получателей: топик, маркетинговая рассылка);
user preferences / opt-out (нельзя слать туда, где пользователь отписался; compliance — CAN-SPAM, GDPR, TCPA);
per-channel изоляции (деградация SMS-провайдера не должна останавливать push).

Базовый принцип: очередь на канал + пул воркеров + circuit breaker на провайдера + дедупликация в Redis/БД.

Prometheus

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Middle+/Senior

TL;DR#

Prometheus — это TSDB + язык запросов PromQL + pull-модель сбора метрик: сервер сам ходит (scrape) по HTTP-эндпоинтам /metrics целей, обнаруженных через service discovery, и складывает числовые временные ряды. Метрика — это name{label="value"} → значение во времени; уникальная комбинация имени и набора лейблов = один временной ряд (series). Четыре типа: counter (монотонно растёт, мерим через rate()), gauge (произвольно колеблется), histogram (бакеты _bucket{le} + _sum + _count, перцентили считаются на сервере через histogram_quantile, агрегируется между инстансами), summary (квантили считает клиент, НЕ агрегируется). Главный враг senior’а — cardinality explosion: лейбл с неограниченным множеством значений (user_id, request_id, URL с ID) умножает число рядов и убивает память/диск. В Go используем prometheus/client_golang.

TCP/IP: модель, транспорт и что важно бэкендеру

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

TCP/IP — это 4-уровневая модель (Link / Internet / Transport / Application), на практике вместо OSI обсуждают именно её.
TCP даёт надёжную, упорядоченную, байт-ориентированную доставку поверх ненадёжного IP за счёт sequence/ack-номеров, ретрансмиссий и контрольных сумм.
Установка — 3-way handshake (SYN / SYN-ACK / ACK), закрытие — 4-way (FIN/ACK обе стороны), активный закрыватель уходит в TIME_WAIT на 2×MSL.
Flow control = защита получателя (sliding window), congestion control = защита сети (slow start, congestion avoidance, fast recovery, CUBIC/BBR).
Бэкендеру критичны: TIME_WAIT-исчерпание портов, Nagle vs delayed ACK (латентность), TCP keep-alive vs HTTP keep-alive (это разные вещи), backlog очередей accept.

Теория#

Модель TCP/IP vs OSI#

TCP/IP	Аналог OSI	Примеры
Application	L5-L7	HTTP, gRPC, DNS, TLS
Transport	L4	TCP, UDP, QUIC(поверх UDP)
Internet	L3	IP, ICMP, маршрутизация
Link	L1-L2	Ethernet, ARP, MAC

Senior-нюанс: TLS формально живёт между L4 и L7, поэтому в собеседовании TLS обычно относят к “L6-ish” в OSI, но в TCP/IP-модели это просто часть Application.

Дженерики в Go (1.18+)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior+

TL;DR#

Дженерики появились в Go 1.18 и позволяют параметризовать функции и типы по типам (type parameters) с ограничениями (constraints), которые задаются интерфейсами, описывающими множество типов (type set), а не множество методов. Под капотом Go использует не чистую мономорфизацию (как C++/Rust) и не чисто словари (как Java erasure), а гибрид — GC Shape Stenciling: компилятор генерирует по одной инстанцированной копии кода на каждую уникальную «GC-форму» (gcshape) аргумента, а различия в пределах одной формы разрешаются через скрытый словарь (dictionary). Это даёт компактный бинарник, но и неочевидные накладные расходы: дженерики далеко не всегда быстрее интерфейсов и часто теряют девиртуализацию и инлайнинг.

Каналы: устройство hchan

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

Канал — типизированная очередь с синхронизацией, представленная структурой runtime.hchan. Отправка/приём блокируют горутины через парковку (gopark); рантайм поддерживает очереди ожидающих отправителей/получателей и кольцевой буфер. Закрытый канал отдаёт оставшиеся значения, затем нулевые с ok=false; отправка в закрытый — паника; операции с nil-каналом блокируются навсегда.

Теория#

Структура hchan#

// src/runtime/chan.go (упрощённо)
type hchan struct {
 qcount uint // элементов в буфере сейчас
 dataqsiz uint // размер буфера (cap)
 buf unsafe.Pointer // кольцевой буфер (только для буферизованных)
 elemsize uint16
 closed uint32
 elemtype *_type
 sendx uint // индекс записи в буфер
 recvx uint // индекс чтения из буфера
 recvq waitq // очередь ожидающих получателей (sudog)
 sendq waitq // очередь ожидающих отправителей (sudog)
 lock mutex // защищает ВСЕ поля
}

Каждый блокирующийся актёр оборачивается в sudog (G + указатель на элемент). lock — это рантаймовый мьютекс (не sync.Mutex), под ним выполняются все операции с каналом.

Модели согласованности

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Consistency model — это контракт между хранилищем и приложением: какие чтения допустимы при заданной истории операций. Сильнее модель ⇒ проще рассуждать ⇒ дороже по latency/availability.
Linearizability (strong/atomic consistency) — recency-гарантия над одним объектом: как только запись завершилась, все последующие чтения видят её (или более новое значение). Есть единый total order, согласованный с реальным временем.
Serializability — isolation-гарантия над транзакциями (мульти-объектными): результат конкурентного выполнения транзакций эквивалентен какому-то последовательному порядку. Не обязана уважать реальное время.
Strict serializability = serializability + linearizability — эквивалент последовательному порядку, который к тому же уважает реальное время (Spanner: external consistency).
Eventual consistency — слабейшая полезная модель: при прекращении записей реплики сходятся. Ничего не говорит про порядок «во время».
Causal consistency — сохраняет порядок причинно-связанных операций (happens-before); самая сильная модель, достижимая при сохранении доступности во время партиции.
Client-centric / session guarantees: read-your-writes, monotonic reads, monotonic writes, writes-follow-reads — гарантии в рамках сессии одного клиента, удобный компромисс.

Теория#

Зачем нужны модели согласованности#

В одной машине память «просто работает»: записал — прочитал. В распределённой системе с репликами и кэшами «последнее значение» становится неопределённым: чтение с другой реплики может вернуть старое. Модель согласованности формально фиксирует, какие исходы чтений система обещает не допускать. Это нужно, чтобы разработчик мог рассуждать о корректности, не зная деталей репликации.

Нативный fuzzing в Go (1.18+)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

Fuzzing — автоматическая генерация входных данных, нацеленная на расширение покрытия кода (coverage-guided), чтобы найти входы, на которых код паникует, виснет или нарушает инварианты. С Go 1.18 fuzzing встроен в testing: функция FuzzXxx(f *testing.F), seed corpus через f.Add, тело — f.Fuzz(func(t *testing.T, ...){...}). Движок мутирует входы, отслеживая покрытие; найденный падающий вход автоматически минимизируется и сохраняется в testdata/fuzz/FuzzXxx/ как регрессионный кейс. Лучше всего ловит панику на парсерах/декодерах, нарушения round-trip инвариантов (encode→decode) и расхождения с reference-реализацией (differential). Запуск: go test -fuzz=FuzzXxx; без -fuzz fuzz-тест прогоняет только seed corpus как обычный тест.

Специфика live-coding на Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Алгоритмы · Уровень: Middle+/Senior

TL;DR#

На Go-интервью ценят идиоматичность: slices/maps/sort, map[T]struct{} как set, multiple return + comma-ok, ранние возвраты.
Главные ловушки: range копирует значение, shared backing array при slicing, байты vs руны в строках, nil map panic, захват переменной цикла в горутине/замыкании.
Знать stdlib: sort, slices (1.21+), maps, strings, strconv, container/heap. Не изобретать велосипед.
Senior отличают: чистый код, обработка edge cases, понимание аллокаций/escape, написанные тесты (table-driven), проговаривание сложности.

Теория#

Идиоматичные приёмы для алгоритмов#

// comma-ok для map и type assertion:
if v, ok := m[key]; ok { _ = v }

// multiple return — норма, не "костыль":
func minmax(a []int) (mn, mx int) { /* ... */ return }

// set через map[T]struct{} (0 байт на значение):
seen := map[int]struct{}{}
seen[x] = struct{}{}
_, ok := seen[x]

// swap без temp:
a[i], a[j] = a[j], a[i]

// ранний возврат вместо вложенности:
if len(a) == 0 { return nil }

Слайсы: то, что спросят#

s := make([]int, 0, n) // pre-alloc cap — меньше реаллокаций
s = append(s, vals...) // распаковка слайса
b := slices.Clone(s) // независимая копия (Go 1.21+)
s = slices.Delete(s, i, i+1) // удаление с сохранением порядка
idx := slices.Index(s, x) // поиск, -1 если нет
ok := slices.Contains(s, x)
slices.Reverse(s)
mx := slices.Max(s)

// 2D-слайс — правильная инициализация (каждый ряд отдельно!):
grid := make([][]int, rows)
for i := range grid {
 grid[i] = make([]int, cols)
}

Map: то, что спросят#

m := make(map[string]int, hint) // hint = ожидаемый размер
m[k]++ // работает даже если k нет (zero value 0)
delete(m, k)
v := m[absent] // zero value, без panic (для ЧТЕНИЯ)

// детерминированный обход (map рандомизирован!):
keys := make([]string, 0, len(m))
for k := range m {
 keys = append(keys, k)
}
slices.Sort(keys)
for _, k := range keys { _ = m[k] }

// maps пакет (1.21+):
import "maps"
clone := maps.Clone(m)
for k := range maps.Keys(m) { _ = k } // iterator (1.23+)

Строки и руны (UTF-8!)#

Строка в Go — неизменяемая последовательность байтов (UTF-8). Индексация s[i] даёт байт, range даёт руны.

Типовые поведенческие вопросы для Senior

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Behavioral · Уровень: Senior

TL;DR#

Поведенческое интервью проверяет, как ты реально действовал в прошлом, а не как «считаешь правильным». Прошлое поведение — лучший предиктор будущего.
Используй метод STAR: Situation → Task → Result, через Action. 70% времени ответа — на Action и Result.
На senior уровне важны не сами факты, а демонстрация владения (ownership), влияния (impact) и рефлексии: что ты решил, почему, чему научился, что измерил.
Готовь заранее 6–8 «историй» из опыта и переиспользуй их под разные вопросы. Одна сильная история закрывает 3–4 темы.
Цифры и trade-off’ы продают senior’а. «Снизили p99 latency с 1.2s до 180ms» сильнее, чем «улучшили производительность».

Теория / Подход#

Что на самом деле оценивают#

Поведенческая секция — это не «проверка на адекватность». Интервьюер собирает сигналы по компетенциям, которые у компании прописаны в гайде. Для senior это обычно:

Тюнинг GC: GOGC и GOMEMLIMIT

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

GOGC (по умолчанию 100) управляет частотой сборки мусора через целевой размер кучи: heap_target = live_heap * (1 + GOGC/100) — то есть при 100 GC запускается, когда куча удваивается относительно живых данных после предыдущей сборки. GOMEMLIMIT (Go 1.19+) задаёт мягкий лимит на общую память рантайма и заставляет GC работать чаще по мере приближения к нему, страхуя от OOM. Канонический паттерн для контейнеров — GOGC=off (или высокий) + GOMEMLIMIT, установленный на ~90-95% от лимита пода, что даёт минимум GC при нормальной нагрузке и автоматическое уплотнение при пиках. Главная опасность — «death spiral», когда лимит занижен и GC начинает крутиться непрерывно, выжигая CPU.

Уровни изоляции транзакций в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

Стандарт SQL определяет 4 уровня изоляции: Read Uncommitted, Read Committed, Repeatable Read, Serializable — и описывает их через 3 запрещённые аномалии (dirty read, non-repeatable read, phantom read).
Стандарт определяет уровни через аномалии, а не через механизм. PostgreSQL реализует их через MVCC (snapshot isolation), поэтому реальная защита от аномалий строже, чем минимально требует стандарт.
В PostgreSQL фактически три уровня: READ UNCOMMITTED ведёт себя как READ COMMITTED (грязного чтения не существует никогда — MVCC отдаёт только закоммиченные версии строк).
Read Committed (дефолт) — снимок берётся на каждый отдельный statement. Защищает от dirty read, но допускает non-repeatable read, phantom read и lost update между statements.
Repeatable Read в PG — это полноценный snapshot isolation: один снимок на всю транзакцию. Предотвращает dirty/non-repeatable/phantom read (в отличие от стандарта, где RR допускает phantom). Но допускает write skew и при конфликте на запись бросает 40001.
Serializable в PG реализован через SSI (Serializable Snapshot Isolation): отслеживает зависимости чтения/записи через predicate locks (SIReadLock) и откатывает транзакции с serialization_failure (SQLSTATE 40001), нарушающие сериализуемость, включая write skew.
На уровнях RR и Serializable код обязан иметь retry-цикл на 40001 (и 40P01 deadlock). Без него приложение будет случайно падать под нагрузкой.

Теория#

Стандарт SQL: уровни через аномалии#

Стандарт ANSI/ISO SQL не описывает как СУБД должна изолировать транзакции, а только какие аномалии запрещены на каждом уровне. Аномалии:

GOMAXPROCS: параллелизм планировщика и проблема контейнеров

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

GOMAXPROCS задаёт число P (logical processors) в планировщике Go — максимальное количество горутин, выполняющихся на CPU параллельно. Исторически дефолт равнялся числа CPU хоста (runtime.NumCPU()), что в контейнерах с cgroup-лимитом приводило к oversubscription: Go видит, скажем, 64 ядра хоста, а квота — 2 ядра, отсюда лишние context switches, раздутый GC и хвостовая латентность. Решали это библиотекой automaxprocs от Uber; в Go 1.25 runtime стал cgroup-aware и читает CPU-квоту автоматически, периодически её обновляя.

Kubernetes для Go-разработчика

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

Pod — минимальная единица деплоя (1+ контейнеров с общими network namespace и volumes). Поды эфемерны и заменяемы.
Deployment управляет ReplicaSet’ами, обеспечивает rolling update и self-healing. Service даёт стабильный виртуальный IP/DNS и L4-балансировку поверх меняющихся подов. Ingress — L7-роутинг (host/path) снаружи.
ConfigMap — некритичная конфигурация, Secret — чувствительные данные (base64, не шифрование по умолчанию). Монтируются как env или файлы.
Probes: liveness (перезапуск зависшего), readiness (убрать из балансировки, не убивая), startup (для медленного старта, отключает остальные пока не пройдёт).
requests — гарантированный минимум для планировщика, limits — потолок. CPU limit троттлит, memory limit → OOMKill.
Главная Go-проблема: GOMAXPROCS не видит cgroup-лимит CPU — по умолчанию берёт число ядер ноды, что вызывает throttling. Решение: automaxprocs или Go 1.25+ (cgroup-aware runtime). Аналогично GOMEMLIMIT под memory limit.
Graceful shutdown: SIGTERM → дренаж readiness → дослужить запросы → exit до истечения terminationGracePeriodSeconds. preStop хук для синхронизации с балансировщиком.

Теория#

Базовые объекты#

Pod — один или несколько контейнеров, разделяющих сетевой namespace (один IP, общий localhost) и volumes. В norm-практике 1 контейнер на под + sidecar’ы (логи, прокси). Под не переживает перезапуск ноды — его пересоздаёт контроллер.

Middleware-паттерн в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

Middleware в идиоматическом Go — это функция func(http.Handler) http.Handler: она принимает следующий хендлер, оборачивает его и возвращает новый http.Handler. Это декоратор поверх интерфейса http.Handler.
Цепочка строится композицией: Chain(m1, m2, m3)(final). Внешний middleware оборачивает внутренний. На входе порядок прямой (m1 → m2 → m3 → handler), на выходе — LIFO (handler → m3 → m2 → m1), потому что код после next.ServeHTTP выполняется при разворачивании стека.
Захват status code требует обёртки http.ResponseWriter, т.к. интерфейс не отдаёт код наружу. Наивная обёртка теряет http.Flusher, http.Hijacker, http.Pusher — это классический баг.
Порядок критичен: recovery — самым снаружи (ловит панику из всех остальных), CORS — рано (чтобы preflight отработал до auth), auth — до бизнес-логики, rate limit — обычно до тяжёлой работы.
Best practices: middleware должны быть дешёвыми, не блокировать, идемпотентными по эффекту, передавать данные через context.Context (не через мутацию структур), не хардкодить зависимости (внедрять через замыкание/конструктор).
В net/http 1.22+ роутер http.ServeMux умеет методы и path-параметры, но не имеет встроенной поддержки middleware-цепочек — оборачивать mux целиком или использовать chi.

Теория#

1. Каноническое определение#

Middleware — это декоратор над http.Handler. Базовая сигнатура:

MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

PostgreSQL использует MVCC (Multi-Version Concurrency Control): каждое изменение строки создаёт новую физическую версию (tuple), а старая помечается «мёртвой», но физически остаётся на странице до очистки.
Видимость версий определяется системными полями xmin (транзакция-создатель), xmax (транзакция-удалитель), cmin/cmax (command id внутри транзакции) и снапшотом транзакции (xmin, xmax, список активных xip).
Главное следствие: читатели не блокируют писателей, а писатели не блокируют читателей — в отличие от блокировочников (2PL, MySQL MyISAM с table-level locks).
Цена MVCC — dead tuples и bloat (раздувание таблиц/индексов). Их убирает VACUUM (помечает место как переиспользуемое + freezing против wraparound) и autovacuum (автоматически).
VACUUM обычный не отдаёт место ОС и не блокирует; VACUUM FULL переписывает таблицу (ACCESS EXCLUSIVE lock), отдаёт место, но кладёт нагрузку. Для онлайн-дефрагментации — pg_repack.
32-битный xid (2^31 «прошлых» транзакций) требует freezing, иначе transaction id wraparound = катастрофа. HOT updates снижают bloat индексов.

Теория#

Зачем нужен MVCC: блокировочники vs многоверсионники#

В классических блокировочных СУБД (двухфазная блокировка, 2PL) согласованность чтения обеспечивается блокировками: транзакция, читающая строку, ставит shared-lock, что мешает писателям; писатель ставит exclusive-lock, что мешает читателям. Крайний случай — MySQL MyISAM, где блокировки уровня таблицы: один писатель останавливает всех.

Order Service

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Order Service — это «оркестратор истины» о заказе: он владеет состоянием заказа (state machine), координирует резервирование товара (inventory), оплату (payment) и доставку (shipping). Главная сложность — не CRUD, а согласованность между сервисами без распределённой транзакции 2PC. Решение: state machine + saga (orchestration) + outbox + идемпотентность + reserve-with-TTL для inventory. Ключевые враги: oversell на hot SKU, дубли заказов при ретраях, «застрявшие» саги, и UX поверх eventual consistency. На senior+ копают именно границы консистентности: где вы допускаете рассинхрон, как его чините (reconciliation), и почему не выбрали 2PC.

SLI / SLO / SLA

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Senior

TL;DR#

SLI (Service Level Indicator) — измеримая метрика поведения сервиса с точки зрения пользователя: доля успешных запросов, доля быстрых запросов, свежесть данных. Формула почти всегда good events / valid events.
SLO (Service Level Objective) — целевое значение SLI на окне времени: «99.9% запросов за 30 дней успешны». Внутренняя цель команды.
SLA (Service Level Agreement) — юридический/контрактный обязательство перед клиентом с компенсациями (refund, credits). SLA обычно слабее SLO (если SLO=99.9%, SLA=99.5%), чтобы у команды был запас.
Error budget = 1 − SLO. При SLO 99.9% бюджет ошибок = 0.1% запросов за окно. Бюджет — это разрешённое количество «плохого», которое можно тратить на риск (релизы, эксперименты).
Burn rate — скорость расходования бюджета. Алертить надо НЕ на «упал один запрос», а на скорость прожигания бюджета через multi-window multi-burn-rate алерты (быстрый + медленный burn). Это даёт высокий precision и recall и убирает шум.
SLI выбирают по принципу: метрика должна отражать опыт пользователя, быть измеримой на границе, где пользователь «видит» сервис, и иметь чёткий критерий good/bad.

Теория#

Зачем вообще SLO, а не «аптайм 100%»#

100% надёжности — недостижимая и вредная цель: каждый «девятка» удорожает систему экспоненциально, а пользователь всё равно ограничен надёжностью своего Wi-Fi, DNS, браузера. SLO — это инженерный компромисс: формальное согласие команды и бизнеса о том, какой уровень ненадёжности приемлем. Из этого согласия рождается error budget — единый язык для конфликта «фичи vs стабильность». Пока бюджет есть — катим релизы; бюджет исчерпан — фриз фич и работа над надёжностью.

TLS: handshake, сертификаты, mTLS, производительность

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

TLS даёт конфиденциальность (шифрование), целостность (MAC/AEAD) и аутентификацию (сертификаты) поверх TCP.
TLS 1.3 — 1-RTT handshake (vs 2-RTT в 1.2), 0-RTT на возобновлении, выкинул небезопасные шифры (RSA key exchange, CBC, RC4), всегда forward secrecy (ECDHE).
Доверие — через цепочку сертификатов до доверенного корневого CA; сервер шлёт leaf + промежуточные, клиент проверяет до корня.
SNI позволяет хостить много доменов на одном IP (выбор сертификата); ALPN согласует протокол (h2/h3/http1.1) в рамках handshake.
mTLS — взаимная аутентификация: клиент тоже предъявляет сертификат (zero-trust, service mesh).
В Go всё в crypto/tls: tls.Config, tls.Certificate, RootCAs, ClientCAs, ServerName, NextProtos.

Теория#

Что даёт TLS#

Конфиденциальность — симметричное шифрование сессии (AES-GCM, ChaCha20-Poly1305).
Целостность — AEAD (шифрование + аутентификация в одном).
Аутентификация — проверка сертификата сервера (и опц. клиента) через PKI.

Handshake: TLS 1.2 vs 1.3#

TLS 1.2 (2-RTT):

Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Гарантии доставки определяются тем, когда отправляется ack: до обработки (at-most-once, риск потери) или после (at-least-once, риск дублей).
at-most-once — каждое сообщение доставляется 0 или 1 раз (никогда не дублируется, но может потеряться).
at-least-once — 1+ раз (никогда не теряется, но возможны дубли). Это дефолт большинства брокеров.
exactly-once delivery — миф. Нельзя атомарно «доставить сообщение и зафиксировать ack» через ненадёжную сеть (проблема двух генералов, FLP-невозможность консенсуса в асинхронной модели).
То, что в индустрии называют exactly-once, на практике есть effectively-once / exactly-once processing = at-least-once delivery + идемпотентность + дедупликация (dedup по message id, idempotent consumer).
Kafka EOS реализует это инженерно: idempotent producer (PID + sequence number), транзакции (transactional.id, atomic read-process-write), isolation.level=read_committed на консьюмере.
2PC даёт атомарность распределённого commit, но это блокирующий протокол: отказ координатора в фазе uncertainty подвешивает участников с захваченными локами. 3PC добавляет pre-commit (неблокирующий), но ломается при network partition.

Теория#

Что вообще гарантируется и где#

«Гарантия доставки» — характеристика контракта между отправителем (producer), брокером/каналом и получателем (consumer). Важно различать три уровня:

Интеграционные тесты, testcontainers-go, TestMain

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

Интеграционные тесты проверяют код против реальных зависимостей (БД, брокеры, кэши), а не моков. testcontainers-go поднимает эти зависимости в Docker-контейнерах на лету: тест получает реальный Postgres/Redis/Kafka с динамическим портом, использует его и уничтожает контейнер по завершении — без ручного docker-compose и без общей «тестовой» БД. TestMain(m *testing.M) даёт единую точку setup/teardown на весь пакет (один контейнер на пакет — баланс скорости и изоляции). Медленные/требующие Docker тесты отделяют от unit-тестов через build tags (//go:build integration) или testing.Short(), чтобы go test ./... оставался быстрым, а интеграционные шли отдельным шагом CI. Изоляция между тестами — через отдельные схемы/БД/префиксы, транзакции с откатом или truncate.

Интерфейсы в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Интерфейс в Go — это «толстый указатель» из двух слов: дескриптор типа и указатель на данные. Непустой интерфейс представлен структурой iface (с таблицей методов itab), пустой — eface. Главная ловушка senior-уровня: интерфейс с конкретным типом, но nil-значением внутри — НЕ равен nil. Удовлетворение интерфейса проверяется статически и структурно (duck typing).

Теория#

Внутреннее устройство: eface и iface#

Любая переменная интерфейсного типа в рантайме — это структура из двух машинных слов (на amd64 — 16 байт).

Утечки горутин, дедлоки, livelock, starvation

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

Главные болезни конкурентного Go: deadlock (взаимная блокировка — никто не двигается), livelock (горутины активны, но прогресса нет), starvation (горутина не получает ресурс), и goroutine leak (горутина навсегда заблокирована и не собирается GC). Чаще всего утечки происходят из-за каналов: отправка без получателя, чтение из канала, который никто не закроет, отсутствие ветки ctx.Done(). Диагностика — runtime.NumGoroutine, goroutine-профиль pprof, дамп стеков (SIGQUIT), go test -race и встроенный детектор полного дедлока.

Eventual Consistency

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Eventual consistency — гарантия, что при отсутствии новых записей все реплики в конце концов сойдутся к одному значению. Это слабая модель: нет гарантий, когда сойдутся и что прочитает клиент в промежутке. Приемлема там, где временное расхождение не ломает бизнес (лайки, счётчики просмотров, ленты, профили), и опасна там, где нужна линеаризуемость/сильная согласованность (деньги, остатки на складе, уникальность) — там нужны транзакции, кворумы или CRDT с подходящей семантикой. Ключевые механизмы: разрешение конфликтов (LWW — просто, но теряет данные при clock skew; vector clocks / version vectors — детектят causality и concurrent; CRDT — структуры, конфликты которых разрешаются автоматически и детерминированно), и репликация/восстановление (read repair, anti-entropy через Merkle trees и gossip, hinted handoff в стиле Dynamo).

net/http: Server, Handler, ServeMux, таймауты, Client и контекст

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

http.Server — это конфигурация сервера; ListenAndServe запускает accept-loop, на каждое соединение создаётся отдельная горутина (conn.serve).
Handler — интерфейс с единственным методом ServeHTTP(w, r). HandlerFunc — адаптер, превращающий обычную функцию в Handler.
В Go 1.22 ServeMux научился методам и wildcard-паттернам: "GET /items/{id}", {path...}, доступ через r.PathValue("id"), есть детерминированный приоритет специфичности и паника при конфликтах.
Таймауты — обязательны в проде. Дефолтный http.Server без таймаутов уязвим к Slowloris (медленные клиенты держат соединения вечно). Минимум: ReadHeaderTimeout, ReadTimeout, WriteTimeout, IdleTimeout.
http.Client и http.Transport потокобезопасны и переиспользуют TCP/TLS-соединения через пул. Создавать клиент на каждый запрос — антипаттерн (утечка соединений и портов). Всегда defer resp.Body.Close() и вычитывать тело до конца.
r.Context() отменяется при разрыве клиентского соединения и при истечении server-таймаутов. context.WithValue — только для request-scoped данных, не для DI и не для опциональных параметров.

Теория#

http.Server: поля и accept loop#

http.ListenAndServe(addr, handler) — это удобная обёртка, которая создаёт &http.Server{Addr: addr, Handler: handler} без единого таймаута. В проде так делать нельзя — нужно конфигурировать http.Server явно.

Payment Service

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Платёжный сервис — это система, где корректность важнее доступности, а потеря или дублирование денег недопустимы. Три кита:

Идемпотентность — клиент шлёт Idempotency-Key, сервер гарантирует, что повтор запроса (ретрай, таймаут, двойной клик) не спишет деньги дважды. Реализуется через уникальный индекс в БД.
Double-entry ledger — деньги не «хранятся» как баланс, а выводятся из неизменяемого (append-only) журнала проводок debit/credit, где сумма всех проводок транзакции равна нулю.
Transactional outbox + CDC — события («платёж проведён») публикуются в брокер строго на основе закоммиченного состояния БД, что даёт exactly-once effect поверх at-least-once delivery брокера.

«Exactly-once деньги» — это не магия брокера, а at-least-once доставка + идемпотентные обработчики. Деньги всегда в целочисленных minor units (копейки/центы), никогда во float.

sync.Cond

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

sync.Cond — условная переменная: горутина под захваченным мьютексом вызывает Wait, чтобы заснуть до тех пор, пока другая горутина не вызовет Signal (разбудить одну) или Broadcast (разбудить всех). Нужна редко: почти всё решается каналами. Реальная ниша — широковещательное пробуждение многих ожидающих по изменению разделяемого состояния, где каналы неудобны. Wait обязан вызываться в цикле проверки условия из-за spurious-подобных пробуждений и гонок.

Теория#

Контракт#

c := sync.NewCond(&sync.Mutex{})

// Ожидающая сторона
c.L.Lock()
for !condition() { // ВСЕГДА в цикле, не if
 c.Wait() // атомарно: Unlock(L) + park; при пробуждении: Lock(L)
}
useState()
c.L.Unlock()

// Сигнализирующая сторона
c.L.Lock()
changeState()
c.L.Unlock()
c.Signal() // или c.Broadcast()

Wait() атомарно отпускает мьютекс и паркует горутину; при пробуждении снова захватывает мьютекс перед возвратом. Поэтому Wait вызывается строго под Lock.
Signal() будит одну ожидающую горутину (если есть).
Broadcast() будит все ожидающие горутины.
Сигнал/Broadcast можно вызывать с захваченным мьютексом или без — но менять защищаемое состояние нужно под мьютексом.

Почему `for`, а не `if`#

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

Terraform / Infrastructure as Code

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: DevOps · Уровень: Middle+/Senior

TL;DR#

IaC — инфраструктура описана кодом, версионируется в git, применяется детерминированно. Уходим от ручного «кликанья в консоли» (snowflake-серверов) к воспроизводимым, ревьюимым изменениям.
Terraform декларативен: вы описываете желаемое состояние, движок сам считает дельту между ним, текущим состоянием (state) и реальностью (refresh) и применяет минимальный набор изменений.
State — JSON-файл, сопоставляющий ресурсы в коде с реальными объектами в облаке (по ID). Без него Terraform не знает, что уже создано. Хранить удалённо (S3+DynamoDB, GCS, Terraform Cloud) с блокировкой (lock), иначе два одновременных apply испортят инфраструктуру.
Цикл: init (плагины+бэкенд) → plan (dry-run, показывает дельту) → apply (применяет). plan обязателен в review.
Providers — плагины к API (aws, google, kubernetes). Modules — переиспользуемые наборы ресурсов с input/output. Drift — расхождение реальности и state (кто-то поменял руками).
Best practices: remote state с локом, маленькие изолированные state’ы, модули, отсутствие секретов в state/коде в открытом виде, plan в CI, иммутабельность.

Теория#

Декларативность и граф зависимостей#

Вы пишете, что должно быть, а не как это сделать (в отличие от императивных скриптов). Terraform строит граф зависимостей ресурсов (по ссылкам resource.attr) и применяет их в правильном порядке, параллеля независимые.

UDP и надёжность поверх UDP

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

UDP — простой датаграммный транспорт: нет соединения, нет гарантий доставки/порядка, нет flow/congestion control. Только порты + контрольная сумма.
Плюсы: минимальная латентность и накладные расходы, отсутствие head-of-line blocking, broadcast/multicast, контроль над семантикой надёжности на стороне приложения.
Применять: DNS, DHCP, NTP, VoIP/видео (RTP), realtime-игры, метрики (statsd), service discovery, QUIC.
“Надёжность поверх UDP” = QUIC (HTTP/3), а также кастомные протоколы (ACK, ретрансмиты, FEC, sequence numbers) — вы переносите логику TCP в userspace.
В Go: net.UDPConn, ReadFromUDP/WriteToUDP, net.ListenPacket. Один сокет обслуживает множество “пиров”.

Теория#

UDP в двух словах#

Заголовок UDP — всего 8 байт: source port, dest port, length, checksum. Никакого состояния. Каждый WriteToUDP = одна датаграмма = (обычно) один IP-пакет.

Моки, стабы и тестируемость

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

В Go тестируемость строится на интерфейсах, объявленных на стороне потребителя (узких, в 1-3 метода), и dependency injection через конструкторы/поля структуры. Терминология: стаб возвращает заранее заданные ответы; мок дополнительно проверяет, как и сколько раз его вызвали (verify expectations); fake — упрощённая рабочая реализация (in-memory БД); spy — записывает вызовы для последующей проверки. Варианты: ручные моки (явные, читаемые, без зависимостей — идиоматичный дефолт для узких интерфейсов), gomock (кодогенерация, строгие expectations, контроль порядка), testify/mock (рефлексия, гибко, но рантайм-ошибки и многословно). Принцип Go: «accept interfaces, return structs», интерфейс определяет тот, кто его использует, а не тот, кто реализует.

Обзор NoSQL и Redis

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

NoSQL — это не «отсутствие схемы», а класс хранилищ с разными моделями данных, оптимизированных под конкретные паттерны доступа: Key-Value (Redis, DynamoDB), Document (MongoDB), Wide-column (Cassandra, HBase), Graph (Neo4j). Выбор движется от паттернов запросов, а не от данных.
SQL vs NoSQL — не «или-или». SQL даёт строгую схему, JOIN-ы, ACID, нормализацию; NoSQL — горизонтальное масштабирование, гибкую схему, денормализацию под чтение. По CAP при сетевом разделении (P неизбежно) выбираешь между C и A; многие NoSQL — это AP с BASE-семантикой (eventual consistency), но это конфигурируемо (Cassandra tunable consistency, DynamoDB strongly consistent reads).
Redis — однопоточное (для исполнения команд) in-memory хранилище структур данных. Сила не в «кэше», а в богатых структурах: String, List, Hash, Set, ZSET, Bitmap, HyperLogLog, Stream, geo. Атомарность каждой команды — следствие single-threaded модели.
Персистентность: RDB (снапшоты, компактно, риск потери данных между снапшотами), AOF (журнал команд, durability до appendfsync everysec/always), гибрид (RDB-преамбула + AOF-хвост) — дефолт в Redis 7.
Кэширование: cache-aside (самый частый), write-through/write-back; проблемы — thundering herd / cache stampede (защита: lock на пересчёт, jitter в TTL, early recomputation), stale data / invalidation.
Distributed lock: SET key val NX PX ttl + unlock через Lua (проверка владельца). Redlock спорен (критика Martin Kleppmann — fencing token нужен всё равно); для строгих гарантий не полагайся только на TTL-lock.
Rate limiting: token bucket / sliding window log / sliding window counter на Redis + Lua для атомарности.
Масштабирование: репликация (async, replica может отставать), Redis Cluster (16384 хеш-слота, без multi-key операций между слотами без hash tags). Eviction: allkeys-lru, allkeys-lfu, volatile-*, noeviction.

Теория#

Часть 1. NoSQL#

Что такое NoSQL и зачем он появился#

Реляционные СУБД оптимизированы под нормализованные данные, произвольные запросы (ad-hoc) и строгую консистентность на одном узле. Проблемы возникают при:

Структурированное логирование (slog)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Middle+/Senior

TL;DR#

Структурированное логирование = логи как набор key-value (обычно JSON), а не текстовая строка → машинно-парсятся, фильтруются и агрегируются в Loki/ELK по полям. В Go 1.21+ это стандарт log/slog: Logger → Handler (JSONHandler/TextHandler/кастомный) → Record из Attr. Уровни через slog.LevelVar можно менять в рантайме без рестарта. Контекстные поля добавляются через With/WithGroup. Ключевая senior-практика — корреляция: кастомный Handler достаёт trace_id/span_id из context.Context (OTel SpanContext) и пишет в каждую запись через InfoContext. PII не логировать (пароли, токены, карты, email) — маскировать через LogValuer или ReplaceAttr. При высоком RPS — sampling/rate-limiting логов. Производительность: slog имеет zero-alloc путь при использовании типизированных Attr и ленивых LogValuer, плюс проверку Enabled, чтобы не вычислять дорогие поля при отключённом уровне.

Устройство map в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

map в Go — это хэш-таблица с разрешением коллизий методом цепочек через «бакеты», где каждый бакет хранит до 8 пар key/value. Таблица растёт инкрементально (эвакуация бакетов происходит порциями при записи/удалении), порядок итерации намеренно рандомизирован, map не потокобезопасна (конкурентная запись приводит к нерекаверабельному fatal error), и нельзя брать адрес элемента, потому что реаллокация при росте инвалидирует указатели. В Go 1.24 классическая реализация заменена на Swiss Tables.

Утечки горутин (goroutine leaks)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

Утечка горутины — это горутина, которая никогда не завершается и не освобождается рантаймом, потому что навсегда заблокирована на канале/мьютексе/системном вызове или крутится в бесконечном цикле без условия выхода. Каждая утёкшая горутина удерживает свой стек (минимум 2 КБ, растёт сегментами) плюс всё, что захвачено через замыкание, поэтому утечки проявляются как медленный рост памяти и runtime.NumGoroutine(). Главные инструменты диагностики — pprof goroutine profile и дамп по SIGQUIT/debug=2; главная профилактика — context.Context, errgroup и чёткий контракт «кто закрывает канал».

context

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

context.Context переносит сигнал отмены, дедлайн и request-scoped значения сквозь границы вызовов и горутин. Корни — Background()/TODO(); производные — WithCancel/WithTimeout/WithDeadline/WithValue. Отмена распространяется по дереву контекстов вниз; всегда вызывайте cancel() (обычно через defer), чтобы не текли ресурсы.

Теория#

Иерархия и корни#

context.Background() — пустой корень для main, init, тестов; никогда не отменяется.
context.TODO() — заглушка, когда непонятно, какой контекст передать; семантически = Background, но сигнализирует «надо доделать».
Производные образуют дерево: отмена/дедлайн родителя каскадно отменяет детей.

ctx, cancel := context.WithCancel(parent)
defer cancel() // ОБЯЗАТЕЛЬНО: освобождает горутину/таймер и удаляет из дерева

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel()

ctx, cancel := context.WithDeadline(parent, time.Now().Add(time.Second))
defer cancel()

ctx := context.WithValue(parent, key, val) // без cancel

Интерфейс#

type Context interface {
 Deadline() (deadline time.Time, ok bool)
 Done() <-chan struct{} // закрывается при отмене/дедлайне
 Err() error // nil | Canceled | DeadlineExceeded
 Value(key any) any
}

Done() возвращает канал, который закрывается (broadcast) при отмене. Err() после закрытия даёт причину: context.Canceled или context.DeadlineExceeded.

Distributed Tracing

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Observability · Уровень: Middle+/Senior

TL;DR#

Distributed tracing восстанавливает путь одного запроса через множество сервисов как дерево/DAG спанов. Trace = набор спанов с общим trace_id; span = одна операция (start/end/attributes/events/status/kind), ссылающаяся на родителя. Связь между сервисами держится на context propagation: W3C traceparent (= version-trace_id-span_id-flags) инжектится в исходящие заголовки и извлекается на входе. Sampling решает, какие трейсы хранить: head-based (решение на старте, дёшево, но может пропустить редкие ошибки) или tail-based (решение после завершения трейса в коллекторе — можно отобрать по latency/error, но дорого по памяти/буферизации). Чтение трейса = поиск critical path, gaps (сеть/блокировки/GC), fan-out и N+1. Корреляция: trace_id в логах, exemplars из метрик в трейс. Senior-грабли: разрыв контекста на context.Background(), потеря спана в горутине без ctx, clock skew, и RecordError ≠ SetStatus.

OAuth2: роли, grant types, OIDC, токены и типовые ошибки

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

OAuth2 — это про авторизацию (делегированный доступ), а НЕ про аутентификацию. Он отвечает на вопрос «можно ли этому клиенту делать X от имени пользователя», а не «кто этот пользователь». Аутентификацию поверх OAuth2 даёт OIDC (OpenID Connect) через id_token.
4 роли: Resource Owner (пользователь), Client (приложение), Authorization Server (выдаёт токены), Resource Server (API, проверяет токены).
Основной flow сегодня — Authorization Code + PKCE для всех типов клиентов (web, SPA, mobile, desktop). Client Credentials — для machine-to-machine без пользователя. Refresh Token grant — для обновления access token без повторного логина.
Deprecated: Implicit (утечка токена через URL/Referer, отсутствие refresh) и Resource Owner Password Credentials (anti-pattern — клиент видит пароль пользователя).
access token — короткоживущий (минуты), bearer, передаётся в API. refresh token — долгоживущий, хранится максимально защищённо, обменивается на новый access token.
Безопасность держится на: state (CSRF), PKCE (перехват кода), строгая валидация redirect_uri (open redirect), проверка aud/iss/exp/подписи токена на Resource Server.

Теория#

1. OAuth2 ≠ аутентификация#

Самая частая концептуальная ошибка. OAuth2 (RFC 6749) спроектирован как протокол делегированной авторизации: ресурс-овнер разрешает третьему приложению (клиенту) доступ к своим ресурсам на Resource Server без передачи пароля.

panic / recover: механика, раскрутка стека и runtime-паники

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

panic начинает раскрутку стека текущей горутины, по пути выполняя зарегистрированные defer. recover останавливает раскрутку и возвращает значение паники, но работает только при прямом вызове из отложенной функции — иначе возвращает nil и эффекта не имеет. Паника в любой горутине, не пойманная её собственным defer/recover, убивает весь процесс — поймать её из другой горутины нельзя. Часть runtime-ошибок (nil deref, index out of range) — это обычные паники и их можно восстановить; часть (concurrent map writes, deadlock, нехватка памяти) — это fatal errors и они принципиально не recoverable.

Rate Limiter

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Rate Limiter ограничивает число запросов от клиента (по ключу: user_id, API-key, IP) за единицу времени. Базовый ответ при превышении — HTTP 429 Too Many Requests с Retry-After. Ключевой выбор — алгоритм (точность vs память) и место размещения (gateway/middleware/sidecar). В распределённой системе состояние обычно держат в Redis с атомарными операциями через Lua-скрипты; для снижения нагрузки на Redis применяют гибрид local + global (локальный токен-бакет на ноде + периодическая синхронизация).

Table-driven тесты, subtests и параллельность

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Тестирование · Уровень: Middle+/Senior

TL;DR#

Table-driven тесты — идиоматичный для Go способ покрыть множество входов/выходов одной логикой проверки: срез структур-кейсов + цикл. t.Run создаёт subtests — изолированные узлы дерева тестов с собственным именем, фильтрацией (-run Foo/case_x) и независимым fail. t.Parallel() помечает тест как параллельный: он приостанавливается, пока не завершатся последовательные тесты родителя, затем запускается одновременно с другими параллельными. Главная историческая ловушка — захват переменной цикла замыканием (tc); в Go < 1.22 это давало все кейсы с последним значением. В 1.22+ переменная цикла per-iteration, ловушка ушла, но на собеседовании про неё всё равно спрашивают.

WebSocket: upgrade, фреймы, масштабирование

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

WebSocket (RFC 6455) — полнодуплексный двунаправленный канал поверх одного TCP, устанавливается HTTP Upgrade-рукопожатием, затем переходит на бинарный фрейм-протокол.
Использует тот же порт (80/443), проходит прокси/файрволлы как HTTP; после upgrade — это уже не HTTP.
Фреймы: text/binary/ping/pong/close + fragmentation; клиент обязан маскировать payload.
Выбирать вместо polling/SSE, когда нужна низкая латентность И двунаправленность (чат, игры, коллаборация). SSE достаточно для server→client односторонних потоков.
Масштабирование — главная боль: stateful соединения, sticky-сессии или pub/sub-бэкплейн (Redis/NATS/Kafka), лимиты на FD/память.
В Go: gorilla/websocket (де-факто, но архивный) и coder/websocket (бывш. nhooyr.io/websocket, контекст-aware, рекомендуемый).

Теория#

Установка: HTTP Upgrade#

GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat # опц. субпротоколы

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= # SHA1(key+GUID), base64

После 101 соединение перестаёт быть HTTP — дальше бинарные WS-фреймы.
Sec-WebSocket-Accept = base64(SHA1(client_key + magic_GUID)) — подтверждает, что сервер понял WS (защита от случайного апгрейда кешами).
Поверх TLS — это wss:// (рекомендуется всегда).
HTTP/2 имеет своё расширение для WS (RFC 8441, CONNECT), но классика — поверх h1.

Структура фрейма#

FIN бит (последний фрейм сообщения) + opcode: 0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong, 0x0 continuation.
MASK бит + 32-битный masking key: клиент → сервер фреймы ОБЯЗАНЫ быть замаскированы (XOR), сервер → клиент — нет. Это защита от cache-poisoning через прокси.
Payload length: 7 / 7+16 / 7+64 бит (расширяемая длина).
Fragmentation: большое сообщение можно слать частями (FIN=0 у промежуточных).

Ping/Pong (keep-alive на уровне WS)#

Control-фреймы ping/pong для проверки живости и удержания соединения (NAT, прокси-таймауты).
На ping peer обязан ответить pong (с тем же payload).
Сервер обычно периодически шлёт ping и закрывает соединение, если нет pong в дедлайн → детект мёртвых клиентов. TCP keep-alive здесь недостаточно надёжен/быстр.

WebSocket vs SSE vs Polling#

	Long Polling	SSE	WebSocket
Направление	client↔server (через переоткрытие)	server→client	полный дуплекс
Транспорт	HTTP	HTTP (text/event-stream)	TCP после upgrade
Латентность	высокая	низкая	низкая
Авто-reconnect	вручную	встроен (Last-Event-ID)	вручную
Бинарные данные	да	нет (только текст/UTF-8)	да
Через HTTP/2 мультиплекс	да	да	сложнее
Сложность/инфра	низкая	низкая	высокая (stateful)

Правило: нужен только server→client (нотификации, прогресс, котировки) — бери SSE (проще, авто-reconnect, обычный HTTP). Нужен дуплекс/низкая латентность в обе стороны (чат, игры, совместное редактирование) — WebSocket.

Идемпотентность в распределённых системах

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Идемпотентность — повторное выполнение операции с теми же параметрами даёт тот же результат и те же побочные эффекты, что и однократное. f(f(x)) == f(x) на уровне состояния системы.
Нужна потому, что сеть ненадёжна: клиент не знает, дошёл ли запрос. Любая система с ретраями и доставкой at-least-once обязана быть идемпотентной, иначе дубли (двойные списания, двойные заказы).
HTTP: GET, PUT, DELETE, HEAD, OPTIONS идемпотентны по семантике спецификации; POST и PATCH — нет. Спецификация не гарантирует реализацию.
Практика для не-идемпотентных операций: idempotency key — клиент генерирует уникальный ключ, сервер хранит (key → результат, статус) и при повторе отдаёт сохранённый ответ вместо повторного выполнения.
Самое сложное — конкурентные запросы с одним ключом (in-flight). Решается через unique constraint или distributed lock + конечный автомат статусов processing → completed/failed.
На уровне БД идемпотентность достигается через UPSERT, INSERT ... ON CONFLICT, unique constraints, INSERT ... WHERE NOT EXISTS.

Теория#

Зачем нужна идемпотентность#

В распределённой системе невозможно отличить «запрос не дошёл» от «ответ не дошёл». Это фундаментальная проблема two generals: клиент отправил POST /payments, получил таймаут. Что произошло?

Партиционирование таблиц в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

Декларативное партиционирование (PARTITION BY, появилось в PG 10, доработано в 11–14) разбивает одну логическую таблицу на физические партиции по ключу. Три стратегии: RANGE (диапазоны, чаще всего для time-series), LIST (явные списки значений), HASH (равномерное распределение по остатку хеша).
Главная выгода — управление жизненным циклом данных: удаление старых данных через DROP TABLE/DETACH PARTITION (метаданные, мгновенно) вместо DELETE (миллионы строк, dead tuples, нагрузка на vacuum). Плюс partition pruning — планировщик отсекает ненужные партиции и сканирует только релевантные.
Partition pruning работает только если ключ партиционирования присутствует в WHERE (или вычислим из условий). Есть pruning на этапе планирования (constraint exclusion / новый механизм) и runtime pruning для параметров prepared statements и nested loop.
Ключевое ограничение: любой PRIMARY KEY / UNIQUE обязан включать колонки ключа партиционирования. Глобальных уникальных индексов нет. FK на партиционированную таблицу можно (с PG 12), FK из партиционированной — тоже.
Партиционирование — не про “ускорить любой запрос”, а про обслуживаемость больших таблиц, локальность горячих данных и дешёвое удаление. Запросы без ключа партиционирования могут стать медленнее (скан всех партиций + накладные расходы планировщика).
Старое наследование (table inheritance) + триггеры/CHECK — legacy. Декларативное партиционирование почти всегда предпочтительнее; для автоматизации создания партиций используют pg_partman.

Теория#

Что такое партиционирование и зачем оно#

Партиционированная таблица — это «фасад»: у неё нет собственного хранилища, данные физически лежат в партициях (отдельных таблицах). Маршрутизация строки в нужную партицию происходит по ключу партиционирования на стороне сервера автоматически при INSERT.

Утечки памяти в Go (несмотря на GC)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

Garbage collector освобождает только то, на что нет живых ссылок — поэтому утечка в Go — это всегда «случайно удерживаемая ссылка» или незакрытый ресурс, а не ошибка аллокатора. Классика: растущие глобальные мапы, под-слайсы, держащие весь backing array, незакрытые response.Body/файлы, time.Ticker/time.After в циклах, кэши без эвикции, горутины-зомби. Ищут через pprof heap (inuse_space vs alloc_space), diff профилей и runtime.MemStats.

Теория#

Почему GC не спасает#

Go GC — tracing mark-and-sweep: живо то, что достижимо от корней (стеки горутин, глобальные переменные, регистры). Объект собирается, только когда на него нет ни одной ссылки. «Утечка» — это логически ненужный объект, который остаётся достижимым: его кто-то держит. Дополнительно есть феномен «память освобождена для рантайма, но не возвращена ОС» (RSS остаётся высоким) — это не утечка в строгом смысле, но выглядит похоже.

Apache Kafka

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Kafka — это распределённый, реплицируемый, persistent commit log, а не классическая очередь. Сообщения не удаляются после чтения; консьюмеры читают по своему оффсету (pull-модель).
Топик → партиции. Партиция — единица параллелизма и единственная единица упорядочивания. Глобального порядка между партициями нет.
Consumer group: одна партиция в конкретный момент обрабатывается ровно одним консьюмером группы. Параллелизм группы ограничен числом партиций.
Гарантии порядка — только внутри партиции; ключ сообщения определяет партицию (hash(key) % partitions), поэтому одинаковый ключ → одна партиция → порядок.
Delivery: по умолчанию at-least-once. Exactly-once (EOS) достигается idempotent producer + transactions + read_committed. At-most-once — если коммитить оффсет до обработки.
Надёжность: acks=all + min.insync.replicas>=2 + replication.factor>=3. ISR — синхронные реплики.
Ребалансировка: eager (stop-the-world) vs cooperative/incremental (KIP-429). Ретеншн: по времени/размеру или log compaction (хранит последнее значение на ключ).
Go-клиенты: franz-go (предпочтительно, нативный, поддержка свежих KIP, EOS) vs sarama (зрелый, но тяжелее и с историей багов).

Теория#

Лог как структура данных#

Партиция — это append-only лог сегментов на диске. Каждое сообщение получает монотонный offset (int64) — порядковый номер в партиции. Это центральная идея Kafka: брокер не отслеживает, кто что прочитал, он лишь хранит лог и текущие границы.

OpenAPI/Swagger, code generation, contract-first vs code-first, валидация

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

OpenAPI — машиночитаемая спецификация (контракт) HTTP/REST API в YAML/JSON. До версии 3.0 называлась Swagger (2.0 == “Swagger 2.0”). Swagger сейчас — это набор инструментов (Swagger UI, Swagger Editor, Codegen) от SmartBear, а сам формат — OpenAPI Specification (OAS) под управлением OpenAPI Initiative (Linux Foundation).
Версии: 2.0 (2014, Swagger) → 3.0 (2017, переработана структура: components, requestBody, servers) → 3.1 (2021, полная совместимость с JSON Schema Draft 2020-12).
Два подхода: contract-first (design-first) — сначала пишем спеку, из неё генерим типы/сервер/клиент (oapi-codegen); code-first — пишем Go-код с аннотациями, из него генерим спеку (swaggo/swag). Для контракта между командами/фронтом промышленный стандарт — contract-first.
Спека = source of truth. Контракт между бэкендом, фронтом, мобайлом, внешними потребителями. Версионируется в git, линтуется в CI (spectral, vacuum), на breaking changes проверяется (oasdiff).
Валидация: статическая (линт спеки в CI) + рантайм (middleware на базе kin-openapi валидирует request/response против схемы).

Теория#

Что такое OpenAPI#

OpenAPI Specification (OAS) — формальное, языконезависимое описание HTTP API. Описывает: эндпоинты, методы, параметры, тела запросов/ответов, схемы данных, аутентификацию, примеры. Главная ценность — единый машиночитаемый контракт, из которого можно:

URL Shortener

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: System Design · Уровень: Senior

TL;DR#

Сервис превращает длинный URL в короткий ключ (tiny.cc/aZ3kP9) и редиректит обратно. Это классический read-heavy сервис с соотношением чтения к записи ~100:1, где главные проблемы не в редиректе как таковом, а в:

Генерации уникальных коротких ключей без коллизий и без single point of contention. Два рабочих подхода: hash(url) + truncate (просто, но коллизии) и counter + base62 (без коллизий, но нужен распределённый монотонный счётчик).
Редиректе 301 vs 302 — это не косметика: выбор напрямую ломает или сохраняет аналитику и нагрузку на бэкенд.
Латентности чтения — путь редиректа должен быть O(1) lookup из кэша/CDN, в идеале не доходя до основной БД.

Senior-ответ строится вокруг трёх осей: как раздать диапазоны ключей между инстансами без гонок, почему 302 (а не 301) при наличии аналитики, и как удержать p99 редиректа в единицах миллисекунд при масштабе.

Архитектура PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

PostgreSQL — это процессная (process-per-connection) СУБД, а не потоковая. Родительский процесс postmaster форкает по одному backend-процессу на каждое соединение, плюс набор фоновых служебных процессов.
Все backend’ы общаются через общую память (shared memory), главная часть которой — shared buffers (кэш страниц 8 КБ). Вытеснение страниц — алгоритм clock-sweep (приближение к LRU).
Перед записью грязной страницы на диск изменения сначала пишутся в WAL (write-ahead log) — это гарантирует durability и crash recovery. Принцип WAL-before-data, позиция в логе — LSN.
Checkpoint — точка, до которой все грязные страницы сброшены на диск; ограничивает объём WAL, который нужно проиграть при восстановлении. Регулируется checkpoint_timeout, max_wal_size, checkpoint_completion_target.
Autovacuum убирает dead tuples (следствие MVCC), предотвращает раздувание (bloat) и transaction ID wraparound, обновляет статистику и visibility map.
TOAST — механизм хранения значений, не помещающихся в страницу 8 КБ: сжатие + вынос в отдельную таблицу (out-of-line).
На senior-уровне ждут понимания связи MVCC ↔ vacuum ↔ WAL ↔ checkpoint и умения диагностировать проблемы (I/O-всплески, bloat, wraparound, write amplification).

Теория#

Процессная модель#

PostgreSQL запускает дерево процессов. В отличие от MySQL/Oracle (потоки), здесь на каждое клиентское соединение создаётся отдельный процесс ОС. Это упрощает изоляцию сбоев (краш одного backend не валит сервер), но делает соединения дорогими — отсюда необходимость пулеров (PgBouncer, pgcat) на высоконагруженных системах.

Горутины: жизненный цикл, стоимость, стек

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

Горутина — это легковесный поток исполнения, управляемый рантаймом Go, а не ОС. Стартовый стек ~2 КБ, растёт/сжимается копированием. Создаётся через go f(), планируется на потоки ОС моделью GMP. Завершается при возврате из функции; неперехваченная паника в горутине роняет весь процесс.

Теория#

Что такое горутина под капотом#

Горутина представлена структурой runtime.g (файл src/runtime/runtime2.go). Это не поток ОС: множество горутин мультиплексируется на ограниченное число потоков ОС (M) через логические процессоры (P). Ключевые поля g:

Модель памяти Go (Go Memory Model): happens-before и синхронизация

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

Go memory model определяет, при каких условиях чтение переменной в одной горутине гарантированно видит значение, записанное в другой. Основа — отношение happens-before: если запись happens-before чтения (и между ними нет других записей в эту переменную), чтение видит эту запись. Гарантии дают только примитивы синхронизации (channels, sync.Mutex, sync.Once, sync/atomic, WaitGroup). Программа без data race ведёт себя как sequential consistency; программа с гонкой имеет неопределённое поведение, и компилятор/CPU вправе переупорядочивать операции. С Go 1.19 модель официально переписана и формализует sync/atomic как sequentially consistent.

Указатели в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Указатель в Go — это типизированный адрес значения в памяти; Go всегда передаёт аргументы по значению, поэтому указатель — единственный способ позволить функции мутировать чужое значение и избежать копии. Арифметики указателей нет (кроме unsafe.Pointer), есть GC, и где физически живёт значение (стек или куча) решает escape-анализ, а не наличие &. Выбор value vs pointer receiver влияет не только на мутацию и стоимость копий, но и на method set, а значит — на то, реализует ли тип интерфейс.

pprof: профилирование CPU, памяти и блокировок в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

pprof — это система статистического профилирования Go. Большинство профилей (CPU, heap, mutex, block) собираются через сэмплирование, поэтому стоят дёшево и пригодны для продакшена. Профиль можно собрать программно (runtime/pprof) или через HTTP-эндпоинты (net/http/pprof), а затем анализировать в go tool pprof (top/list/web/peek) или в continuous-profiling-системах (Pyroscope, Parca, Grafana Cloud). Ключ к правильному чтению — понимать flat vs cum и разницу между inuse/alloc для heap.

Protocol Buffers: схемы, wire format, эволюция и совместимость

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

Protocol Buffers (protobuf) — бинарный, схемозависимый формат сериализации от Google. Схема описывается в .proto, компилируется protoc в код целевого языка (для Go — пакет google.golang.org/protobuf).
На проводе (wire format) сообщение — это последовательность пар (tag, value), где tag = (field_number << 3) | wire_type. Имена полей на проводе отсутствуют — кодируются только номера.
Есть 4 актуальных wire type: 0 VARINT, 1 I64 (64-bit), 2 LEN (length-delimited), 5 I32 (32-bit). Типы 3/4 (start/end group) устарели.
Номера полей 1–15 кодируются в 1 байт тега, 16–2047 — в 2 байта. Поэтому горячие/частые поля держим в 1–15.
Совместимость держится на номерах полей, а не на именах. Backward (новый код читает старые данные) и forward (старый код читает новые данные) совместимость работают за счёт пропуска/сохранения unknown fields.
Главные правила эволюции: никогда не меняй номер существующего поля, никогда не переиспользуй номер удалённого поля (reserved), добавление полей безопасно, переименование безопасно.
В proto3 нет required, по умолчанию поля имеют presence “implicit” (нельзя отличить zero от unset) — для явного presence используют optional, oneof или wrapper-типы.
oneof, well-known types (Timestamp, Duration, Any, Struct, FieldMask, wrappers), map, repeated + packed encoding — стандартный senior-инструментарий.

Теория#

1. Что такое protobuf и зачем#

Protobuf — это IDL (interface definition language) + бинарный формат + кодогенерация. По сравнению с JSON:

sync.Mutex и sync.RWMutex

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

sync.Mutex — взаимное исключение для защиты разделяемого состояния; устроен на основе атомарного слова состояния + семафора рантайма для парковки горутин. С Go 1.9 у мьютекса есть starvation mode, защищающий «обиженные» горутины от голодания. RWMutex разрешает много читателей или одного писателя, но из-за дороговизны и риска голодания писателей полезен только при сильном перекосе в сторону чтения и длинных критических секциях. Мьютексы нельзя копировать после первого использования.

Transactional Outbox

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Dual write — запись в БД и публикация в брокер выполняются как две независимые операции; между ними возможен сбой → одна сторона зафиксирована, другая нет → потеря или дублирование событий. Распределённой транзакции «БД + Kafka» в общем случае нет (а 2PC дорог и неотказоустойчив).
Transactional outbox решает это: событие пишется в таблицу outbox в той же локальной ACID-транзакции, что и бизнес-данные. Атомарность гарантируется БД. Отдельный процесс (relay) асинхронно вычитывает outbox и публикует в брокер.
Доставка из outbox — at-least-once (relay может упасть после публикации, но до фиксации факта отправки → повторная публикация). Дубликаты неизбежны → консьюмер обязан быть идемпотентным (inbox pattern / dedup-таблица).
Два способа читать outbox: polling publisher (relay SELECT-ит таблицу) vs CDC (Debezium читает WAL/binlog транзакционного лога — нет нагрузки SELECT-ами, ниже latency).
Ordering не бесплатен: глобального порядка нет, обычно гарантируют порядок в рамках партиционного ключа (aggregate_id).

Теория#

Проблема dual write#

Типичный сценарий: сервис заказов создаёт заказ и должен опубликовать событие OrderCreated.

Планирование и оптимизация запросов в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

EXPLAIN показывает план запроса с оценками планировщика (estimated rows, cost), не выполняя запрос. EXPLAIN ANALYZE реально выполняет запрос и добавляет фактические данные (actual time, actual rows, loops). Поэтому ANALYZE с INSERT/UPDATE/DELETE действительно меняет данные — оборачивайте в транзакцию с ROLLBACK или используйте BEGIN; ... ROLLBACK;.
План читается снизу вверх и изнутри наружу: листья (сканы) внизу, корень (то, что отдаёт результат клиенту) вверху. Главный диагностический приём — сравнить rows=N (оценка) с actual rows=M (факт). Расхождение в разы/порядки означает плохую статистику и, как следствие, плохой план.
Cost — это безразмерная величина в условных единицах seq_page_cost. Планировщик выбирает план с минимальным суммарным cost, не учитывая реальную нагрузку CPU/IO в миллисекундах.
Типы сканов по возрастанию избирательности: Seq Scan (читаем всё), Bitmap Index/Heap Scan (средняя селективность, много строк по индексу), Index Scan (мало строк), Index Only Scan (данные целиком в индексе + visibility map).
Джойны: Nested Loop хорош для малых наборов с индексом по внутренней таблице, катастрофичен при недооценке строк; Hash Join для больших equi-join без сортировки (зависит от work_mem); Merge Join для отсортированных/индексированных больших наборов.
Статистика собирается ANALYZE в pg_statistic: n_distinct, MCV (most common values), гистограммы. По умолчанию default_statistics_target = 100. Для коррелированных колонок планировщик предполагает независимость и сильно ошибается — лечится CREATE STATISTICS.
OFFSET линейно деградирует (читает и выбрасывает N строк). Используйте keyset pagination (WHERE (created_at, id) < (...)).
N+1 в Go — главный источник деградации latency: решается JOIN, IN (...), dataloader-батчингом или pgx.Batch.

Теория#

EXPLAIN vs EXPLAIN ANALYZE#

EXPLAIN запрашивает у планировщика выбранный план без выполнения. Вы видите оценки: сколько строк планировщик ожидает (rows), их средняя ширина в байтах (width) и стоимость (cost=startup..total).

Рефлексия в Go (reflect)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Рефлексия в Go — это механизм, позволяющий программе исследовать и менять собственные значения и типы во время выполнения через пакет reflect. Она построена поверх внутреннего представления интерфейсов (eface): reflect.Value хранит указатель на rtype, указатель на данные и набор флагов. Рефлексия мощная, но дорогая (аллокации, отсутствие инлайнинга, динамические проверки), поэтому на горячих путях её избегают, а популярные библиотеки (encoding/json) кэшируют построенные по типу планы кодирования. Ключевые понятия для senior: три закона Роба Пайка, settability (только через указатель + Elem()), разница Kind vs Type, флаги flagIndir/flagAddr/flagRO.

Execution Tracer и runtime/trace: тайминги вместо агрегатов

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

runtime/trace (execution tracer) пишет поток событий планировщика, GC, syscalls и блокировок с наносекундными таймстампами — в отличие от pprof, который даёт агрегированную статистику. Он отвечает на вопрос «почему конкретная горутина простояла 8 мс именно в этот момент», а не «куда в среднем уходит CPU». С Go 1.21 трейсер переписан на низкооверхедный формат (snapshot-free, ~1-2% overhead), а Go 1.25 принёс trace.FlightRecorder — кольцевой буфер для post-mortem диагностики редких событий. Дополняется неинвазивной диагностикой через GODEBUG (gctrace, schedtrace, inittrace).

RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

RabbitMQ — это smart broker / dumb consumer: брокер хранит логику маршрутизации (exchanges + bindings) и выталкивает (push) сообщения потребителям. Kafka — наоборот: dumb broker / smart consumer (pull, потребитель сам держит offset).
Базовая модель AMQP 0-9-1: producer публикует в exchange, exchange по binding и routing key раскладывает сообщение по очередям, consumer читает из очереди. Очередь — единственное место, где сообщение реально хранится.
Типы exchange: direct (точное совпадение routing key), topic (паттерны с * и #), fanout (broadcast, ключ игнорируется), headers (матчинг по заголовкам).
Надёжность доставки строится на трёх китах: manual ack/nack (подтверждение от consumer), publisher confirms (подтверждение от брокера producer-у), persistent + durable + quorum queue (переживание рестарта/отказа узла).
DLQ (dead-letter exchange) ловит сообщения, которые были отвергнуты (reject/nack без requeue), протухли по TTL, или вытеснены по max-length.
Prefetch (basic.qos) — главный рычаг производительности: без него один медленный consumer заберёт всю очередь round-robin’ом; с prefetch=1 получается fair dispatch.
Quorum queues (на базе Raft) — современный стандарт для надёжности. Classic mirrored queues deprecated и удалены в RabbitMQ 4.0.
Выбор: RabbitMQ — для task/job queue, сложной маршрутизации, RPC, per-message acknowledgement. Kafka — для event streaming, replay, высокого throughput и ordered log.

Теория#

Модель AMQP 0-9-1#

AMQP 0-9-1 (Advanced Message Queuing Protocol) — это бинарный wire-протокол, реализуемый RabbitMQ по умолчанию. Не путать с AMQP 1.0 — это совершенно другой протокол (он тоже поддерживается RabbitMQ через плагин, но дефолтная модель — именно 0-9-1).

REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Backend · Уровень: Middle+/Senior

TL;DR#

REST — архитектурный стиль (диссертация Роя Филдинга, 2000), а не протокол. Ключевые ограничения: client-server, stateless, cacheable, layered system, uniform interface, опционально code-on-demand.
Ресурс — абстрактная сущность, у неё есть представления (JSON/XML/…). URI идентифицирует ресурс, метод выражает действие. Не глаголы в URI (/users/42, а не /getUser?id=42).
Уровни зрелости Ричардсона (RMM): L0 — один эндпоинт (RPC поверх HTTP), L1 — ресурсы, L2 — HTTP-методы + статусы (де-факто отраслевой стандарт), L3 — HATEOAS (гиперссылки).
Семантика методов: GET/HEAD/OPTIONS — safe; GET/HEAD/PUT/DELETE/OPTIONS — idempotent; POST/PATCH — нет. Кэшируются по умолчанию GET/HEAD.
Идемпотентность = N одинаковых запросов дают тот же эффект на сервере, что и один. PUT идемпотентен по дизайну, POST — нет → для платежей нужен Idempotency-Key.
Версионирование: URL path (/v1/) — просто и видно; media-type через Accept — «правильно» по REST, но сложнее в эксплуатации; query param — компромисс.
Пагинация: offset/limit прост, но дрейфует и медленный на больших offset; cursor/keyset — стабилен и быстр (WHERE (created_at, id) < (?, ?)).
Ошибки: единый формат RFC 7807/9457 Problem Details (application/problem+json), стабильные машинные коды, никаких stack trace и SQL наружу.

Теория#

1. Принципы REST (ограничения архитектуры)#

REST задаётся набором архитектурных ограничений (constraints). Соблюдение даёт масштабируемость, кэшируемость и слабую связанность.

sync.Once

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Middle+/Senior

TL;DR#

sync.Once гарантирует, что переданная функция выполнится ровно один раз за всё время жизни, даже при конкурентных вызовах из множества горутин — основа для потокобезопасной ленивой инициализации. Внутри — атомарный флаг (быстрый путь без блокировки) плюс мьютекс для медленного пути. Go 1.21 добавил эргономичные обёртки OnceFunc, OnceValue, OnceValues.

Теория#

Контракт#

var once sync.Once
var conn *DB

func GetDB() *DB {
 once.Do(func() {
 conn = connect() // выполнится ровно один раз
 })
 return conn
}

Do(f) вызывает f только при первом вызове. Все остальные вызовы (включая конкурентные) блокируются, пока первый f не завершится, и только потом возвращаются.
Гарантия видимости: записи внутри f happens-before возврат любого Do → все горутины видят полностью проинициализированное состояние.
Если f паникует, она считается «выполненной» — повторные Do её не запустят.

Устройство под капотом#

type Once struct {
 done atomic.Uint32 // 0 = не выполнено, 1 = выполнено
 m Mutex
}

func (o *Once) Do(f func()) {
 if o.done.Load() == 0 { // быстрый путь: атомарное чтение
 o.doSlow(f)
 }
}

func (o *Once) doSlow(f func()) {
 o.m.Lock()
 defer o.m.Unlock()
 if o.done.Load() == 0 { // двойная проверка под мьютексом
 defer o.done.Store(1) // ставим флаг ПОСЛЕ f (через defer)
 f()
 }
}

Ключевые детали:

Внутреннее устройство слайсов в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Слайс — это не контейнер, а трёхсловный дескриптор (header): указатель на бэкинг-массив, длина (len) и ёмкость (cap). Слайс передаётся по значению (header копируется), но указывает на тот же массив, поэтому мутации элементов видны вызывающему, а append — нет (он может реаллоцировать). Главные источники багов: молчаливый шаринг бэкинг-массива между подслайсами, реаллокация при росте и утечки памяти, когда маленький подслайс удерживает весь большой массив.

Репликация в PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

Физическая (streaming) репликация — побайтовая копия кластера на уровне WAL. Standby проигрывает WAL primary. Всё или ничего: реплицируется весь инстанс, версии PG должны совпадать, архитектура CPU тоже. Основа HA.
Логическая репликация — на уровне логических изменений строк (decode WAL → INSERT/UPDATE/DELETE). Выборочно по таблицам (publication/subscription), между разными мажорными версиями, можно писать в таблицы-подписчики. Цена — нет DDL, нужны PK/REPLICA IDENTITY, выше overhead.
sync vs async: synchronous_commit управляет, ждать ли подтверждения standby перед возвратом COMMIT. Async = низкая latency, риск потери данных при падении primary. Sync = durability, но latency растёт и primary может «зависнуть», если standby недоступен. quorum/ANY — компромисс.
Replication lag = задержка между primary и standby. Три фазы: write → flush → replay. Мониторинг через pg_stat_replication (на primary) и pg_stat_wal_receiver / pg_last_wal_replay_lsn() (на standby).
Чтение с реплик даёт масштабирование read-нагрузки, но порождает stale reads и проблему read-your-writes. Нужен sticky-routing или чтение свежих данных с primary.
Failover: pg_promote() переводит standby в primary. Опасность split-brain — нужен fencing. В проде это Patroni/repmgr + DCS (etcd/Consul), а не ручной promote.
Go: два пула *pgxpool.Pool / *sql.DB (writer → primary, reader → реплики), роутинг по типу запроса, с fallback на primary для read-your-writes.

Теория#

1. Физическая (streaming / WAL) репликация#

PostgreSQL пишет все изменения сначала в WAL (Write-Ahead Log) — последовательность записей, описывающих физические изменения страниц данных (блоков 8 КБ). Физическая репликация — это передача потока WAL с primary на standby и его непрерывное применение.

Паттерны конкурентности

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

Базовый словарь конкурентного Go: pipeline (этапы через каналы), fan-out/fan-in (распараллелить этап и собрать), worker pool (фиксированный пул на канале задач), семафор (ограничение конкуренции буферизованным каналом), errgroup (группа горутин с отменой и первой ошибкой), graceful shutdown (через context + WaitGroup), or-done (обёртка для отмены). Общий принцип всех паттернов: у каждой горутины есть явный путь завершения (закрытие входа или ctx.Done()), иначе — утечка.

Теория#

Pipeline#

Этапы, соединённые каналами; каждый этап читает вход, пишет выход, закрывает свой выход при завершении.

Ретраи: backoff, jitter, budgets и идемпотентность

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Ретрай — это попытка повторить запрос после сбоя. Наивный «повторить сразу N раз» в распределённой системе создаёт retry storm и усиливает деградацию.
Базовая формула паузы: exponential backoff (base * 2^attempt) с cap (потолком) и jitter (рандомизацией), чтобы избежать синхронизации клиентов (thundering herd).
Лучший дефолт — decorrelated jitter или full jitter (по статье AWS «Exponential Backoff And Jitter»).
Ретраить можно только идемпотентные операции (или операции, защищённые idempotency key). Иначе риск двойного списания/дублей.
Retry budget ограничивает долю ретраев от общего трафика (например, не более 10–20%), предотвращая каскадное усиление нагрузки.
Deadline propagation через context.Context: общий дедлайн всего вызова пробрасывается вниз, и каждая попытка (включая backoff) обязана в него укладываться.
Ретраить осмысленно: transient-ошибки (5xx, timeout, connection reset), а не 4xx (кроме 429/503 с Retry-After).

Теория#

Зачем вообще ретраи#

В распределённой системе сбои — норма, а не исключение: сетевые таймауты, кратковременная недоступность пода во время rolling update, GC-пауза на сервере, потеря пакета. Многие из них transient — повторная попытка через короткое время с высокой вероятностью пройдёт. Ретрай повышает наблюдаемую надёжность (availability) без изменения самого сервиса.

Стек vs Куча: где живут данные в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Runtime и память · Уровень: Senior+

TL;DR#

В Go компилятор сам решает, где разместить значение — на стеке горутины или в куче, — опираясь на escape analysis. Стек дешёв: аллокация это сдвиг указателя SP, а освобождение — возврат при выходе из функции, без участия GC. Куча дороже: запрос у аллокатора (mcache/mcentral/mheap), последующая работа GC и давление на пропускную способность. Стеки горутин начинаются с 8 КБ (исторически было 2 КБ для системных потоков-g0 и для горутин в разных версиях), растут не сегментами, а целостным копированием (contiguous stacks) через morestack/copystack.

Строки, руны и байты в Go

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

string в Go — это неизменяемая (immutable) пара «указатель + длина» (StringHeader{ptr, len}), указывающая на read-only последовательность байт, без какого-либо требования к кодировке. Текст в исходниках и стандартной библиотеке хранится в UTF-8, поэтому len(s) возвращает количество байт, s[i] — отдельный байт, а for i, r := range s декодирует UTF-8 и отдаёт руны (rune = int32, Unicode code point) вместе с байтовым смещением. Конвертации string<->[]byte и string<->[]rune в общем случае копируют память (аллокация в куче), но компилятор умеет несколько важных оптимизаций (ключ map, range []byte(s)), а strings.Builder и unsafe.String/Slice позволяют избегать лишних копий — каждая со своими опасностями.

Шардирование (горизонтальное масштабирование)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior+

TL;DR#

Шардирование — разбиение данных на независимые узлы (шарды), каждый из которых хранит свой непересекающийся поднабор строк. Это способ масштабировать запись и объём данных за пределы одной машины.
Не путать: репликация = копии тех же данных (масштаб чтения и HA), партиционирование = разбиение таблицы внутри одного инстанса, шардирование = разбиение по разным инстансам.
Стратегии: hash-based (равномерность, но плохие range-запросы), range-based (хорошие диапазоны, но hotspots), lookup/directory (гибкость ценой лишнего хопа), geo (локальность и data residency).
Shard key — главное архитектурное решение: равномерность распределения, отсутствие hotspots, co-location связанных данных. Изменить его потом крайне дорого.
Consistent hashing + виртуальные узлы минимизируют перемещение данных при resharding: при добавлении N+1-го шарда переезжает ~1/(N+1) ключей, а не «почти всё».
Cross-shard запросы (scatter-gather, JOIN, агрегации) и транзакции (2PC, saga) дороги — хорошая схема шардирования их избегает.
PostgreSQL: Citus (расширение, distributed tables), Vitess (это про MySQL), либо application-level sharding с роутингом в коде.

Теория#

Шардирование vs репликация vs партиционирование#

Три разных оси масштабирования, которые часто путают на собеседовании.

Race Detector (гонки данных и -race)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

Гонка данных — это два конкурентных доступа к одной памяти, где хотя бы один — запись, и между ними нет отношения happens-before. В Go такое поведение не определено. Детектор гонок (go test -race, go run -race) построен на ThreadSanitizer: он динамически отслеживает happens-before через векторные часы и сообщает о реальных гонках, наблюдённых на конкретном прогоне. Цена высока (память ×5–10, скорость ×2–20), и он не доказывает отсутствие гонок — только находит те, что фактически случились.

Saga Pattern

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Saga — это способ управлять данными в нескольких сервисах/БД через последовательность локальных транзакций, где каждый шаг публикует событие/команду, запускающую следующий шаг. Если шаг падает, выполняется серия компенсирующих транзакций, откатывающих эффекты предыдущих шагов семантически (а не настоящим rollback). Saga жертвует Isolation из ACID: вы получаете ACD без I. Два стиля координации: оркестрация (центральный координатор дёргает участников командами) и хореография (участники реагируют на события друг друга, без центра). Главные проблемы: отсутствие изоляции (dirty reads, lost updates), компенсации могут падать (нужны ретраи и идемпотентность), часть шагов невозможно компенсировать. Решается это контрмерами (semantic lock, commutative updates, pessimistic view, reread value, by value) и разделением шагов на compensatable / pivot / retriable.

Система типов Go: defined types, alignment, memory layout

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Core Go · Уровень: Senior

TL;DR#

Go — статически типизированный язык со структурной концепцией underlying type, на которой строятся правила assignability и convertibility. type Foo int создаёт новый defined (named) type с тем же underlying type, но другой identity; type Foo = int — это alias, полностью идентичный int. Поверх системы типов лежит физический memory layout: компилятор выравнивает поля структур по их alignment, добавляя padding, поэтому порядок полей напрямую влияет на Sizeof. Знание zerobase для struct{}, правил comparable-типов и iota — обязательный senior-минимум.

Транзакции в PostgreSQL и Go (database/sql, pgx)

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Базы данных · Уровень: Senior

TL;DR#

ACID = Atomicity (всё или ничего, реализуется через WAL и откат), Consistency (инварианты БД: constraints, triggers, FK), Isolation (параллельные транзакции не мешают друг другу — в PostgreSQL через MVCC + уровни изоляции), Durability (после COMMIT данные переживут крах — гарантируется WAL + fsync).
PostgreSQL не имеет настоящих вложенных транзакций — SAVEPOINT создаёт субтранзакции (получают свой subxid), которые дёшевы в небольшом количестве, но при >64 на бэкенд вызывают SLRU overflow и резкую деградацию (subtrans SLRU misses).
Длинные транзакции — главное зло в PostgreSQL: удерживают xmin горизонт → VACUUM не может удалить dead tuples → bloat, распухание индексов, деградация. idle in transaction особенно опасен.
В Go: всегда BeginTx(ctx, opts), паттерн defer tx.Rollback() (после Commit это no-op), не забывать ctx для отмены. В pgx — pgxpool + tx.Begin/pgx.BeginFunc.
На уровне SERIALIZABLE (и REPEATABLE READ при write skew конфликтах) транзакция может упасть с 40001 (serialization_failure) или 40P01 (deadlock_detected) — это нормально и ожидаемо, надо реализовать retry с экспоненциальным backoff.

Теория#

ACID подробно#

ACID — набор гарантий, которые СУБД даёт относительно транзакций. Важно понимать не определения из учебника, а как именно они реализованы в PostgreSQL.

Планировщик GMP

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior+

TL;DR#

Планировщик Go строится на трёх сущностях: G (горутина), M (поток ОС), P (логический процессор/контекст планирования). P держит локальную очередь runnable-горутин, число P = GOMAXPROCS. Используются work stealing, кооперативная и (с 1.14) асинхронная вытесняющая преемпция, handoff P при блокирующих syscall и интегрированный netpoller для сетевого I/O.

Теория#

G, M, P#

G (runtime.g) — горутина: стек, контекст (gobuf), статус.
M (runtime.m) — машина = поток ОС. Реально исполняет код. Чтобы исполнять Go-код, M должен владеть P.
P (runtime.p) — процессор/контекст: локальный runqueue (256 слотов, кольцевой буфер + runnext), кэши аллокатора (mcache), таймеры. Число P = GOMAXPROCS. P — это «право исполнять Go-код».

Инвариант: выполнять Go-код может только связка M+P. Свободные P лежат в sched.pidle; свободные M — в sched.midle.

select

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Senior

TL;DR#

select ждёт готовности одного из нескольких канальных кейсов; при нескольких готовых выбирает псевдослучайно. default делает select неблокирующим. nil-каналы исключают кейс из выбора — основа для динамического включения/выключения и таймаутов/отмены через time.After/ctx.Done().

Теория#

Семантика#

Если готов один кейс — он выполняется.
Если готовы несколько — выбирается случайный (равномерно, через fastrandn), чтобы избежать голодания.
Если ни один не готов и есть default — выполняется default (неблокирующий select).
Если ни один не готов и default нет — горутина блокируется, пока какой-то кейс не станет готов.
Пустой select{} блокирует навсегда.

select {
case v := <-in:
 use(v)
case out <- x:
 // отправили
case <-time.After(time.Second):
 // таймаут
default:
 // ничего не готово прямо сейчас
}

Под капотом (`runtime.selectgo`)#

Кейсы перемешиваются в случайном pollorder (для честного выбора).
Каналы блокируются в фиксированном lockorder по адресам — чтобы исключить дедлок при множественной блокировке.
Проход 1: ищем уже готовый кейс (есть данные/место/закрыт). Нашли — выполняем.
Если есть default и готовых нет — выполняем default.
Иначе: регистрируем sudog во всех каналах (в sendq/recvq), паркуемся.
При пробуждении одним из каналов — снимаем регистрацию с остальных, выполняем выигравший кейс.

То есть в худшем случае select дороже одиночной операции: O(числа кейсов) на регистрацию/дерегистрацию.

sync.WaitGroup

Mon, 01 Jan 0001 00:00:00 +0000

Модуль: Concurrency · Уровень: Middle+/Senior

TL;DR#

WaitGroup — счётчик незавершённой работы: Add(n) увеличивает, Done уменьшает, Wait блокирует, пока счётчик не дойдёт до нуля. Главное правило: Add вызывать до запуска горутины (в той же горутине, что и Wait), а не внутри неё, иначе возможна гонка между Wait и стартом. Go 1.25 добавил WaitGroup.Go, который атомарно делает Add(1) + запуск + Done, устраняя самую частую ошибку.

Теория#

Контракт#

var wg sync.WaitGroup
for _, task := range tasks {
 wg.Add(1) // ДО go
 go func(t Task) {
 defer wg.Done() // гарантированно даже при панике
 process(t)
 }(task)
}
wg.Wait() // блокируемся, пока счётчик != 0

Add(delta) — атомарно прибавляет delta (может быть отрицательным) к счётчику.
Done() — это Add(-1).
Wait() — блокирует, пока счётчик не станет 0. Если уже 0 — возвращается сразу.
Если счётчик становится отрицательным → паника sync: negative WaitGroup counter.

Устройство под капотом#

До Go 1.20 WaitGroup хранил счётчик и число ожидающих в одном 64-битном слове (с трюками выравнивания для 32-бит платформ). С Go 1.25 (рефакторинг под WaitGroup.Go) внутреннее представление изменилось, но логически — это: