Собеседование на Go-разработчика, System Design

27 сентября 2023 г. · 22 мин. чтения

Сегодня мы разберём процесс проведения технического собеседования на позицию системного дизайнера, в ходе которого кандидат должен спроектировать архитектуру сервиса, аналогичного Twitter. Интервью проводится в формате МОК-теста с участием опытного интервьюера, который оценивает навыки проектирования, умение собирать требования, выбирать подходящие технологии и обосновывать свои решения. Помимо основной задачи, обсуждаются аспекты масштабируемости, надёжности, хранения данных, а также современные подходы к построению распределённых систем.

Вопрос 1. Расскажите о себе — кто вы, чем занимаетесь, какой у вас опыт и какие технологии используете?

Таймкод: 00:03:12

Ответ собеседника: Правильный. Кандидат представился, сообщил что основной язык — Go, на котором пишет уже около 11-12 лет, ранее писал на Python. Последние 3+ года работает с Go, включая concurrency. Прошёл курс по Go от навыков, который помог получить оффер в компанию, занимающуюся разработкой на Go. Упомянул интерес к переходу в компанию с Go-стеком.

Правильный ответ:

Отличный старт — кандидат чётко обозначил свой основной стек и опыт. Для полноценного ответа на этот вопрос на собеседовании стоит структурировать самопрезентацию следующим образом:

1. Кто вы и чем занимаетесь

Кратко представьтесь: имя, текущая роль, основной язык и область деятельности. Например: «Я Go-разработчик с 11-12 годами опыта в бэкенд-разработке. Последние 3+ года работаю преимущественно на Go, до этого писал на Python.»

2. Ключевой опыт и проекты

Опишите 1–2 значимых проекта, над которыми работали. Важно упомянуть:

Архитектурные решения, которые принимали
Масштаб системы (RPS, объём данных, количество сервисов)
Конкретные технические вызовы и как вы их решали

3. Технологический стек

Перечислите ключевые технологии, с которыми работаете:

Язык: Go (основной), Python (предыдущий)
Базы данных: PostgreSQL, MySQL, Redis, MongoDB — укажите, с какими работали
Брокеры сообщений: Kafka, RabbitMQ, NATS
Инфраструктура: Docker, Kubernetes, CI/CD
Мониторинг: Prometheus, Grafana, Jaeger

4. Интересы и мотивация

Завершите тем, что привлекает в новой компании: «Интересно работать в компании с Go-стеком, где могу применить опыт с concurrency и микросервисной архитектурой.»

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

Вопрос 2. Какой объём трафика на запись и чтение ожидать — сколько сообщений в день будут писать пользователи и сколько раз будет читаться лента?

Таймкод: 00:13:47

Ответ собеседника: Неполный. Кандидат начал расчёт нагрузки, но запутался в соотношениях. При 150 млн активных пользователей, пишущих в среднем по 1 сообщению в день, получилось 150 млн сообщений в день. Размер одного сообщения принят 800 байт. Кандидат получил около 112 млрд байт (~104 ГБ/день), но интервьюер поправил до ~120 ГБ/день. Соотношение чтение/запись 1:50 было дано, но кандидат не успел полностью посчитать итоговую нагрузку на чтение.

Правильный ответ:

Расчёт нагрузки на запись

Исходные данные:

150 млн активных пользователей в день (DAU)
В среднем 1 сообщение на пользователя в день
Размер одного сообщения: 800 байт

Запись в день = 150 000 000 × 800 байт = 120 000 000 000 байт ≈ 120 ГБ/день

Переводим в секунды для понимания RPS:

120 ГБ/день ÷ 86 400 сек ≈ 1.39 МБ/сек
150 000 000 сообщений ÷ 86 400 сек ≈ 1 736 RPS (записей/сек)

Расчёт нагрузки на чтение

Соотношение чтение/запись = 50:1 — это типично для лент новостей, где каждый пост читается множество раз.

Чтение в день = 150 000 000 × 50 = 7 500 000 000 операций чтения/день
RPS чтения = 7 500 000 000 ÷ 86 400 ≈ 86 805 RPS ≈ 87K RPS

Итоговая картина нагрузки

Метрика	Запись	Чтение
Операций/день	150 млн	7.5 млрд
RPS (средний)	~1.7K	~87K
Трафик/день	~120 ГБ	Зависит от размера ответа

Важные уточнения для интервью

Пиковые нагрузки. Средний RPS — это лишь отправная точка. Пиковая нагрузка обычно в 3–5 раз выше средней, особенно в вечерние часы. Для чтения это означает пик до 250–400K RPS.

Размер ответа при чтении. При чтении ленты возвращается не одно сообщение, а список (например, 20 постов). Если каждый пост в ответе занимает ~500 байт (без медиа), то:

Трафик чтения = 7.5 млрд × 20 × 500 байт = 75 ТБ/день

Распределение нагрузки. Нагрузка неравномерна — 70% трафика приходится на 16 часов активности, а не на все 24 часа. Это увеличивает пиковые значения ещё в 1.5 раза.

Практический вывод для проектирования

При таких объёмах необходимо:

Кэширование лент в Redis/Memcached (чтение доминирует в 50 раз)
Шардирование базы данных по user_id
CDN для медиаконтента
Асинхронная запись через брокер сообщений (Kafka) для сглаживания пиков
Предвычисленные ленты (fan-out on write) для активных пользователей

Вопрос 3. Предложите высокоуровневую архитектуру системы — какие микросервисы или компоненты вы выделите для реализации функциональных требований (отправка/получение сообщений, подписка, лента постов)?

Таймкод: 00:32:00

Ответ собеседника: Правильный. Кандидат предложил разделить систему на несколько сервисов: сервис твитов (принимает и сохраняет сообщения), сервис пользователей (хранит данные пользователей и подписки), сервис лент (формирует ленту постов). Между пользователем и сервисами размещается API Gateway / Load Balancer для маршрутизации запросов. Для каждого сервиса предполагается своё хранилище данных. Схема была нарисована на доске и описана словами.

Правильный ответ:

Основные микросервисы

1. API Gateway / Load Balancer

Точка входа для всех клиентских запросов. Выполняет маршрутизацию, аутентификацию, rate limiting, SSL termination. Можно использовать Nginx, Kong, или собственное решение на Go.

2. User Service (Сервис пользователей)

Отвечает за регистрацию, авторизацию, профили и управление подписками. Хранит данные пользователей и граф подписок в реляционной БД (PostgreSQL) или графовой базе для сложных запросов по связям.

3. Tweet Service (Сервис сообщений)

Принимает новые сообщения, валидирует, сохраняет в базу данных. При публикации сообщения отправляет событие в брокер сообщений (Kafka) для дальнейшей обработки — формирования лент, уведомлений, индексации.

4. Feed Service (Сервис лент)

Формирует и отдаёт ленту постов пользователя. Использует кэш (Redis) для хранения предвычисленных лент. При запросе ленты сначала проверяет кэш, при промахе — собирает из базы.

5. Notification Service (Сервис уведомлений)

Подписывается на события из Kafka и отправляет push-уведомления, email или in-app уведомления при новых сообщениях, подписках, лайках.

6. Media Service (Сервис медиа)

Обрабатывает загрузку изображений и видео, хранит в объектном хранилище (S3/MinIO), отдаёт через CDN.

Вспомогательные компоненты

Брокер сообщений (Kafka)

Связывает сервисы асинхронно. При публикации твита Tweet Service отправляет событие в топик, на который подписаны Feed Service (для обновления лент), Notification Service и другие потребители.

Кэш (Redis)

Хранит предвычисленные ленты пользователей, сессии, счётчики. Критически важен для снижения нагрузки на базу данных при чтении.

Хранилища данных

Каждый сервис имеет свою базу данных (Database per Service):

User Service → PostgreSQL (реляционные данные, подписки)
Tweet Service → Cassandra или ScyllaDB (высокая пропускная способность на запись, временные ряды)
Feed Service → Redis (кэш лент) + PostgreSQL (долгосрочное хранение)
Media Service → S3/MinIO (объектное хранилище)

Схема взаимодействия

Клиент → API Gateway → [User Service | Tweet Service | Feed Service]
                                      ↓
                                   Kafka
                                      ↓
                   [Feed Service | Notification Service | Search Service]

Ключевые архитектурные решения

Fan-out стратегия для лент. Для обычных пользователей используется fan-out on write — при публикации твита он сразу добавляется в ленты всех подписчиков. Для знаменитостей с миллионами подписчиков — fan-out on read, чтобы не создавать миллионы записей на один твит.

Асинхронность через Kafka. Развязывает сервисы по времени и нагрузке. Tweet Service не знает о существовании Feed Service — он просто публикует событие.

Кэширование лент. Лента пользователя хранится в Redis в виде отсортированного множества (sorted set) с временной меткой в качестве оценки. Это позволяет быстро получать последние N постов.

Вопрос 4. Как обеспечить низкую латентность запроса ленты (~200 мс) при большом объёме данных? Какое хранилище выбрать для твитов и как организовать формирование ленты?

Таймкод: 00:45:00

Ответ собеседника: Неполный. Кандидат предложил использовать графовую БД для хранения подписок пользователей и PostgreSQL с репликами для данных пользователей. Для хранилища твитов предложил использовать Cassandra или другую NoSQL БД, рассчитанную на большие объёмы данных. Однако кандидат не успел предложить конкретный механизм оптимизации формирования ленты (fan-out / precomputed feed) для достижения требуемых 200 мс латентности.

Правильный ответ:

Выбор хранилища для твитов

Для хранения твитов оптимальна Cassandra или ScyllaDB по следующим причинам:

Высокая пропускная способность на запись (сотни тысяч записей в секунду)
Линейная масштабируемость через добавление нод
Естественная модель данных — временные ряды, где ключом является user_id, а кластеризующий ключ — timestamp
Настраиваемая консистентность (QUORUM для критичных операций, ONE для чтения)

Схема таблицы в Cassandra:

CREATE TABLE tweets (
    user_id  uuid,
    tweet_id timeuuid,
    content  text,
    created_at timestamp,
    PRIMARY KEY (user_id, tweet_id)
) WITH CLUSTERING ORDER BY (tweet_id DESC);

Стратегия формирования ленты: Fan-out on Write

Ключевая идея — лента должна быть предвычислена и лежать в кэше, чтобы запрос ленты не требовал сложных JOIN-ов в реальном времени.

Как это работает:

Пользователь публикует твит → Tweet Service сохраняет в Cassandra
Tweet Service отправляет событие в Kafka
Feed Service подписан на топик Kafka, получает событие
Feed Service запрашивает список подписчиков из User Service
Для каждого подписчика добавляет tweet_id в его кэш ленты в Redis

Реализация в Redis:

// При публикации твита — добавляем в ленты всех подписчиков
func (s *FeedService) FanOutTweet(ctx context.Context, tweetID string, authorID string) error {
    followers, err := s.userService.GetFollowers(ctx, authorID)
    if err != nil {
        return err
    }
    
    pipe := s.redis.Pipeline()
    for _, followerID := range followers {
        key := fmt.Sprintf("feed:%s", followerID)
        // Добавляем в sorted set с временной меткой как score
        pipe.ZAdd(ctx, key, redis.Z{
            Score:  float64(time.Now().Unix()),
            Member: tweetID,
        })
        // Обрезаем до последних 1000 твитов — экономим память
        pipe.ZRemRangeByRank(ctx, key, 0, -1001)
        // Устанавливаем TTL — 7 дней
        pipe.Expire(ctx, key, 7*24*time.Hour)
    }
    
    _, err = pipe.Exec(ctx)
    return err
}

Запрос ленты — O(1) из кэша:

func (s *FeedService) GetFeed(ctx context.Context, userID string, limit int) ([]string, error) {
    key := fmt.Sprintf("feed:%s", userID)
    
    // Получаем последние N tweet_id из Redis — это миллисекунды
    tweetIDs, err := s.redis.ZRevRange(ctx, key, 0, int64(limit-1)).Result()
    if err != nil {
        return nil, err
    }
    
    // Если кэш пуст — fallback на сбор из базы (медленный путь)
    if len(tweetIDs) == 0 {
        return s.buildFeedFromDB(ctx, userID, limit)
    }
    
    // Загружаем полные данные твитов из Cassandra по ID
    tweets, err := s.tweetService.GetByIDs(ctx, tweetIDs)
    return tweets, err
}

Обработка знаменитей (celebrity problem)

Для пользователей с миллионами подписчиков fan-out on write создаёт слишком большую нагрузку. Решение — гибридный подход:

Пользователи с < 10K подписчиков → fan-out on write (предвычисленная лента)
Пользователи с > 10K подписчиков → fan-out on read (их твиты подтягиваются при запросе ленты)

const celebrityThreshold = 10000

func (s *FeedService) FanOutTweet(ctx context.Context, tweetID string, authorID string) error {
    followerCount, err := s.userService.GetFollowerCount(ctx, authorID)
    if err != nil {
        return err
    }
    
    // Знаменитость — не делаем fan-out, твит будет подтянут при чтении
    if followerCount > celebrityThreshold {
        return nil
    }
    
    // Обычный пользователь — стандартный fan-out
    return s.fanOutToFollowers(ctx, tweetID, authorID)
}

Дополнительные оптимизации для достижения 200 мс

Мультиуровневое кэширование:

L1 — локальный кэш в памяти сервиса (LRU, ~100ms TTL)
L2 — Redis кластер (~10ms на запрос)
L3 — Cassandra (~50-100ms на запрос)

Параллельная загрузка данных:

func (s *FeedService) GetFeedParallel(ctx context.Context, userID string) (*Feed, error) {
    tweetIDs := s.getCachedFeed(userID)
    
    // Загружаем твиты и данные пользователей параллельно
    var tweets []Tweet
    var users map[string]User
    
    errGroup, ctx := errgroup.WithContext(ctx)
    
    errGroup.Go(func() error {
        var err error
        tweets, err = s.tweetService.GetByIDs(ctx, tweetIDs)
        return err
    })
    
    errGroup.Go(func() error {
        var err error
        users, err = s.userService.GetByIDs(ctx, extractUserIDs(tweetIDs))
        return err
    })
    
    if err := errGroup.Wait(); err != nil {
        return nil, err
    }
    
    return assembleFeed(tweets, users), nil
}

Размер кэша ленты. Хранить последние 1000 твитов на пользователя в Redis. При 800 байт на tweet_id + overhead — это ~1 МБ на пользователя. Для 150 млн пользователей — 150 ТБ, что требует большого Redis-кластера. На практике кэшируем только активных пользователей (те, кто заходил за последние 7 дней).

Итоговый бюджет латентности:

Redis ZRevRange: ~5ms
Cassandra batch get по ID: ~30ms
Сериализация ответа: ~5ms
Сеть + API Gateway: ~20ms
Итого: ~60ms — с запасом укладываемся в 200ms

Вопрос 5. Как организовать масштабирование сервисов для 250 млн пользователей с учётом географического распределения? Как маршрутизировать запросы к ближайшему экземпляру сервиса?

Таймкод: 01:02:39

Ответ собеседника: Правильный. Кандидат согласился, что каждый сервис может масштабироваться горизонтально по мере роста нагрузки. Для географического распределения предложил использовать GeoDNS или аналогичные механизмы, чтобы маршрутизировать запросы конкретного пользователя к ближайшему экземпляру сервиса. Также обсудили необходимость развертывания сервисов внескольких регионах.

Правильный ответ:

Горизонтальное масштабирование сервисов

Каждый микросервис должен быть stateless — это позволяет добавлять инстансы без изменения логики. Масштабирование управляется через Kubernetes HPA (Horizontal Pod Autoscaler) на основе метрик CPU, пользовательских метик (RPS, latency) или длины очереди в Kafka.

# Пример HPA для Feed Service
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: feed-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: feed-service
  minReplicas: 10
  maxReplicas: 500
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

Географическое распределение

GeoDNS (Route 53, Cloudflare)

DNS-сервер определяет регион пользователя по IP-адресу и возвращает IP ближайшего дата-центра. Это самый простой уровень маршрутизации.

Пользователь из Москвы → DNS возвращает IP европейского кластера
Пользователь из Нью-Йорка → DNS возвращает IP американского кластера

Anycast и Global Load Balancer

Более продвинутый подход — использование Anycast IP или облачного Global Load Balancer (GCP Global LB, AWS Global Accelerator). Запрос автоматически маршрутизируется к ближайшему региону на уровне сети, без задержек DNS-резолва.

Маршрутизация пользователя к конкретному региону

Важно не просто направить пользователя в ближайший регион, но и обеспечить привязку данных — пользователь должен всегда попадать в один и тот же регион, где хранятся его данные.

// Определение региона пользователя по user ID
func GetUserRegion(userID string) string {
    // Вариант 1: Хэш от user ID для равномерного распределения
    hash := fnv32(userID)
    regions := []string{"eu-west", "us-east", "us-west", "asia-pacific"}
    return regions[hash%uint32(len(regions))]
}

// Вариант 2: Хранение региона пользователя в базе
func (s *UserService) GetRegion(ctx context.Context, userID string) (string, error) {
    // Проверяем кэш
    region, err := s.redis.Get(ctx, "user_region:"+userID).Result()
    if err == nil {
        return region, nil
    }
    
    // Загружаем из базы
    user, err := s.db.GetUser(ctx, userID)
    if err != nil {
        return "", err
    }
    
    // Кэшируем на 24 часа
    s.redis.Set(ctx, "user_region:"+userID, user.Region, 24*time.Hour)
    return user.Region, nil
}

Репликация данных между регионами

Асинхронная репликация через Kafka MirrorMaker:

Регион EU → Kafka EU → MirrorMaker → Kafka US → Сервисы US

Это позволяет каждому региону иметь локальную копию данных с задержкой в секунды.

Стратегия размещения данных:

Тип данных	Стратегия	Обоснование
Профили пользователей	Репликация во все регионы	Читаются часто, пишутся редко
Твиты	Шардирование по региону автора + репликация	Пишутся в одном регионе, читаются глобально
Ленты	Локальные кэши в каждом регионе	Предвычисляются локально
Подписки	Репликация во все регионы	Небольшой объём, нужны везде

Affinity routing на уровне API Gateway:

// Middleware для маршрутизации к нужному региону
func RegionAffinityMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        userID := c.GetHeader("X-User-ID")
        if userID == "" {
            c.Next()
            return
        }
        
        targetRegion := GetUserRegion(userID)
        currentRegion := os.Getenv("REGION")
        
        if targetRegion != currentRegion {
            // Проксируем запрос в нужный регион
            proxyURL := fmt.Sprintf("https://%s.api.example.com%s", targetRegion, c.Request.URL.Path)
            proxyRequest(c, proxyURL)
            c.Abort()
            return
        }
        
        c.Next()
    }
}

Проблемы и решения

Проблема миграции пользователя. Если пользователь переехал в другой регион, нужно перенести его данные. Решение — фоновая миграция с двойной записью в оба региона в течение переходного периода.

Консистентность данных. Между регионами репликация асинхронная, поэтому возможны временные несогласованности. Для критичных операций (подписка, публикация) используем запись в домашний регион и синхронное подтверждение.

Стоимость. Репликация данных увеличивает затраты на хранение и трафик между регионами. Оптимизация — реплицировать только горячие данные (последние 7 дней), архивные хранить в одном регионе с доступом через API.

Вопрос 6. Какие метрики и мониторинг нужно собирать для каждого сервиса, чтобы обеспечить надёжную работу системы? Какие бизнес-метрики важны?

Таймкод: 01:05:59

Ответ собеседника: Правильный. Кандидат предложил собирать стандартные инфраструктурные метрики (CPU, память, диски), логи (с помощью ELK-стека), метрики успешности ответов (HTTP 2xx/5xx), статистику ошибок, а также бизнес-метрики: количество созданных твитов в день, количество активных пользователей в день/час. Также упомянул необходимость алертов на основе этих метрик.

Правильный ответ:

Инфраструктурные метрики (RED методология)

Для каждого сервиса собираются три ключевые группы метрик:

Rate (Скорость запросов):

RPS (requests per second) на каждый endpoint
Количество входящих сообщений из Kafka в секунду
Скорость записи/чтения из базы данных

Errors (Ошибки):

Процент ошибок 4xx и 5xx по каждому endpoint
Количество таймаутов при обращении к зависимым сервисам
Количество dead letter messages в Kafka
Rate ошибок подключения к БД и Redis

Duration (Длительность):

Latency p50, p95, p99 для каждого endpoint
Время обработки сообщения из Kafka
Время выполнения запросов к БД
Время fan-out при публикации твита

Реализация в Go с Prometheus:

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promauto"
)

var (
    requestDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "Duration of HTTP requests",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "endpoint", "status"},
    )
    
    requestCount = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )
    
    kafkaLag = promauto.NewGaugeVec(
        prometheus.GaugeOpts{
            Name: "kafka_consumer_lag",
            Help: "Consumer lag per partition",
        },
        []string{"topic", "partition"},
    )
    
    cacheHitRate = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "cache_operations_total",
            Help: "Cache hits and misses",
        },
        []string{"operation", "result"}, // result: hit, miss
    )
)

func metricsMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        start := time.Now()
        c.Next()
        duration := time.Since(start).Seconds()
        
        status := strconv.Itoa(c.Writer.Status())
        requestDuration.WithLabelValues(c.Request.Method, c.FullPath(), status).Observe(duration)
        requestCount.WithLabelValues(c.Request.Method, c.FullPath(), status).Inc()
    }
}

Метрики зависимостей

База данных:

Количество активных соединений в пуле
Время выполнения запросов (slow queries > 100ms)
Количество deadlocks и retry
Replication lag для реплик

Redis:

Hit rate (доля попаданий в кэш) — целевое значение > 95%
Использование памяти
Количество evicted keys
Время выполнения команд

Kafka:

Consumer lag — отставание обработки от поступления сообщений
Количество сообщений в топиках
Скорость продюсеров и потребителей

Бизнес-метрики

Активность пользователей:

DAU (Daily Active Users) — ежедневные активные пользователи
MAU (Monthly Active Users) — ежемесячные активные пользователи
DAU/MAU ratio — вовлечённость (stickiness)
Количество новых регистраций в день/час

Контент-метрики:

Количество опубликованных твитов в минуту/час/день
Среднее количество твитов на пользователя
Количество медиа-загрузок
Распределение длины твитов

Метрики лент:

Время формирования ленты (p50, p95, p99)
Количество твитов в средней ленте
Доля лент, собранных из кэша vs из БД
Fan-out latency — время распространения твита по лентам подписчиков

Метрики подписок:

Количество новых подписок/отписок в час
Среднее количество подписок на пользователя
Количество «знаменитей» (пользователей с > 10K подписчиков)

Алерты

Критические алерты (PagerDuty, немедленная реакция):

Latency p99 > 500ms для ключевых endpoints
Error rate > 1% для любого сервиса
Kafka consumer lag > 100K сообщений
Redis hit rate < 90%
Диск заполнен > 85%

Предупреждения (Slack, реакция в течение часа):

Latency p95 > 300ms
Error rate > 0.5%
Рост трафика на 50% за 15 минут (возможная DDoS)
Снижение DAU на 20% от нормы

Распределённая трассировка (Distributed Tracing)

Для отслеживания запроса через все сервисы используется Jaeger или Zipkin:

import "go.opentelemetry.io/otel"

func (s *FeedService) GetFeed(ctx context.Context, userID string) (*Feed, error) {
    tracer := otel.Tracer("feed-service")
    ctx, span := tracer.Start(ctx, "GetFeed")
    defer span.End()
    
    span.SetAttributes(attribute.String("user.id", userID))
    
    // Запрос в Redis с дочерним span
    ctx, redisSpan := tracer.Start(ctx, "Redis.GetFeed")
    tweetIDs, err := s.redis.ZRevRange(ctx, "feed:"+userID, 0, 19).Result()
    redisSpan.End()
    
    if err != nil {
        span.RecordError(err)
        return nil, err
    }
    
    // Запрос в Cassandra
    ctx, dbSpan := tracer.Start(ctx, "Cassandra.GetTweets")
    tweets, err := s.tweetRepo.GetByIDs(ctx, tweetIDs)
    dbSpan.End()
    
    return tweets, err
}

Это позволяет видеть полный путь запроса: API Gateway → Feed Service → Redis → Cassandra и точно определять, где возникает задержка.

Дашборды Grafana

Рекомендуется создать отдельные дашборды для:

Обзора системы (SLA, доступность, ключевые метрики)
Каждого микросервиса (детальные метрики)
Инфраструктуры (БД, Redis, Kafka)
Бизнес-метрик (DAU, контент, вовлечённость)

Вопрос 7. Какие есть вопросы или комментарии по итогам интервью?

Таймкод: 01:15:56

Ответ собеседника: Правильный. В финальной части обсуждались организационные вопросы: стоимость мок-интервью (3900 руб.), скидка 5000 руб. на обучение, возможность выбора инструмента для проектирования, уровни грейдов в разных компаниях (Amazon, Авито и др.), а также кандидат поделился впечатлениями — вторая часть (системный дизайн) ему понравилась больше, чем первая (алгоритмы), и он отметил, что нехватка времени — это нормальная ситуация на реальных собеседованиях.

Правильный ответ:

Это организационный вопрос, не требующий технического ответа. Однако стоит дать рекомендации, какие вопросы полезно задать на финальной стадии реального собеседования.

Вопросы о техническом стеке и архитектуре:

Какой текущий стек технологий? Какие языки и фреймворки используются?
Как устроена архитектура — микросервисы или монолит?
Какой объём трафика обслуживает система?
Есть ли планы по миграции или переходу на новые технологии?

Вопросы о процессах разработки:

Как устроен процесс разработки — Scrum, Kanban?
Как происходит code review?
Какой покрытие тестами? Есть ли практика TDD?
Как организован CI/CD?
Есть ли on-call дежурства?

Вопросы о команде:

Какого размера команда? Как распределены роли?
Как происходит онбординг новых разработчиков?
Есть ли менторство и возможности для роста?
Как часто проводятся технические митапы и knowledge sharing?

Вопросы о задачах:

Какие задачи будут в первые 1–3 месяца?
Какие технические вызовы стоят перед командой сейчас?
Есть ли техдолг и как с ним работают?

Вопросы о грейдах и росте:

Как устроена система грейдов в компании?
Какие критерии перехода на следующий уровень?
Как часто проводятся performance review?

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

Вопрос 8. Зачем спрашивают внутреннее устройство базовых структур данных (например, HashMap, бакеты) на собеседовании? Это же карго-культ?

Таймкод: 01:35:58

Ответ собеседника: Правильный. Интервьюер и кандидат обсудили, что знание внутреннего устройства структур данных позволяет кандидату не «стрелять себе в ногу». В Go ограничение на 8 элементов в бакете снижает необходимость глубокого знания, тогда как в Java отсутствие такого ограничения может привести к деградации HashMap до связанного списка, если не понимать работу бакетов и хеш-функций. Знание этих нюансов помогает писать эффективный код и избегать проблем производительности.

Правильный ответ:

Это отличный вопрос, который часто вызывает споры среди разработчиков. Давайте разберём, почему знание внутреннего устройства структур данных действительно важно.

Почему это не карго-культ

1. Понимание сложности операций. Когда вы знаете, что HashMap в среднем даёт O(1) на вставку и поиск, но в худшем случае деградирует до O(n), вы можете осознанно выбирать структуру данных. Например, если ключи — пользовательские объекты с плохим hashCode, вместо HashMap лучше использовать TreeMap с гарантированным O(log n).

2. Предсказание поведения под нагрузкой. В Java HashMap при загрузке выше load factor (по умолчанию 0.75) происходит rehashing — дорогая операция копирования всех элементов. Если вы создаёте HashMap на 1 млн элементов без указания initial capacity, вы получите ~13 рехешей во время заполнения. Зная это, вы сразу напишете:

// Плохо — множественные rehash
Map<String, User> users = new HashMap<>();

// Хорошо — один размер с запасом
Map<String, User> users = new HashMap<>(1_500_000);

3. Отладка и профилирование. Когда профайлер показывает, что 30% времени уходит в hashCode(), вы понимаете, что проблема в коллизиях и можете либо улучшить хеш-функцию, либо выбрать другую структуру.

Особенности Go map

В Go map устроена интереснее, чем в Java:

// Go map — это хеш-таблица с бакетами по 8 элементов
// При переполнении бакета создаётся overflow bucket (связанный список)
// При достижении определённой нагрузки происходит эвакуация (incremental rehash)

// Компилятор Go оптимизирует маленькие map
// map с <= 8 элементами хранится как массив пар, а не хеш-таблица

Практический пример — кастомный ключ в Go:

type Point struct {
    X, Y int
}

// Плохой ключ — все точки попадают в один бакет
func (p Point) Hash() int {
    return 0 // коллапс в связанный список, O(n) вместо O(1)
}

// Хороший ключ — равномерное распределение
func (p Point) Hash() int {
    return p.X*31 + p.Y
}

// В Go для struct как ключа map компилятор сам генерирует hash
// Но если используете interface{} или кастомный тип — важно понимать последствия

Когда это действительно карго-культ

Вопрос становится карго-культом, если интервьюер спрашивает:

Точную формулу хеш-функции конкретной реализации
Размер заголовка bucket в байтах
Порядок полей в структуре runtime внутри компилятора

Эти детали не влияют на повседневную работу и меняются между версиями.

Когда это действительно полезно

Выбор между map, sync.Map, concurrent hash map в высоконагруженном сервисе
Понимание, почему профайлер показывает contention на map при параллельном доступсе
Оптимизация памяти при хранении миллионов записей
Понимание, почему Go map не thread-safe и когда нужен sync.RWMutex или sync.Map

// Паттерн: шардирование map для снижения contention
type ShardedMap struct {
    shards [256]struct {
        sync.RWMutex
        data map[string]int
    }
}

func (sm *ShardedMap) getShard(key string) int {
    h := fnv32(key)
    return int(h) % 256
}

func (sm *ShardedMap) Get(key string) (int, bool) {
    shard := sm.getShard(key)
    sm.shards[shard].RLock()
    defer sm.shards[shard].RUnlock()
    val, ok := sm.shards[shard].data[key]
    return val, ok
}

Итог. Знание внутреннего устройства — это не заучивание деталей, а понимание компромиссов. Это позволяет принимать осознанные решения, отлаживать проблемы производительности и выбирать правильные инструменты для задачи.

Вопрос 9. Какие книги порекомендуете для подготовки к System Design собеседованиям?

Таймкод: 01:41:14

Ответ собеседника: Правильный. Интервьюер рекомендовал две основные книги: «System Design Interview» (книга с кабанчиком / Alex Xu) — как шаблон для прохождения собеседования, и «Clean Architecture» Роберта Мартина — как источник идей по архитектуре микросервисов. Кандидат добавил, что также полезна книга «Designing Data-Intensive Applications» (Манфред Клеппманн), которая даёт глубокое понимание распределённых систем, транзакций и гарантий доставки.

Правильный ответ:

Основные книги для подготовки

1. «System Design Interview» — Alex Xu (том 1 и том 2)

Практическое руководство с разбором конкретных задач: проектирование URL-shortener, чат-системы, ленты новостей, видеостриминга. Книга даёт структуру ответа — от уточнения требований до детального проектирования. Это лучший старт для тех, кто хочет быстро освоить формат собеседования.

2. «Designing Data-Intensive Applications» — Martin Kleppmann

Фундаментальная книга, которая объясняет, как работают распределённые системы изнутри. Покрывает репликацию, шардирование, консистентность, транзакции, потоковую обработку данных. После прочтения вы будете понимать компромиссы между различными подходами, а не просто запоминать шаблоны.

3. «Clean Architecture» — Robert C. Martin

Книга о принципах проектирования архитектуры приложений. Разделение на слои, принципы зависимостей, границы между компонентами. Полезна для понимания, как структурировать код внутри микросервисов.

Дополнительная литература

4. «Building Microservices» — Sam Newman

Практическое руководство по проектированию микросервисной архитектуры: декомпозиция, коммуникации, деплой, мониторинг. Хорошо дополняет теорию из DDIA практическими паттернами.

5. «The Art of Scalability» — Martin Abbott

Книга о масштабировании систем и организаций. Модель SCALABLE для анализа узких мест. Полезна для понимания, как масштабирование связано с организационной структурой.

6. «Site Reliability Engineering» — Google (бесплатно онлайн)

Как Google строит и эксплуатирует свои системы. Покрывает SLO/SLI, мониторинг, инцидент-менеджмент, постмортемы. Даёт понимание, как устойчивость системы связана с процессами.

7. «Database Internals» — Alex Petrov

Глубокое погружение в устройство баз — B-деревья, LSM-деревья, индексы, репликация, консенсус. Полезно, когда на собеседовании нужно обосновать выбор между PostgreSQL, Cassandra, RocksDB.

Онлайн-ресурсы

System Design Primer (GitHub, donnemartin) — бесплатный репозиторий с конспектами по всем темам
High Scalability (highscalability.com) — разборы архитектур реальных систем
YouTube: ByteByteGo — видео от Alex Xu с визуальными объяснениями паттернов

Рекомендуемый порядок изучения

Начать с «System Design Interview» — понять формат и структуру ответа
Прочитать «Designing Data-Intensive Applications» — наполнить ответы глубиной
Изучить «Building Microservices» — научиться проектировать границы сервисов
Практиковаться на конкретных задачах из System Design Primer

Такой подход даёт и практические навыки прохождения собеседования, и глубокое понимание распределённых систем.

Вопрос 1. Расскажите о себе — кто вы, чем занимаетесь, какой у вас опыт и какие технологии используете?​

Вопрос 2. Какой объём трафика на запись и чтение ожидать — сколько сообщений в день будут писать пользователи и сколько раз будет читаться лента?​

Вопрос 6. Какие метрики и мониторинг нужно собирать для каждого сервиса, чтобы обеспечить надёжную работу системы? Какие бизнес-метрики важны?​

Вопрос 7. Какие есть вопросы или комментарии по итогам интервью?​

Вопрос 8. Зачем спрашивают внутреннее устройство базовых структур данных (например, HashMap, бакеты) на собеседовании? Это же карго-культ?​

Вопрос 9. Какие книги порекомендуете для подготовки к System Design собеседованиям?​

Вопрос 1. Расскажите о себе — кто вы, чем занимаетесь, какой у вас опыт и какие технологии используете?

Вопрос 2. Какой объём трафика на запись и чтение ожидать — сколько сообщений в день будут писать пользователи и сколько раз будет читаться лента?

Вопрос 6. Какие метрики и мониторинг нужно собирать для каждого сервиса, чтобы обеспечить надёжную работу системы? Какие бизнес-метрики важны?

Вопрос 7. Какие есть вопросы или комментарии по итогам интервью?

Вопрос 8. Зачем спрашивают внутреннее устройство базовых структур данных (например, HashMap, бакеты) на собеседовании? Это же карго-культ?

Вопрос 9. Какие книги порекомендуете для подготовки к System Design собеседованиям?