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/ > Модуль: 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-образ, платформа крутит и масштабирует. ```bash # Cloud Run: деплой контейнера одной командой gcloud run deploy my-svc \ --image=gcr.io/proj/my-svc:sha-abc123 \ --region=europe-west1 \ --min-instances=1 --max-instances=20 \ --concurrency=80 \ --no-allow-unauthenticated ``` **Cloud Run / Fargate vs Lambda для Go**: - Go в Lambda — быстрый cold start (компилируемый, маленький бинарь), но модель «один запрос на инстанс» (нет внутреннего конкуррентного обслуживания), лимиты на время (15 мин) и размер. - Cloud Run обслуживает несколько запросов на инстанс (`concurrency`), что отлично ложится на Go-горутины — дешевле и эффективнее под HTTP-нагрузку. ### Storage: объектное хранилище (S3 / GCS) Объектное хранилище — не POSIX-ФС. Объект = ключ + байты + метаданные. Нет директорий (только префиксы), нет частичной перезаписи (PUT перезаписывает целиком), нет «переименования» (это copy+delete). Ключевые понятия: - **Классы хранения**: Standard (горячие) → Infrequent Access → Glacier/Archive (холодные, дёшево за хранение, дорого/медленно за извлечение). Lifecycle-политики автоматически перемещают/удаляют. - **Консистентность**: S3 теперь strong read-after-write для PUT и DELETE. Но листинг и кросс-региональная репликация — eventual. - **Доступ**: приватный по умолчанию; **presigned URL** для временного прямого доступа клиента (загрузка/скачивание минуя бэкенд). - **Versioning** и Object Lock — защита от случайного удаления / WORM-комплаенс. ```go // presigned URL: клиент грузит файл напрямую в S3, минуя ваш сервис ps := s3.NewPresignClient(s3Client) req, _ := ps.PresignPutObject(ctx, &s3.PutObjectInput{ Bucket: aws.String("uploads"), Key: aws.String("user/42/avatar.png"), }, s3.WithPresignExpires(15*time.Minute)) // отдаём req.URL клиенту, он делает PUT сам ``` Блочное хранилище (EBS / Persistent Disk) — это «диск» для VM: умеет частичную перезапись, привязан к зоне, имеет IOPS/throughput-лимиты. ### Managed реляционные БД | | AWS | GCP | |--|-----|-----| | Managed Postgres/MySQL | RDS | Cloud SQL | | Cloud-native совместимый | Aurora (Postgres/MySQL-совместимый) | AlloyDB (Postgres) | | Globally-distributed | DynamoDB (NoSQL), Aurora Global | Spanner (NewSQL, горизонтальный) | Что даёт managed: автоматические бэкапы и PITR (point-in-time recovery), minor-патчи, Multi-AZ/HA с автоматическим failover, read-replicas, мониторинг. Что теряете: root/superuser, произвольные расширения и версии, полный контроль над `postgresql.conf` (только через parameter groups), иногда задержку с новыми мажорными версиями. Для Go: подключение через стандартный `database/sql` + драйвер (`pgx`). Важные нюансы в облаке: - **Connection pooling**: managed Postgres имеет лимит соединений; serverless-инстансы (Lambda/Cloud Run) легко его выедают. Нужен пулер (RDS Proxy, PgBouncer, Cloud SQL connector) или жёсткий лимит `SetMaxOpenConns`. - **IAM-аутентификация к БД**: вместо пароля — короткоживущий токен (RDS IAM auth, Cloud SQL IAM). ```go db.SetMaxOpenConns(20) // не дать пулу превысить лимит инстанса БД db.SetMaxIdleConns(10) db.SetConnMaxLifetime(30 * time.Minute) // переоткрывать, чтобы ловить failover/ротацию db.SetConnMaxIdleTime(5 * time.Minute) ``` ### Очереди и события **AWS**: - **SQS** — управляемая очередь (point-to-point). Standard (at-least-once, без строгого порядка, высокий throughput) и FIFO (exactly-once-ish, порядок, ниже throughput). Консьюмер делает long-poll `ReceiveMessage`, обрабатывает, явно `DeleteMessage`. Невидимость (visibility timeout) и **DLQ** (dead-letter queue) после N неудачных попыток. - **SNS** — pub/sub fan-out: одно сообщение → много подписчиков (SQS-очереди, Lambda, HTTP). Классический паттерн **SNS → несколько SQS** для надёжного fan-out. - **EventBridge** — событийная шина с маршрутизацией по правилам. **GCP**: - **Pub/Sub** — совмещает роли SQS и SNS: topic (publish) + subscription (по одной на консьюмера). Pull или push доставка, at-least-once, DLQ, ordering keys для порядка. Один topic с несколькими subscriptions = fan-out. ```go // SQS consumer: long-poll + явное удаление после успешной обработки out, _ := sqsClient.ReceiveMessage(ctx, &sqs.ReceiveMessageInput{ QueueUrl: &queueURL, MaxNumberOfMessages: 10, WaitTimeSeconds: 20, // long polling VisibilityTimeout: 60, }) for _, m := range out.Messages { if err := handle(ctx, m); err != nil { continue // не удаляем -> сообщение вернётся после visibility timeout, потом в DLQ } sqsClient.DeleteMessage(ctx, &sqs.DeleteMessageInput{ QueueUrl: &queueURL, ReceiptHandle: m.ReceiptHandle, }) } ``` Ключевой инвариант для бэкендера: доставка **at-least-once** ⇒ обработчик должен быть **идемпотентным** (дедупликация по message-id / бизнес-ключу), потому что одно сообщение может прийти дважды. ### IAM базово Модель: **principal** (пользователь/роль/service account) — **action** (что можно: `s3:GetObject`) — **resource** (над чем) — **condition** (когда: IP, MFA, тег). Запрос разрешён, только если есть явный allow и нет явного deny (deny всегда побеждает в AWS). - **AWS**: пользователи, группы, **роли** (assume-role даёт временные креды), политики (JSON). Сервисы получают права через роль, прикреплённую к инстансу/таску/функции (instance profile / task role / Lambda execution role) — без статичных ключей. - **GCP**: members (user/serviceAccount/group) ← привязка роли (predefined/custom) ← на ресурсе/проекте/организации (иерархия наследования). Сервисы используют **service accounts**; в GKE — **Workload Identity** связывает k8s SA с GCP SA. ```json // AWS: read-only доступ к одному бакету { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"] }] } ``` Правила гигиены: наименьшие привилегии, никаких долгоживущих ключей в коде/CI (используйте роли + OIDC), отдельные роли на сервис, регулярный аудит (Access Analyzer / IAM Recommender). ## Подводные камни / gotchas - **Объектное хранилище ≠ файловая система**: нет append/частичной записи, «папки» — фикция, rename = copy+delete. Не стройте на S3 БД или общий мутабельный стейт. - **At-least-once доставка очередей** ⇒ дубликаты неизбежны. Без идемпотентности — двойные списания/письма. FIFO/exactly-once смягчает, но дороже и медленнее. - **Исчерпание соединений к managed БД** из serverless: тысячи инстансов × пул = лимит БД превышен. Нужен пулер или connection-aware дизайн. - **Egress-трафик платный** (особенно cross-region, в интернет, между AZ). Архитектура «болтливых» сервисов через регионы дорого обходится. NAT Gateway тоже стоит за трафик. - **Visibility timeout < времени обработки** в SQS — сообщение станет видимым и обработается повторно параллельно. Настраивайте под p99 обработки или продлевайте heartbeat'ом. - **Cold start у Lambda** при больших зависимостях/VPC-привязке. Go помогает (малый бинарь), но VPC ENI и provisioned concurrency — отдельная тема. - **Широкие IAM-политики** (`"Action": "*"`, `"Resource": "*"`) — частая дыра. Wildcard-доступ к S3/секретам = инцидент при компрометации. - **Региональность и зональность**: ресурс в одной зоне/регионе недоступен из другой без репликации; падение зоны кладёт single-AZ ресурсы. Multi-AZ ≠ бесплатно. - **Стоимость холодного хранилища**: Glacier дёшев за хранение, но извлечение медленное и платное — не для горячих данных. ## Вопросы на собеседовании **В:** Когда выбрать Lambda/Cloud Functions, а когда контейнеры (Cloud Run/ECS)? **О:** FaaS — для событийной/рваной нагрузки, glue-логики, cron, где важна нулевая операционка и оплата за вызовы. Контейнеры (Cloud Run/Fargate) — для постоянных HTTP-сервисов, длительных/конкуррентных задач, контроля рантайма. Для Go под HTTP Cloud Run обычно эффективнее: один инстанс обслуживает много запросов горутинами (concurrency), тогда как Lambda — запрос-на-инстанс. **В:** Чем объектное хранилище отличается от файловой системы и блочного диска? **О:** Объектное (S3/GCS) — плоское key→bytes, нет частичной записи (PUT целиком), нет директорий (только префиксы), rename = copy+delete, оплата за объём+запросы+трафик, масштабируется почти бесконечно. Блочное (EBS/PD) — это «диск» для VM с частичной записью и IOPS, привязан к зоне. ФС поверх блочного даёт POSIX-семантику. На S3 нельзя строить мутабельный стейт как на ФС. **В:** В чём разница между SQS и SNS, и как сделать надёжный fan-out в AWS? **О:** SQS — очередь point-to-point: сообщение читает один консьюмер. SNS — pub/sub fan-out: одно сообщение уходит всем подписчикам, но без буферизации/ретраев на стороне получателя. Надёжный fan-out — SNS topic → несколько SQS-очередей (каждый консьюмер читает свою очередь со своим темпом, DLQ, ретраями). В GCP это одним сервисом: Pub/Sub topic с несколькими subscriptions. **В:** Почему обработчик сообщений из очереди должен быть идемпотентным? **О:** Потому что облачные очереди дают at-least-once доставку: сбой консьюмера до удаления сообщения, истечение visibility timeout, ретраи — всё ведёт к повторной доставке. Если обработка не идемпотентна (нет дедупликации по message-id/бизнес-ключу или транзакционной защиты), получаем дублирующиеся эффекты — двойные списания, повторные письма. **В:** Что вы теряете и что получаете, переходя на managed БД (RDS/Cloud SQL)? **О:** Получаете: автоматические бэкапы и PITR, патчи, Multi-AZ HA с failover, read-replicas, мониторинг — минус операционка. Теряете: суперюзера, произвольные расширения/версии, прямой доступ к конфигам ОС и `postgresql.conf` (только parameter groups), иногда отставание по новым версиям и более высокую цену за тот же ресурс. **В:** Как сервису в облаке безопасно получать доступ к ресурсам без статичных ключей? **О:** Через роли/identity, привязанные к самому compute: в AWS — IAM role на EC2/ECS task/Lambda (временные креды от STS), в GCP — service account на инстансе/Cloud Run, в GKE — Workload Identity (k8s SA ↔ GCP SA). Для CI — OIDC-федерация. Это убирает долгоживущие ключи, даёт автоматическую ротацию и привязку прав к конкретному воркладу. **В:** Как не выесть лимит соединений managed БД из serverless-сервиса? **О:** Serverless масштабируется до многих инстансов, каждый со своим пулом — суммарно превышает лимит БД. Решения: внешний пулер (RDS Proxy, Cloud SQL connector, PgBouncer), жёсткий `SetMaxOpenConns` на инстанс, использование транзакционного пулинга, и `ConnMaxLifetime`, чтобы корректно подхватывать failover. **В:** Как работает IAM-модель и что значит «deny побеждает»? **О:** Доступ описывается как principal → action → resource → condition. В AWS запрос разрешён, только если есть явный Allow и нет ни одного явного Deny — explicit deny всегда перекрывает любой allow. По умолчанию всё запрещено. Принцип наименьших привилегий: давать минимально необходимые action на конкретные ресурсы, избегать wildcard. ## На что копают на senior+ - Дизайн под отказоустойчивость: Multi-AZ vs Multi-Region, RTO/RPO, как failover влияет на соединения и кэши, чтение из реплик и lag. - Cost engineering: egress/NAT-стоимость, классы хранения и lifecycle, spot/preemptible, right-sizing, savings plans, FinOps-мышление. - Идемпотентность и exactly-once в распределённой обработке: дедупликация, outbox-паттерн, транзакционная публикация событий. - Сетевая модель: VPC, приватные подсети, endpoints/PrivateLink (доступ к S3/БД без интернета), security groups, egress-контроль. - Безопасность данных: шифрование at-rest/in-transit, KMS/CMEK, ротация ключей, secret manager, отзыв доступа. - Выбор БД под задачу: реляционка vs DynamoDB/Spanner, single-table design, hot partition, глобальное масштабирование и его цена консистентности.