Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: Распределённые системы · Уровень: 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 — гарантии в рамках сессии одного клиента, удобный компромисс.

## Теория

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

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

Главный трейдофф: **сильнее модель → больше синхронной координации → выше latency и ниже availability** (см. CAP/PACELC).

### Спектр моделей (от сильной к слабой)

```
strict serializability   (Spanner external consistency)
        │  (txns + real-time)
linearizability           (single-object, real-time recency)   ← "strong consistency"
        │
sequential consistency    (общий порядок, но не обязан уважать real-time)
        │
causal consistency        (happens-before сохраняется)   ← макс. при сохранении availability
        │
session guarantees        (read-your-writes, monotonic reads/writes, writes-follow-reads)
        │
eventual consistency      (реплики сходятся "когда-нибудь")
```

Линейного «одного» спектра на самом деле нет (модели образуют частичный порядок), но как первое приближение порядок выше полезен.

### Linearizability (strong / atomic)

Гарантия: существует **total order** над всеми операциями такой, что:
1. Он согласуется с **real-time**: если операция A завершилась до начала операции B (по абсолютному времени), то A предшествует B в порядке.
2. Каждое чтение возвращает значение последней предшествующей записи в этом порядке.

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

```
Реальное время →
Клиент A:  ──[ write x=1 ]──┐
Клиент B:               ──[ read x ]──   должен вернуть 1
                              ↑ если read начался ПОСЛЕ завершения write,
                                linearizability обязывает вернуть 1 (или новее)
```

- Это **per-object** свойство (один регистр/ключ). Не про транзакции над несколькими ключами.
- Это «C» из CAP. Требует синхронной координации (кворум/лидер) ⇒ дорого.
- Композируема: если каждый объект линеаризуем, система из этих объектов тоже линеаризуема (важное отличие от serializability).

### Serializability

Гарантия: результат конкурентного выполнения набора **транзакций** (каждая — над произвольным множеством объектов) эквивалентен **некоторому** последовательному (serial) их выполнению.

- Это **isolation**-свойство (ACID-I), про транзакции, а не про recency.
- Сериализуемость **не уважает real-time**: допустим, T1 закоммитилась до начала T2, но эквивалентный serial-порядок может поставить T2 перед T1. Чтение в T2 законно может «не увидеть» коммит T1.
- Не композируема сама по себе так, как linearizability.

### Linearizability vs Serializability — ключевое различие

Это любимый вопрос на senior+.

| | Linearizability | Serializability |
|---|---|---|
| Про что | **Recency** (свежесть) | **Isolation** (изоляция транзакций) |
| Область | **Один объект**, одна операция | **Много объектов**, транзакции |
| Real-time | Уважает (total order согласован с реальным временем) | **Не** обязана уважать |
| Откуда термин | Распределённые системы (Herlihy & Wing) | Теория БД (ACID-I) |
| Композируемость | Да (локальное свойство) | Нет |

**Strict serializability** = serializability ∧ linearizability: эквивалентный serial-порядок к тому же уважает real-time. Это то, что даёт Spanner (под именем external consistency) благодаря TrueTime. Самая сильная практическая модель для транзакционных систем.

```
                 single-object         multi-object/txn
recency only     linearizability       —
isolation only   —                     serializability
recency + iso     —                    strict serializability
```

Кратко: **linearizability — про «когда» (свежесть), serializability — про «как переплелись транзакции» (изоляция). Strict serializability — оба сразу.**

### Sequential consistency

Существует total order, согласованный с **program order** каждого клиента (операции одного клиента в порядке их выдачи), но **не обязан** согласовываться с real-time между разными клиентами. Слабее linearizability: чтение может вернуть устаревшее значение, если только не нарушает порядок внутри клиентов. Модель памяти многих языков/процессоров близка к этому.

### Causal consistency

Сохраняет порядок только для **причинно-связанных** (happens-before, Lamport) операций; конкурентные (causally independent) операции разные узлы могут видеть в разном порядке.

Happens-before (→):
- операции одного процесса упорядочены;
- send → receive того же сообщения;
- транзитивность.

```
A: write post = "hi"   ──┐ (causal: коммент видит пост)
B: (видит post)          └─→ write comment = "re: hi"
   Любой узел, увидевший comment, ОБЯЗАН уже видеть post.
   Но два независимых поста разные узлы могут увидеть в разном порядке.
```

Важность: **causal consistency — самая сильная модель, совместимая с высокой доступностью во время партиции** (теорема: convergent + causal — потолок для AP-систем). Реализуется через vector clocks / version vectors. Предотвращает аномалии типа «вижу ответ, но не вижу исходное сообщение».

### Session / client-centric guarantees

Гарантии в рамках **сессии одного клиента** (не глобальные). Терпимы к слабой репликации, но устраняют самые раздражающие аномалии для конкретного пользователя.

- **Read-your-writes (read-my-writes)**: после того как клиент записал значение, его последующие чтения видят это значение (или новее). Без этого пользователь меняет аватар и видит старый.
- **Monotonic reads**: если клиент прочитал значение, последующие чтения не вернут более старое. Без этого время «прыгает назад» при переключении реплик.
- **Monotonic writes**: записи одного клиента применяются на репликах в порядке их выдачи. Без этого `set name; set email` может примениться в обратном порядке.
- **Writes-follow-reads (session causality)**: если клиент прочитал значение, а затем сделал запись, эта запись логически следует за прочитанным значением на всех репликах. Обеспечивает причинность на уровне сессии (комментарий после прочтения поста).

**Session consistency** обычно = read-your-writes + monotonic reads + monotonic writes в рамках сессии. Часто реализуется через **sticky sessions** (клиент закреплён за репликой) или передачу версии/токена (например, Cassandra LWT, MongoDB causal consistency tokens, Cosmos DB session tokens).

Эти гарантии **слабее causal** (только своя сессия), но сильнее голого eventual и закрывают 90% UX-проблем.

### Eventual consistency

Слабейшая практически используемая модель: **если записи прекратятся, все реплики в конце концов сойдутся к одному значению** (liveness-гарантия). Во время записей — почти никаких гарантий о порядке/свежести.

- Не определяет, *какое* значение победит при конфликте — это решает разрешение конфликтов (LWT по timestamp, vector clocks + siblings в Riak, CRDT).
- «Eventually» без верхней границы по времени; на практике — десятки мс — секунды.
- Дёшево и максимально доступно ⇒ дефолт для Dynamo/Cassandra/DNS.
- **Strong eventual consistency (CRDT)**: реплики, получившие один набор обновлений (в любом порядке), гарантированно в одном состоянии — без координации, через коммутативные/идемпотентные merge.

### Где это всплывает в Go

В Go-сервисах модель согласованности обычно «спускается» из выбранного хранилища, но клиентский код обязан её учитывать:

```go
// Анти-паттерн: read-after-write на eventually consistent реплике
_, err := db.ExecContext(ctx, "INSERT INTO orders ...") // пишем в primary
if err != nil { return err }
// читаем со read-replica — можем НЕ увидеть только что вставленное
row := replica.QueryRowContext(ctx, "SELECT ... FROM orders WHERE id=$1", id)
```

Решения: читать с primary для read-your-writes критичных путей; передавать версию/LSN и ждать её на реплике; sticky routing; или строить инвариант так, чтобы stale-read был безопасен (идемпотентность, повтор).

## Подводные камни / gotchas

- **Linearizability ≠ serializability.** Первое — recency над одним объектом, второе — isolation над транзакциями. Их регулярно путают; strict serializability — это их объединение.
- **Serializability не уважает real-time.** Транзакция может законно «не увидеть» только что закоммиченную другую транзакцию, если эквивалентный serial-порядок ставит её раньше. Для real-time нужна strict serializability.
- **Eventual consistency не разрешает конфликты сама.** «Сойдутся» — да, но *к чему* зависит от стратегии (LWW теряет записи; vector clocks дают siblings; CRDT мержит без потерь).
- **Read-your-writes легко сломать read-репликами.** Запись в primary, чтение с асинхронной реплики — классический баг «обновил профиль, вижу старый».
- **Monotonic reads ломается при балансировке между репликами** без sticky/версионности: пользователь видит то новые, то старые данные.
- **Causal consistency требует трекинга зависимостей** (vector clocks), что добавляет метаданные и сложность; «дешёвая» causal-репликация — нетривиальна.
- **Сильная модель на запись ≠ сильная на чтение.** Многие системы тюнят отдельно (Cassandra: write CL и read CL независимы; ZooKeeper: линеаризуемые записи, но чтения могут быть stale без sync()).
- **Линеаризуемость дорога и не всегда нужна.** Навешивать strong consistency на всё — это лишняя latency; senior выбирает минимально достаточную модель на каждый путь.

## Вопросы на собеседовании

**В:** В чём разница между linearizability и serializability?
**О:** Linearizability — recency-гарантия над одним объектом: единый порядок операций, согласованный с реальным временем, чтение видит последнюю завершившуюся запись. Serializability — isolation-гарантия над транзакциями (много объектов): результат эквивалентен какому-то последовательному порядку, но real-time не обязан соблюдаться. Первое из распределённых систем, второе — из теории БД (ACID-I).

**В:** Что такое strict serializability и кто её даёт?
**О:** Это serializability + linearizability: эквивалентный serial-порядок транзакций к тому же уважает реальное время (если T1 закоммитилась до начала T2, то T1 в порядке раньше). Google Spanner предоставляет её под названием external consistency, используя TrueTime для синхронизации часов.

**В:** Может ли сериализуемая система вернуть устаревшие данные?
**О:** Да. Сериализуемость не обязана уважать real-time: транзакция T2, начавшаяся после коммита T1, может законно оказаться в эквивалентном serial-порядке перед T1 и не увидеть её изменений. Чтобы это исключить, нужна strict serializability.

**В:** Что гарантирует eventual consistency и чего не гарантирует?
**О:** Гарантирует, что при прекращении записей реплики сойдутся к одному состоянию. Не гарантирует порядок или свежесть во время записей и сама по себе не определяет, какое значение победит в конфликте — это задача стратегии разрешения (LWW, vector clocks, CRDT).

**В:** Что такое read-your-writes и как её обеспечить при наличии read-реплик?
**О:** Гарантия, что клиент после своей записи видит её (или новее) в последующих чтениях. При асинхронных репликах обеспечивается чтением с primary для своих недавних записей, sticky-сессией к одной реплике, или передачей версии/LSN записи и ожиданием, пока реплика догонит её.

**В:** Чем monotonic reads отличается от read-your-writes?
**О:** Monotonic reads: последующие чтения клиента не возвращают более старое значение, чем уже прочитанное (время не идёт назад). Read-your-writes: чтения видят собственные записи клиента. Первое про монотонность чтений, второе про видимость своих записей — это разные session guarantees.

**В:** Почему causal consistency особенная среди слабых моделей?
**О:** Это самая сильная модель согласованности, совместимая с полной доступностью во время сетевой партиции (доказано, что «причинность + сходимость» — потолок для AP-систем). Она сохраняет порядок причинно-связанных операций (happens-before), устраняя аномалии вроде «вижу ответ без исходного сообщения», и при этом не требует глобальной синхронной координации.

**В:** Композируемы ли linearizability и serializability?
**О:** Linearizability — да: если каждый объект линеаризуем, вся система из этих объектов линеаризуема (локальное свойство). Serializability сама по себе не композируема таким образом — её надо обеспечивать на уровне всего набора транзакций.

**В:** Что такое session consistency и как её реализуют на практике?
**О:** Набор гарантий в рамках сессии одного клиента — обычно read-your-writes + monotonic reads + monotonic writes. Реализуется через sticky-сессии (закрепление клиента за репликой) либо через session/version-токены, которые клиент носит с собой и которые заставляют реплику обслужить запрос не старее указанной версии (Cosmos DB session tokens, MongoDB causal consistency).

## На что копают на senior+

- Чёткое разведение **linearizability (recency, single-object) vs serializability (isolation, multi-object)** и понимание, что **strict serializability** — их объединение (Spanner / external consistency).
- Понимание, что **serializability не уважает real-time**, и умение привести конкретную аномалию, которую это допускает.
- Знание **спектра** и того, что это частичный порядок, а не одна линия; умение разместить sequential, causal, session guarantees.
- Понимание **causal как потолка для AP** и механики happens-before / vector clocks.
- Знание **session guarantees поимённо** (read-your-writes, monotonic reads/writes, writes-follow-reads) с конкретными UX-аномалиями каждой и способами обеспечить (sticky, version tokens).
- Понимание стоимости: **сильная согласованность = синхронная координация = latency/availability-цена** (связь с CAP/PACELC), и умение выбрать минимально достаточную модель на конкретный путь.
- Практика: **read-after-write на read-репликах**, разрешение конфликтов при eventual (LWW теряет данные, CRDT/vector clocks — нет), независимый тюнинг read/write consistency.