Григорий Вахмистров, Владимир Иванов: публичное собеседование по System Design

Сегодня мы разберём живое собеседование по системному дизайну, в котором кандидат Вова, опытный инженер и автор блога по архитектуре, под руководством интервьюера Гриши проектирует сервис видеоконференций уровня Google Meet — с поддержкой миллиарда пользователей, до 20 участников в конференции, высокой доступностью и строгими требованиями к задержке. В ходе обсуждения они детально разбирают выбор протоколов (WebRTC vs SIP), топологию передачи медиа (звезда vs полносвязная), вопросы масштабирования, сайзинга серверов с GPU, геораспределения, мониторинга и disaster recovery, демонстрируя глубокое понимание компромиссов между производительностью, стоимостью и скоростью разработки.

Вопрос 1. Какие задачи на системный дизайн вы обычно даете на собеседованиях и на что обращаете внимание?

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

Ответ собеседника: Правильный. Вопрос был адресован соведущему (Грише), а не кандидату. Гриша рассказал, что любит наблюдать за тем, как люди проходят систем дизайн, потому что каждая задача уникальна, а кандидаты предлагают интересные нестандартные решения.

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

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

Типичные задачи на системный дизайн для Golang-позиций:

На собеседованиях на позицию Golang-разработчика уровень задач на системный дизайн зависит от глубины роли:

Для Middle/Senior разработчиков:

• Проектирование высоконагруженного API-сервиса (например, URL-shortener, rate limiter, система очередей)
• Дизайн распределённой системы с акцентом на консистентность, доступность и устойчивость к разделению (CAP-теорема)
• Проектирование микросервисной архитектуры с учётом межсервисного взаимодействия (gRPC, message brokers)

На что обращают внимание интервьюеры:

1. Способность декомпозировать задачу — кандидат должен уметь разбить большую систему на компоненты, определить границы ответственности каждого сервиса.
2. Понимание компромиссов — выбор между SQL и NoSQL, синхронным и асинхронным взаимодействием, консистентностью и доступностью.
3. Практический опыт с Go — как кандидат представляет реализацию компонентов на Go: горутины, каналы, контексты, работа с базами данных, обработка ошибок.
4. Масштабирование — горизонтальное и вертикальное, шардирование, репликация, кэширование.
5. Надёжность и observability — логирование, метрики, трейсинг, graceful shutdown, circuit breakers.

Пример задачи:

> Спроектируйте систему обработки заказов для маркетплейса, которая должна выдерживать 10 000 RPS в пике, гарантировать идемпотентность операций и обеспечивать консистентность данных между сервисами каталога, корзины и оплаты.

Ожидается, что кандидат предложит архитектуру с чётким разделением на сервисы, использование очередей сообщений (Kafka, NATS), паттерны Saga или Outbox для распределённых транзакций, а также обоснует выбор технологий с учётом специфики Go (например, эффективная работа с конкурентностью через goroutine pools).

Вопрос 2. Расскажите немного о себе.

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

Ответ собеседника: Правильный. Кандидат представился как Владимир Иванов, Senior Engineering Manager в компании Т (такси, самокаты и доставка еды в Европе и Африке). Также ведёт блог по архитектуре, YouTube-канал и архитектурную рассылку Architecture Weekly.

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

Кандидат — Владимир Иванов, Senior Engineering Manager в компании «Т», которая занимается такси, самокатами и доставкой еды в Европе и Африке. Параллельно ведёт блог по архитектуре, YouTube-канал и архитектурную рассылку Architecture Weekly.

Как рекомендуется отвечать на вопрос «Расскажите о себе» на собеседовании Golang-разработчика:

Этот вопрос — возможность структурированно представить свой профессиональный профиль. Рекомендуемый формат:

1. Текущая роль и контекст Название компании, домен, масштаб системы, размер команды. Например: «Работаю senior Golang-разработчиком в fintech-компании, где обслуживаю платёжный конвейер с нагрузкой ~5000 RPS.»

2. Ключевой технический стек Go, фреймворки (gin, echo, gRPC), базы данных (PostgreSQL, Redis, ClickHouse), инфраструктура (Kubernetes, Docker, CI/CD), брокеры сообщений (Kafka, NATS, RabbitMQ).

3. Значимые достижения Конкретные метрики и результаты: «Переписал критический сервис с Python на Go, что снизило latency P99 с 200ms до 40ms и уменьшило потребление CPU в 3 раза.»

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

5. Вне работы (опционально) Технический блог, open-source контрибуции, менторство, участие в конференциях — всё это демонстрирует глубину экспертизы и вовлечённость в профессиональное сообщество.

Ответ должен быть лаконичным (2–3 минуты) и подводить к темам, которые кандидат хочет обсудить далее — например, к архитектурным решениям или опыту проектирования распределённых систем.

Вопрос 3. Какой инструмент для видеоконференций выберем для проектирования (Zoom, Google Meet, StreamYard)?

Таймкод: 00:05:06

Ответ собеседника: Правильный. Кандидат выбрал Google Meet как более известный и популярный инструмент.

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

Кандидат выбрал Google Meet, мотивировав это его распространённостью и знакомостью большинству участников.

Обоснование выбора инструмента для секции системного дизайна:

Для проведения секции системного дизайна на собеседовании важны следующие критерии:

1. Надёжность и доступность Инструмент должен работать стабильно, не требовать сложной настройки и быть доступным без установки дополнительного ПО (браузерный доступ предпочтителен).

2. Возможность демонстрации экрана Интервьюеру нужно показать кандидату шаблоны или схему, а кандидату — возможность совместного просмотра диаграмм.

3. Интеграция с инструментами рисования Некоторые команды используют Excalidraw, Miro или Google Jamboard параллельно с видеозвонком, поэтому инструмент не должен конфликтовать с ними.

Сравнение предложенных вариантов:

Критерий	Google Meet	Zoom	StreamYard
Браузерный доступ	Да	Требует клиента (частично)	Да
Демонстрация экрана	Да	Да	Да (для хостов)
Простота подключения	Высокая	Средняя	Средняя
Назначение	Видеоконференции	Видеоконференции	Стриминг

Google Meet — оптимальный выбор для собеседования: не требует установки, работает в браузере, знаком большинству кандидатов и предоставляет все необходимые функции для проведения секции дизайна.

Вопрос 4. Будем ли поддерживать запись звонков или только онлайн-звонки? Какое ограничение на количество участников? Какие дополнительные функции нужны (чат, шаринг экрана)? Нужны ли мобильные приложения или достаточно веб-клиента?

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

Ответ собеседника: Правильный. Только онлайн-звонки без записи. Максимум 20 человек. Добавить чат и шаринг экрана. Начать с веб-клиента.

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

Кандидат определил следующие требования к системе видеоконференций:

Функциональные требования:

• Только онлайн-звонки — запись звонков не поддерживается. Это упрощает архитектуру: не нужна подсистема хранения медиа, управления записями, разграничения доступа к ним.
• До 20 участников в одной сессии — это ключевое ограничение, которое влияет на выбор архитектуры медиасервера.
• Чат — текстовый чат в реальном времени параллельно с видеозвонком.
• Шаринг экрана — возможность демонстрации экрана одним из участников.
• Веб-клиент — мобильные приложения не требуются на первом этапе, достаточно браузерного клиента.

Архитектурные решения, вытекающие из этих требований:

1. Топология медиатрафика

При 20 участниках возможны два подхода:

• Mesh (P2P) — каждый участник отправляет свой поток всем остальным. При 20 участниках это 20 × 19 = 380 соединений, что создаёт огромную нагрузку на клиентские устройства. Непрактично.
• SFU (Selective Forwarding Unit) — центральный сервер принимает потоки от всех участников и пересылает их остальным. Каждый участник отправляет 1 поток и получает 19. Это оптимальный выбор для 20 участников.
• MCU (Multipoint Control Unit) — сервер микширует все потоки в один. Снижает нагрузку на клиент, но требует значительных ресурсов на сервере и вносит задержку при кодировании/декодировании.

Рекомендуется SFU — это стандартный подход для видеоконференций среднего размера (до 50 участников).

2. Протоколы

• WebRTC — основа для передачи медиа в реальном времени в браузере
• WebSocket / gRPC — для сигнального протокола (обмен SDP-описаниями, ICE-кандидатами)
• DataChannel (WebRTC) — для текстового чата

3. Стек технологий для реализации на Go

// Пример структуры SFU-сервиса на Go

package main

import (
    "sync"
    "log"
)

// Peer представляет участника конференции
type Peer struct {
    ID       string
    PC       *webrtc.PeerConnection // WebRTC соединение
    Tracks   []*webrtc.TrackLocalStaticRTP
    mu       sync.RWMutex
}

// Room представляет конференцию
type Room struct {
    ID          string
    Peers       map[string]*Peer
    MaxPeers    int // 20
    mu          sync.RWMutex
}

// SFU маршрутизатор медиапотоков
type SFU struct {
    Rooms map[string]*Room
    mu    sync.RWMutex
}

func (s *SFU) AddPeerToRoom(roomID string, peer *Peer) error {
    s.mu.Lock()
    defer s.mu.Unlock()
    
    room, exists := s.Rooms[roomID]
    if !exists {
        room = &Room{
            ID:       roomID,
            Peers:    make(map[string]*Peer),
            MaxPeers: 20,
        }
        s.Rooms[roomID] = room
    }
    
    room.mu.Lock()
    defer room.mu.Unlock()
    
    if len(room.Peers) >= room.MaxPeers {
        return fmt.Errorf("room is full: max %d peers", room.MaxPeers)
    }
    
    // Подключаем треки нового пира к существующим
    for _, existingPeer := range room.Peers {
        for _, track := range peer.Tracks {
            if _, err := existingPeer.PC.AddTrack(track); err != nil {
                log.Printf("failed to add track: %v", err)
            }
        }
        // И треки существующих пиров к новому
        for _, track := range existingPeer.Tracks {
            if _, err := peer.PC.AddTrack(track); err != nil {
                log.Printf("failed to add track: %v", err)
            }
        }
    }
    
    room.Peers[peer.ID] = peer
    return nil
}

4. Чат через WebRTC DataChannel

// Используем DataChannel вместо отдельного WebSocket для чата
// Это снижает задержки и упрощает инфраструктуру

func (p *Peer) HandleDataChannel(dc *webrtc.DataChannel) {
    dc.OnMessage(func(msg webrtc.DataChannelMessage) {
        chatMsg := ChatMessage{
            From:      p.ID,
            Content:   string(msg.Data),
            Timestamp: time.Now().UnixMilli(),
        }
        // Рассылка всем пирам в комнате
        p.Room.Broadcast(chatMsg, p.ID)
    })
}

5. Шаринг экрана

Реализуется через getDisplayMedia() на стороне браузера — это дополнительный медиатрек, который обрабатывается SFU так же, как и видеокамера. На стороне Go-сервера не требуется специальной логики.

6. Отказ от записи — архитектурные последствия

• Не нужна подсистема медиа-рекординга
• Не нужно хранилище записей (S3-совместимое)
• Не нужна система управления правами доступа к записям
• Упрощается compliance (GDPR и т.д.)

7. MVP без мобильных приложений

WebRTC поддерживается всеми современными браузерами (Chrome, Firefox, Safari, Edge). Веб-клиент на первом этапе покрывает 100% десктоп-пользователей. Мобильные приложения добавляются позже через нативные WebRTC SDK для iOS/Android.

Вопрос 5. Какое ограничение на количество участников в конференции?

Таймкод: 00:06:21

Ответ собеседника: Правильный. Максимум 20 человек в конференции — средний размер, без вебинаров и больших конференций.

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

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

Почему это число критично для архитектуры:

20 участников — это порог, после которого топология SFU начинает создавать значительную нагрузку на сервер, но ещё не требует перехода к каскадированию или гибридным подходам.

Расчёт нагрузки для 20 участников в SFU:

• Каждый участник отправляет 1 видеопоток (uplink)
• Каждый участник получает 19 видеопотоков (downlink)
• Сервер обрабатывает: 20 uplink × 19 пересылок = 380 потоков
• При битрейте ~1.5 Mbps на поток (720p): 380 × 1.5 = 570 Mbps исходящей нагрузки на сервер

Сравнение с другими масштабами:

Участников	Потоков на SFU	Нагрузка (720p)	Требования к серверу
20	380	~570 Mbps	1 сервер, 10 Gbps NIC
100	9900	~15 Gbps	Кластер SFU, балансировка
1000+	~1M	~1.5 Tbps	Каскадные SFU, CDN-подход

Практические следствия ограничения в 20:

1. Один SFU-сервер справляется с нагрузкой — не нужна горизонтальная масштабируемость медиасерверов
2. Simulcast (передача потока в нескольких разрешениях) не обязателен — при 20 участниках можно обойтись одним слоем
3. Bandwidth estimation упрощается — не нужны сложные алгоритмы адаптивного битрейта
4. TURN-сервер может быть один — нагрузка на relay-трафик ограничена
5. Сигнализация через WebSocket или gRPC-stream обрабатывается одним инстансом при таком количестве сессий

// Конфигурация лимита в коде
type RoomConfig struct {
    MaxParticipants     int           `json:"max_participants"`      // 20
    MaxBitrateKbps      int           `json:"max_bitrate_kbps"`      // 1500 (720p)
    VideoCodec          string        `json:"video_codec"`            // "VP8" или "H224"
    EnableSimulcast     bool          `json:"enable_simulcast"`       // false для 20 участников
    EnableRecording     bool          `json:"enable_recording"`       // false по требованию
}

func DefaultRoomConfig() RoomConfig {
    return RoomConfig{
        MaxParticipants: 20,
        MaxBitrateKbps:  1500,
        VideoCodec:      "VP8",
        EnableSimulcast: false,
        EnableRecording: false,
    }
}

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

Вопрос 6. Какие дополнительные функции помимо видео и звука нужно поддерживать (чат, эмодзи, шаринг экрана)?

Таймкод: 00:06:55

Ответ собеседника: Правильный. Кандидат предложил добавить чат и шаринг экрана как базовые функции.

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

Кандидат определил чат и шаринг экрана как дополнительные функции для MVP.

Детализация каждой функции:

1. Текстовый чат

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

Реализация через WebRTC DataChannel предпочтительнее отдельного WebSocket:

• Единый транспорт с медиа — меньше соединений
• Меньшая задержка доставки
• Естественная привязка к сессии — при разрыве WebRTC соединения чат тоже отключается

type ChatMessage struct {
    RoomID    string `json:"room_id"`
    From      string `json:"from"`
    Content   string `json:"content"`
    Timestamp int64  `json:"timestamp"`
    Type      string `json:"type"` // "text", "link", "system"
}

type ChatService struct {
    rooms map[string]*Room
    mu    sync.RWMutex
}

func (cs *ChatService) Broadcast(roomID string, msg ChatMessage, excludePeer string) {
    cs.mu.RLock()
    room, exists := cs.rooms[roomID]
    cs.mu.RUnlock()
    
    if !exists {
        return
    }
    
    data, _ := json.Marshal(msg)
    
    room.mu.RLock()
    defer room.mu.RUnlock()
    
    for peerID, peer := range room.Peers {
        if peerID == excludePeer {
            continue
        }
        if peer.DataChannel != nil && peer.DataChannel.ReadyState() == webrtc.DataChannelStateOpen {
            if err := peer.DataChannel.Send(data); err != nil {
                log.Printf("failed to send chat to %s: %v", peerID, err)
            }
        }
    }
}

2. Шаринг экрана

Технически реализуется на стороне браузера через navigator.mediaDevices.getDisplayMedia(). С точки зрения Go-сервера:

• Это дополнительный видеотрек от одного из участников
• SFU обрабатывает его так же, как обычный видеопоток
• Можно добавить приоритизацию — шаринг экрана имеет более высокий приоритет при bandwidth allocation

type TrackType int

const (
    TrackTypeCamera TrackType = iota
    TrackTypeScreenShare
)

type Track struct {
    ID         string
    Type       TrackType
    PeerID     string
    Track      *webrtc.TrackLocalStaticRTP
    Priority   int // screen share = 2, camera = 1
}

func (s *SFU) HandleScreenShare(peerID string, roomID string, track *webrtc.TrackLocalStaticRTP) {
    screenTrack := &Track{
        ID:       generateTrackID(),
        Type:     TrackTypeScreenShare,
        PeerID:   peerID,
        Track:    track,
        Priority: 2,
    }
    
    s.AddTrackToRoom(roomID, screenTrack)
    
    // Уведомляем всех участников о начале шаринга
    s.NotifyRoom(roomID, Notification{
        Type:   "screen_share_started",
        PeerID: peerID,
    })
}

3. Эмодзи и реакции

Кандидат не упомянул эмодзи, но это простая и полезная функция. Реализуется через тот же DataChannel:

type Reaction struct {
    RoomID    string `json:"room_id"`
    From      string `json:"from"`
    Emoji     string `json:"emoji"` // "👍", "❤️", "😂", "👏"
    Timestamp int64  `json:"timestamp"`
}

// Лёгкий трафик — не требует надёжной доставки
// Можно использовать unordered, unreliable DataChannel mode

Приоритизация функций для MVP:

Функция	Приоритет	Сложность	Обоснование
Видео/аудио	P0	Высокая	Ядро продукта
Чат	P0	Средняя	Критично для UX
Шаринг экрана	P1	Низкая	Дополнительный трек, простая реализация
Эмодзи	P2	Низкая	Приятное дополнение, минимальная разработка
Запись	—	Высокая	Не входит в scope
Вебинарный режим	—	Очень высокая	Не входит в scope (максимум 20 участников)

Вопрос 7. Нужны ли мобильные приложения или достаточно веб-клиента?

Таймкод: 00:07:25

Ответ собеседника: Правильный. Кандидат предложил начать с веб-клиента, мобильные приложения пока не рассматривали.

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

Для MVP достаточно веб-клиента. Мобильные приложения не входят в первую версию продукта.

Обоснование этого решения:

1. Покрытие пользователей

WebRTC поддерживается всеми современными браузерами на десктопах: Chrome, Firefox, Safari, Edge. Это покрывает основную аудиторию — участников рабочих встреч и собеседований.

2. Скорость вывода на рынок (time-to-market)

Веб-клиент не требует:

• Публикации в App Store / Google Play
• Прохождения ревью Apple (которое может занять дни)
• Поддержки двух нативных кодовых баз (Swift/Kotlin)
• Решений проблем с background mode на iOS

3. Снижение барьера входа для пользователя

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

4. Техническая реализация веб-клиента

// Go-сервер отдаёт статику веб-клиента
// и обрабатывает сигнальный протокол

package main

import (
    "net/http"
    "github.com/gorilla/websocket"
    "github.com/pion/webrtc/v3"
)

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return true // В продакшене — строгая проверка
    },
}

func main() {
    // Статика веб-клиента
    fs := http.FileServer(http.Dir("./web"))
    http.Handle("/", fs)
    
    // WebSocket endpoint для сигнализации
    http.HandleFunc("/ws", handleSignaling)
    
    http.ListenAndServe(":8080", nil)
}

func handleSignaling(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Printf("WebSocket upgrade failed: %v", err)
        return
    }
    defer conn.Close()
    
    // Обработка SDP offer/answer, ICE candidates
    for {
        _, msg, err := conn.ReadMessage()
        if err != nil {
            break
        }
        processSignalingMessage(conn, msg)
    }
}

5. Когда понадобятся мобильные приложения

Мобильные приложения стоит рассматривать, когда:

• Появится запрос на участие в конференциях с телефонов
• Потребуется push-уведомления о приглашениях
• Потребуется фоновое аудио при свёрнутом приложении (iOS блокирует WebRTC в background)
• Потребуется интеграция с календарём телефона

Для этого потребуется нативный WebRTC SDK:

• iOS: WebRTC.framework (Pod GoogleWebRTC)
• Android: org.webrtc:google-webrtc
• Кроссплатформенный вариант: Flutter с плагином flutter_webrtc

6. Архитектура с прицелом на мобильные приложения

API сигнализации должен быть спроектирован так, чтобы веб-клиент и мобильные приложения использовали один и тот же backend:

// Универсальный сигнальный протокол
type SignalingMessage struct {
    Type      string          `json:"type"`      // "offer", "answer", "ice_candidate", "join", "leave"
    RoomID    string          `json:"room_id"`
    PeerID    string          `json:"peer_id"`
    Payload   json.RawMessage `json:"payload"`
    ClientType string         `json:"client_type"` // "web", "ios", "android"
}

Это позволяет добавить мобильные приложения позже без переписывания серверной части.

Вопрос 8. Какой масштаб сервиса (пользователи, звонки)? Какие требования к задержке, доступности (availability), безопасности? Нужно ли хранить данные после звонка?

Таймкод: 00:07:43

Ответ собеседника: Правильный. Миллиард пользователей, ~4×10^10 звонков в месяц. Задержка до 1 секунды (до 2 в пике). Доступность — четыре девятки (~52 мин простоя в год). Шифрование + TLS. Данные после звонка удалять.

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

Кандидат определил следующие нефункциональные требования:

Масштаб:

• 1 миллиард пользователей — глобальный масштаб, сравнимый с Zoom или Google Meet
• ~40 миллиардов звонков в месяц — примерно 4 × 10^10, что даёт ~15 000–20 000 звонков в секунду в среднем и до 50 000+ RPS в пике

Задержка (Latency):

• Целевая задержка: до 1 секунды для end-to-end медиа
• До 2 секунд в пиковые периоды — допустимое деградирование

Доступность (Availability):

• Четыре девятки (99.99%) — не более ~52 минут простоя в год
• Для сравнения: три девятки = ~8.7 часов, пять девяток = ~5 минут

Безопасность:

• Шифрование медиа — DTLS-SRTP для WebRTC (встроено в стандарт)
• TLS для сигнализации (WebSocket over WSS)

Хранение данных:

• Данные после звонка удаляются — запись не ведётся, метаданные звонка очищаются

Детализация и архитектурные следствия:

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

40 млрд звонков / месяц = 40 × 10^9 / (30 × 24 × 3600) ≈ 15 432 звонка/секунду (среднее)
Пиковая нагрузка (×3): ~46 000 звонков/секунду
Средняя длительность звонка: ~10 минут
Одновременных звонков: 15 432 × 600 ≈ 9.26 млн
Среднее количество участников на звонок: 5
Одновременных участников: ~46 млн

2. Задержка 1 секунды — что это значит

WebRTC end-to-end задержка складывается из:

• Захват и кодирование: ~50–100ms
• Сетевой транспорт (UDP): ~20–200ms (зависит от географии)
• SFU обработка (jitter buffer, routing): ~10–50ms
• Декодирование и рендеринг: ~30–50ms

Для глобального масштаба 1 секунда — амбициозная, но достижимая цель. Требуется:

• Географически распределённые SFU-серверы — чтобы участники подключались к ближайшему дата-центру
• Edge-серверы для сигнализации
• Anycast IP для минимизации latency первого подключения

3. Доступность 99.99% — архитектурные требования

// Graceful shutdown для минимизации простоев
func (s *SFU) Shutdown(ctx context.Context) error {
    // 1. Прекращаем принимать новые подключения
    s.mu.Lock()
    s.acceptingNew = false
    s.mu.Unlock()
    
    // 2. Уведомляем все комнаты о скором закрытии
    for _, room := range s.Rooms {
        room.NotifyPeers("server_shutting_down", 30*time.Second)
    }
    
    // 3. Ждём завершения активных сессий или таймаута
    select {
    case <-s.allRoomsEmpty:
        log.Println("All rooms closed gracefully")
    case <-ctx.Done():
        log.Println("Forced shutdown after timeout")
    }
    
    // 4. Закрываем все PeerConnections
    for _, room := range s.Rooms {
        for _, peer := range room.Peers {
            peer.PC.Close()
        }
    }
    
    return nil
}

Для достижения 99.99% необходимы:

• Multi-region деплой — минимум 3 региона с active-active топологией
• Auto-scaling SFU-кластеров на основе метрик (CPU, bandwidth, количество пиров)
• Health checks и автоматический drain нездоровых нод
• Circuit breakers между сервисами
• Graceful degradation при перегрузке: снижение качества видео вместо отказа

4. Безопасность — детализация

WebRTC уже обеспечивает шифрование:

• DTLS (Datagram TLS) — для шифрования RTP-пакетов медиа
• SRTP (Secure RTP) — протокол передачи медиа с шифрованием
• SCTP over DTLS — для DataChannel (чат)

Дополнительно требуется:

• WSS (WebSocket Secure) — для сигнализации
• TURN через TLS — для relay-трафика за NAT
• Token-based аутентификация — JWT для входа в комнату

// Аутентификация участника при подключении
func (s *SFU) AuthenticatePeer(token string, roomID string) (*PeerClaims, error) {
    claims := &PeerClaims{}
    parsed, err := jwt.ParseWithClaims(token, claims, func(t *jwt.Token) (interface{}, error) {
        return s.jwtPublicKey, nil
    })
    if err != nil || !parsed.Valid {
        return nil, fmt.Errorf("invalid token")
    }
    
    if claims.RoomID != roomID {
        return nil, fmt.Errorf("token not valid for this room")
    }
    
    if time.Now().Unix() > claims.ExpiresAt {
        return nil, fmt.Errorf("token expired")
    }
    
    return claims, nil
}

type PeerClaims struct {
    jwt.RegisteredClaims
    RoomID   string `json:"room_id"`
    PeerID   string `json:"peer_id"`
    DisplayName string `json:"display_name"`
}

5. Удаление данных после звонка

Отсутствие записи упрощает архитектуру и соответствует GDPR:

• Не нужна подсистема хранения медиа
• Не нужна политика хранения и удаления записей
• Метаданные звонка (участники, время начала/окончания) можно хранить ограниченное время для аналитики, но кандидат решил удалять всё

// Очистка данных при завершении звонка
func (r *Room) Close() {
    r.mu.Lock()
    defer r.mu.Unlock()
    
    // Закрываем все PeerConnections
    for _, peer := range r.Peers {
        peer.PC.Close()
        peer.DataChannel.Close()
    }
    
    // Удаляем комнату из памяти
    delete(r.sfu.Rooms, r.ID)
    
    // Логируем метрику (без персональных данных)
    metrics.RoomClosed(r.ID, len(r.Peers), time.Since(r.CreatedAt))
}

Вопрос 8 (дополнительный). Какие требования к задержке (latency) при установке соединения и передаче видео/аудио?

Таймкод: 00:09:07

Ответ собеседника: Правильный. Для установки соединения — 5-10 секунд. Для задержки видео/аудио — до 1 секунды в нормальном режиме, до 2 секунд в пиковой нагрузке.

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

Кандидат разделил метрики задержки на два этапа — это правильный подход.

Установка соединения (Connection Setup): 5–10 секунд

Это время от момента нажатия «Присоединиться» до начала передачи медиа. Слагаемые:

Этап	Время	Описание
DNS резолв	10–100ms	Резолв домена сигнального сервера
TLS handshake	50–200ms	Установка WSS соединения
HTTP → WS upgrade	10–50ms	Upgrade до WebSocket
Аутентификация	100–500ms	Валидация JWT, проверка прав
SDP exchange	200–1000ms	Offer → Answer через сигнальный сервер
ICE gathering	1–5s	Сбор кандидатов (host, srflx, relay)
DTLS handshake	200–500ms	Установка защищённого канала
SRTP начало	50–100ms	Старт передачи медиа

Основной bottleneck — ICE gathering (1–5 секунд). Для ускорения можно использовать:

• Trickle ICE — отправка кандидатов по мере обнаружения, не ждать полного сбора
• TURN pre-allocation — заранее выделять relay-адреса

// Trickle ICE — обработка ICE кандидатов по мере поступления
func (s *SFU) HandleICECandidate(peerID string, roomID string, candidate webrtc.ICECandidateInit) {
    s.mu.RLock()
    room, exists := s.Rooms[roomID]
    s.mu.RUnlock()
    
    if !exists {
        return
    }
    
    room.mu.RLock()
    peer, exists := room.Peers[peerID]
    room.mu.RUnlock()
    
    if !exists {
        return
    }
    
    // Добавляем кандидат сразу, не ждём полного сбора
    if err := peer.PC.AddICECandidate(candidate); err != nil {
        log.Printf("failed to add ICE candidate for %s: %v", peerID, err)
    }
    
    // Рассылаем кандидат остальным участникам комнаты
    room.BroadcastICECandidate(peerID, candidate)
}

Задержка видео/аудио (Media Latency): 1 секунда нормально, 2 секунды в пике

End-to-end задержка медиа:

Компонент	Норма	Пик
Захват + кодирование	50–100ms	100–150ms
Сеть (client → SFU)	20–100ms	200–500ms
SFU обработка	10–30ms	50–100ms
Сеть (SFU → client)	20–100ms	200–500ms
Jitter buffer	50–100ms	200–300ms
Декодирование + рендеринг	30–50ms	50–100ms
Итого	180–480ms	600–1700ms

Целевые 1–2 секунды реалистичны при условии географически распределённых SFU.

// Jitter Buffer конфиг для баланса задержка/качество
type JitterBufferConfig struct {
    MinDelay    time.Duration // 50ms — минимальная буферизация
    MaxDelay    time.Duration // 300ms — максимальная при плохой сети
    TargetDelay time.Duration // 100ms — целевая
}

func NewAdaptiveJitterBuffer() *JitterBuffer {
    return &JitterBuffer{
        config: JitterBufferConfig{
            MinDelay:    50 * time.Millisecond,
            MaxDelay:    300 * time.Millisecond,
            TargetDelay: 100 * time.Millisecond,
        },
    }
}

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

Таймкод: 00:10:08

Ответ собеседника: Правильный. Доступ по ссылке с подтверждением создателя (модель Google Meet). Баланс скорость/качество, релиз за полгода. Без ограничений по бюджету и стеку. Команда до 100 разработчиков.

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

Кандидат определил следующие ограничения и приоритеты:

Модель доступа: по ссылке с подтверждением создателя (Google Meet модель)

Это означает:

• Создатель комнаты получает уникальную ссылку
• Участники переходят по ссылке
• Создатель подтверждает вход новых участников (lobby/waiting room)
• Незнакомые участники ожидают одобрения перед подключением

// Модель доступа к комнате
type Room struct {
    ID            string
    CreatorID     string
    Participants  map[string]*Peer
    WaitingRoom   map[string]*Peer // Ожидающие подтверждения
    AccessPolicy  AccessPolicy
    CreatedAt     time.Time
}

type AccessPolicy int

const (
    AccessPolicyOpen AccessPolicy = iota        // Открытый доступ
    AccessPolicyCreatorApproval                  // Подтверждение создателем
    AccessPolicyTokenOnly                        // Только по токену
)

func (r *Room) JoinWithApproval(peer *Peer) error {
    if peer.ID == r.CreatorID {
        r.Participants[peer.ID] = peer
        return nil
    }
    
    // Проверяем, является ли участник приглашённым
    if r.isInvited(peer.ID) {
        r.Participants[peer.ID] = peer
        return nil
    }
    
    // Иначе — в комнату ожидания
    r.WaitingRoom[peer.ID] = peer
    r.notifyCreator("waiting_room_join", peer)
    return nil
}

func (r *Room) ApprovePeer(creatorID string, peerID string) error {
    if creatorID != r.CreatorID {
        return fmt.Errorf("only creator can approve")
    }
    
    peer, exists := r.WaitingRoom[peerID]
    if !exists {
        return fmt.Errorf("peer not in waiting room")
    }
    
    delete(r.WaitingRoom, peerID)
    r.Participants[peerID] = peer
    
    // Начинаем SDP exchange для этого участника
    r.initiatePeerConnection(peer)
    return nil
}

Приоритеты разработки:

• Баланс скорости и качества — не жертвуем стабильностью ради быстрого релиза, но и не переусложняем архитектуру
• Релиз за 6 месяцев — агрессивный, но реалистичный для команды в 100 человек

Ограничения:

• Бюджет: без ограничений — можно использовать managed-сервисы (AWS, GCP) и платные решения
• Стек: без ограничений — свобода выбора технологий
• Команда: до 100 разработчиков

Распределение команды на 6 месяцев:

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

Команда	Размер	Ответственность
SFU/Media (Go)	20	Медиасервер, WebRTC, кодеки
Signaling (Go)	15	WebSocket/gRPC, сигнализация, комнаты
Backend/API (Go)	15	REST/GraphQL API, аутентификация, бизнес-логика
Frontend (TypeScript/React)	20	Веб-клиент, UI/UX
Infrastructure/DevOps	10	Kubernetes, CI/CD, мониторинг, масштабирование
QA/Testing	10	Автотесты, нагрузочное тестирование
Mobile (iOS/Android)	5	Мобильные приложения (фаза 2)
Product/Design	5	Продуктовые требования, дизайн

Архитектура на 6 месяцев с командой 100 человек:

// Высокоуровневая структура сервисов

// 1. API Gateway
type Gateway struct {
    authService     *AuthService
    roomService     *RoomService
    signalingClient *SignalingClient
}

// 2. Room Service — управление комнатами
type RoomService struct {
    db     *sql.DB        // PostgreSQL
    cache  *redis.Client  // Redis для быстрого доступа к активным комнатам
    rooms  map[string]*Room // In-memory для активных сессий
}

// 3. Signaling Service — WebRTC сигнализация
type SignalingService struct {
    upgrader    websocket.Upgrader
    sfuClient   *SFUClient
    rooms       map[string]*SignalingRoom
}

// 4. SFU Service — маршрутизация медиа
type SFUService struct {
    rooms       map[string]*Room
    config      SFUConfig
    metrics     *prometheus.Registry
}

// 5. Auth Service — аутентификация
type AuthService struct {
    jwtManager  *JWTManager
    userStore   UserStore
    oauthConfig OAuthConfig
}

Ключевые технические решения для 6-месячного релиза:

1. Использовать pion/webrtc — зрелая Go-библиотека WebRTC, не нужно писать с нуля
2. Kubernetes для оркестрации — автоматическое масштабирование SFU-подов на основе CPU/bandwidth метрик
3. Redis Cluster для хранения состояния комнат и координации между сигнальными серверами
4. PostgreSQL для персистентных данных (пользователи, история звонков)
5. gRPC для межсервисного взаимодействия
6. Prometheus + Grafana для мониторинга
7. Feature flags для постепенного выкатывания функциональности

// Автоматическое масштабирование SFU на основе нагрузки
type SFUScaler struct {
    k8sClient   kubernetes.Interface
    metrics     *prometheus.Registry
    minReplicas int32
    maxReplicas int32
}

func (s *SFUScaler) Evaluate() {
    // Метрики для скейлинг-решений
    activeRooms := s.getActiveRooms()
    cpuUsage := s.getAverageCPUPeercent()
    bandwidthUsage := s.getAverageBandwidthPercent()
    
    if cpuUsage > 70 || bandwidthUsage > 80 {
        s.scaleUp()
    } else if cpuUsage < 30 && bandwidthUsage < 40 && activeRooms < int(s.minReplicas)*10 {
        s.scaleDown()
    }
}

Вопрос 10. Какие требования к безопасности (шифрование, минимальная версия TLS) и доступности (availability)?

Таймкод: 00:11:18

Ответ собеседника: Правильный. Кандидат упомянул необходимость шифрования звонков и минимальных требований к TLS. Доступность — высокая, с простом не более ~52 минут в год (четыре девятки).

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

Кандидат подтвердил требования к безопасности и доступности, сформулированные ранее.

Безопасность — детализация:

1. Шифрование медиа (встроено в WebRTC)

WebRTC обеспечивает шифрование по умолчанию:

• DTLS 1.2+ — Datagram TLS для установки ключей шифрования
• SRTP — Secure Real-time Transport Protocol для шифрования аудио/видео потоков
• SCTP over DTLS — для DataChannel (чат)

Это означает, что даже без дополнительных усилий медиатрафик между клиентом и SFU зашифрован. SFU не может расшифровать содержимое пакетов — он только маршрутизирует RTP-пакеты.

2. TLS для сигнализации

Минимальная версия: TLS 1.2, рекомендуется TLS 1.3:

// Настройка TLS для сигнального сервера
func createTLSConfig(certFile, keyFile string) *tls.Config {
    cert, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        log.Fatal(err)
    }
    
    return &tls.Config{
        Certificates: []tls.Certificate{cert},
        MinVersion:   tls.VersionTLS12,
        MaxVersion:   tls.VersionTLS13,
        CipherSuites: []uint16{
            tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
            tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
            tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
            tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
            tls.TLS_AES_256_GCM_SHA384,       // TLS 1.3
            tls.TLS_CHACHA20_POLY1305_SHA256,  // TLS 1.3
        },
        PreferServerCipherSuites: true,
    }
}

// HTTP сервер с TLS
server := &http.Server{
    Addr:      ":443",
    TLSConfig: createTLSConfig("cert.pem", "key.pem"),
    Handler:   mux,
}

log.Fatal(server.ListenAndServeTLS("", ""))

3. Дополнительные меры безопасности

• TURN over TLS — relay-трафик также должен быть зашифрован
• Certificate pinning — для мобильных приложений
• Rate limiting — защита от brute-force на аутентификацию
• CORS политики — ограничение доменов для веб-клиента
• Content Security Policy — защита от XSS

// Rate limiter для WebSocket подключений
type RateLimiter struct {
    limiter *rate.Limiter
}

func NewRateLimiter(rps int) *RateLimiter {
    return &RateLimiter{
        limiter: rate.NewLimiter(rate.Limit(rps), rps*2),
    }
}

func (rl *RateLimiter) Allow(peerID string) bool {
    return rl.limiter.Allow()
}

// Middleware для проверки rate limit
func RateLimitMiddleware(rl *RateLimiter) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            peerID := r.Header.Get("X-Peer-ID")
            if !rl.Allow(peerID) {
                http.Error(w, "rate limit exceeded", http.StatusTooManyRequests)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

Доступность 99.99% — архитектурные паттерны:

Для обеспечения не более 52 минут простоя в год необходимы:

1. Multi-region деплой

# Kubernetes deployment с multi-region
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sfu-service
spec:
  replicas: 3
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: sfu-service
      containers:
        - name: sfu
          image: sfu:latest
          resources:
            requests:
              cpu: "4"
              memory: "8Gi"
            limits:
              cpu: "8"
              memory: "16Gi"

2. Health checks

// Liveness probe — жив ли процесс
func (s *SFU) HealthCheck() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // Проверяем критические зависимости
        if !s.redisClient.Ping().Err() == nil {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    }
}

// Readiness probe — готов ли принимать трафик
func (s *SFU) ReadinessCheck() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // Не принимаем новые подключения при высокой нагрузке
        if s.getCPUUsage() > 90 || s.getBandwidthUsage() > 95 {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    }
}

3. Graceful degradation

// При перегрузке снижаем качество вместо отказа
func (s *SFU) HandleOverload() {
    for _, room := range s.Rooms {
        for _, peer := range room.Peers {
            // Снижаем битрейт
            peer.SetTargetBitrate(500) // kbps вместо 1500
            
            // Отключаем видео у части участников
            if len(room.Peers) > 10 {
                peer.DisableVideo()
            }
        }
    }
}

4. Расчёт доступности по компонентам:

Компонент	Доступность	Вклада в downtime
Load Balancer	99.99%	~52 мин
API Gateway	99.99%	~52 мин
Signaling Service	99.99%	~52 мин
SFU Cluster	99.995%	~26 мин
Redis Cluster	99.99%	~52 мин
PostgreSQL	99.99%	~52 мин
Общая	~99.99%	~52 мин

Для достижения 99.99% на уровне всей системы каждый критический компонент должен иметь 99.99% или выше, а также отсутствовать single point of failure.

Вопрос 11. Какие требования к доступности (availability) сервиса?

Таймкод: 00:11:37

Ответ собеседника: Правильный. Кандидат отметил, что сервис должен быть высокодоступным, учитывая амбициозную цель — миллиард пользователей по всей планете.

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

Кандидат подтвердил, что сервис должен быть высокодоступным. Ранее была определена конкретная метрика — 99.99% (четыре девятки), что соответствует не более ~52 минут простоя в год.

Почему для миллиарда пользователей 99.99% — минимум:

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

• При равномерном распределении: ~16 700 пользователей в минуту теряют доступ
• В пиковые часы: до 100 000+ пользователей одновременно затронуты
• Репутационные потери: каждый минутный простой — это потенциальные негативные отзывы и отток пользователей

Паттерны обеспечения высокой доступности в Go-сервисах:

1. Redundancy на каждом уровне

// Circuit Breaker для зависимых сервисов
type CircuitBreaker struct {
    failures    int
    threshold   int
    lastFailure time.Time
    timeout     time.Duration
    mu          sync.Mutex
    state       State
}

type State int

const (
    StateClosed State = iota    // Нормальная работа
    StateOpen                   // Отказ, запросы не проходят
    StateHalfOpen               // Тестовый запрос
)

func (cb *CircuitBreaker) Call(fn func() error) error {
    cb.mu.Lock()
    defer cb.mu.Unlock()
    
    switch cb.state {
    case StateOpen:
        if time.Since(cb.lastFailure) > cb.timeout {
            cb.state = StateHalfOpen
        } else {
            return fmt.Errorf("circuit breaker is open")
        }
    }
    
    err := fn()
    
    if err != nil {
        cb.failures++
        cb.lastFailure = time.Now()
        if cb.failures >= cb.threshold {
            cb.state = StateOpen
        }
        return err
    }
    
    cb.failures = 0
    cb.state = StateClosed
    return nil
}

// Использование для вызова Redis
func (s *SFU) GetRoomFromCache(roomID string) (*Room, error) {
    var room *Room
    err := s.circuitBreaker.Call(func() error {
        data, err := s.redisClient.Get("room:" + roomID).Bytes()
        if err != nil {
            return err
        }
        room, err = decodeRoom(data)
        return err
    })
    
    if err != nil {
        // Fallback на PostgreSQL
        return s.getRoomFromDB(roomID)
    }
    return room, nil
}

2. Health checks и автоматическое восстановление

// Kubernetes probes для SFU сервиса
func (s *SFU) RegisterHandlers(mux *http.ServeMux) {
    mux.HandleFunc("/healthz", s.livenessProbe)
    mux.HandleFunc("/readyz", s.readinessProbe)
    mux.HandleFunc("/metrics", s.metricsHandler)
}

func (s *SFU) livenessProbe(w http.ResponseWriter, r *http.Request) {
    // Проверяем, что процесс не завис
    if s.isShuttingDown() {
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
}

func (s *SFU) readinessProbe(w http.ResponseWriter, r *http.Request) {
    // Проверяем готовность принимать трафик
    checks := map[string]bool{
        "redis":    s.redisClient.Ping() == nil,
        "sfu_pool": s.hasAvailableSFUNodes(),
    }
    
    for name, ok := range checks {
        if !ok {
            log.Printf("readiness check failed: %s", name)
            w.WriteHeader(http.StatusServiceUnavailable)
            json.NewEncoder(w).Encode(map[string]interface{}{
                "status": "not ready",
                "failed": name,
            })
            return
        }
    }
    
    w.WriteHeader(http.StatusOK)
}

3. Graceful shutdown

func (s *SFU) Run() error {
    // Слушаем сигналы ОС
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()
    
    // Запускаем сервер
    go func() {
        if err := s.httpServer.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("server error: %v", err)
        }
    }()
    
    <-ctx.Done()
    
    // Graceful shutdown с таймаутом
    shutdownCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    
    // Уведомляем все комнаты
    s.notifyAllRooms("server_shutdown", 30*time.Second)
    
    // Ждём завершения активных соединений
    s.wg.Wait()
    
    return s.httpServer.Shutdown(shutdownCtx)
}

4. SLA и SLI для мониторинга доступности

// Service Level Indicators
type SLIRecorder struct {
    totalRequests   prometheus.Counter
    failedRequests  prometheus.Counter
    requestDuration prometheus.Histogram
}

func NewSLIRecorder() *SLIRecorder {
    return &SLIRecorder{
        totalRequests: prometheus.NewCounter(prometheus.CounterOpts{
            Name: "sfu_requests_total",
            Help: "Total number of requests",
        }),
        failedRequests: prometheus.NewCounter(prometheus.CounterOpts{
            Name: "sfu_requests_failed_total",
            Help: "Total number of failed requests",
        }),
        requestDuration: prometheus.NewHistogram(prometheus.HistogramOpts{
            Name:    "sfu_request_duration_seconds",
            Help: "Request duration in seconds",
            Buckets: prometheus.DefBuckets,
        }),
    }
}

func (sli *SLIRecorder) Availability() float64 {
    total := sli.totalRequests
    failed := sli.failedRequests
    return 1.0 - (failed / total)
}

Вопрос 12. Нужно ли хранить данные после окончания звонка (история чата, записи)?

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

Ответ собеседника: Правильный. Кандидат решил, что после окончания звонка все данные (чат, шаринг) можно удалять — это упрощает задачу.

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

Кандидат принял решение удалять все данные после окончания звонка. Это осознанное упрощение, которое имеет значительные архитектурные последствия.

Что именно не хранится:

• Видео/аудио записи звонков
• История текстового чата
• Записи шаринга экрана
• Метаданные звонка (время начала, участники, длительность)

Архитектурные упрощения от этого решения:

1. Нет подсистемы записи

Не нужен:

• Медиа-рекордер (отдельный сервис, подписанный на RTP-потоки)
• Транскодирование записей для воспроизведения
• Хранилище медиафайлов (S3-совместимое)
• Политики хранения и автоматического удаления

2. Нет подсистемы хранения чата

Не нужна:

• Персистентная очередь сообщений
• Индексация для поиска по истории чатов
• Синхронизация истории между устройствами пользователя

3. Упрощение compliance (GDPR, CCPA)

При отсутствии хранимых данных значительно упрощается:

• Реализация права на удаление данных (right to be forgotten)
• Аудит хранения персональных данных
• Согласия на обработку данных

// Очистка данных при закрытии комнаты
func (r *Room) Close() {
    r.mu.Lock()
    defer r.mu.Unlock()
    
    // Уведомляем всех участников
    for _, peer := range r.Peers {
        peer.SendSignalingMessage(SignalingMessage{
            Type:   "room_closed",
            RoomID: r.ID,
        })
        peer.PC.Close()
    }
    
    // Очищаем все данные
    r.Peers = nil
    r.WaitingRoom = nil
    r.ChatHistory = nil
    
    // Удаляем из кэша
    r.sfu.cache.Delete("room:" + r.ID)
    
    // Удаляем из памяти
    delete(r.sfu.Rooms, r.ID)
    
    // Метрика без персональных данных
    metrics.RoomClosed(r.ID, time.Since(r.CreatedAt))
}

Что можно хранить для аналитики (без персональных данных):

// Анонимная метрика звонка
type CallMetrics struct {
    RoomID        string        `json:"-"` // Не сохраняем
    Duration      time.Duration `json:"duration"`
    PeerCount     int           `json:"peer_count"`
    Region        string        `json:"region"`
    AudioCodec    string        `json:"audio_codec"`
    VideoCodec    string        `json:"video_codec"`
    AvgLatencyMs  float64       `json:"avg_latency_ms"`
    PacketLossPct float64       `json:"packet_loss_pct"`
    Timestamp     time.Time     `json:"timestamp"`
}

func (s *SFU) RecordMetrics(room *Room) {
    metrics := CallMetrics{
        Duration:      time.Since(room.CreatedAt),
        PeerCount:     len(room.Peers),
        Region:        s.region,
        AudioCodec:    "opus",
        VideoCodec:    "VP8",
        AvgLatencyMs:  s.GetAverageLatency(room.ID),
        PacketLossPct: s.GetPacketLoss(room.ID),
        Timestamp:     time.Now(),
    }
    
    // Отправляем в ClickHouse / Prometheus
    s.metricsCollector.Collect(metrics)
}

Когда потребуется хранение данных:

Если в будущем появится запрос на хранение:

• История чата — потребуется PostgreSQL или MongoDB для хранения сообщений, индексация по комнате и времени
• Записи звонков — потребуется медиа-рекордер, S3-хранилище, транскодирование, отдельный сервис для воспроизведения
• Метаданные звонков — потребуется хранение для отчётов и аналитики

Для MVP решение кандидата полностью оправдано — это позволяет сосредоточиться на качестве основного функционала.

Вопрос 13. Какие приоритеты при разработке (скорость выхода на рынок vs качество)? Есть ли ограничения по бюджету, инфраструктуре, стеку технологий, размеру команды?

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

Ответ собеседника: Правильный. Кандидат предложил средний баланс между скоростью и качеством, релиз за полгода. Бюджет не ограничен (модель Google), можно использовать любые решения. Команда — не более 100 разработчиков.

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

Кандидат определил сбалансированные условия для проекта.

Приоритеты: баланс скорости и качества с релизом за 6 месяцев

Это означает:

• Не жертвуем архитектурой ради быстрого прототипа
• Но и не over-engineering — не строим систему для 10x масштаба сразу
• Feature flags для постепенного выкатывания
• Тестовое покрытие критических путей

Без ограничений по бюджету (модель Google):

Это позволяет:

• Использовать managed-сервисы: AWS EC2/GCP Compute Engine для SFU, AWS ElastiCache для Redis, AWS RDS для PostgreSQL
• Платные CDN и Anycast: Cloudflare, AWS CloudFront
• Глобальная инфраструктура: деплой в нескольких регионах с первого дня
• Коммерческие лицензии при необходимости

Без ограничений по стеку:

Рекомендуемый стек для этого проекта:

Слой	Технология	Обоснование
Backend/SFU	Go	Производительность, конкурентность, pion/webrtc
Frontend	TypeScript + React	Экосистема, WebRTC API
Сигнализация	WebSocket (gorilla/websocket) или gRPC	Реальное время
Медиа	pion/webrtc	Зрелая Go-библиотека WebRTC
БД	PostgreSQL	Надёжность, JSON поддержка
Кэш	Redis Cluster	Скорость, pub/sub
Очереди	NATS или Kafka	Асинхронная коммуникация
Инфраструктура	Kubernetes (EKS/GKE)	Оркестрация, автоскейлинг
Мониторинг	Prometheus + Grafana	Метрики, алертинг
Логирование	ELK Stack или Loki	Централизованные логи
CI/CD	GitHub Actions или GitLab CI	Автоматизация

Команда до 100 человек — организация:

При 100 разработчиках и 6 месяцах до релиза эффективная структура:

Команда SFU/Media (20 человек):

• Разработка SFU на Go с pion/webrtc
• Оптимизация маршрутизации медиа
• Поддержка кодеков (VP8, H.264, Opus)
• Bandwidth estimation, simulcast

Команда Signaling & Backend (20 человек):

• WebSocket/gRPC сигнализация
• Управление комнатами и участниками
• Аутентификация и авторизация
• REST/GraphQL API

Команда Frontend (20 человек):

• Веб-клиент на React
• WebRTC интеграция
• UI/UX для видеоконференций
• Чат, шаринг экрана, реакции

Команда Infrastructure (15 человек):

• Kubernetes кластеры
• CI/CD пайплайны
• Мониторинг и алертинг
• Автоматическое масштабирование

Команда QA (15 человек):

• Интеграционные тесты
• Нагрузочное тестирование
• E2E тесты
• Тестирование совместимости браузеров

Команда мобильной разработки (5 человек):

• iOS/Android приложения (фаза 2)
• Нативный WebRTC SDK

Команда Product & Design (5 человек):

• Продуктовые требования
• Дизайн-система
• Исследование пользователей

// Пример архитектуры сервиса с учётом командной структуры

// SFU Service — ответственность команды SFU/Media
type SFUService struct {
    config    SFUConfig
    rooms     sync.Map // map[string]*Room
    metrics   *MetricsCollector
}

// Signaling Service — ответственность команды Signaling
type SignalingService struct {
    upgrader  websocket.Upgrader
    sfuPool   *SFUPool // Пул SFU-нод
    auth      *AuthClient
}

// Room Service — ответственность команды Backend
type RoomService struct {
    db        *sql.DB
    cache     *redis.Client
    events    *EventBus
}

// API Gateway — ответственность команды Infrastructure
type Gateway struct {
    mux       *http.ServeMux
    services  *ServiceRegistry
    middleware []Middleware
}

Риск при 100 людях:

Закон Брукса: «Добавление людей к запаздывающему проекту делает его ещё более запаздывающим.» При 100 разработчиках критически важны:

• Чёткие границы между сервисами (API contracts)
• Асинхронная коммуникация через брокеры сообщений
• Единый CI/CD пайплайн
• Документация архитектурных решений (ADR — Architecture Decision Records)

Вопрос 14. Начните проектировать архитектуру — какие компоненты нужны для базового сценария звонка между двумя пользователями через веб-клиент?

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

Ответ собеседника: Правильный. Кандидат начал с двух веб-клиентов, добавил API-эндпоинт в облаке Google для создания сессий и ссылок, in-memory хранилище сессий (Redis-подобное) и базу данных пользователей.

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

Кандидат определил базовые компоненты архитектуры. Развернём полную архитектуру для минимального сценария.

Базовые компоненты для звонка между двумя пользователями:

1. Веб-клиент (2 экземпляра)

Браузерное приложение на TypeScript/React, использующее WebRTC API:

• getUserMedia() — захват камеры и микрофона
• RTCPeerConnection — WebRTC соединение
• RTCDataChannel — чат
• getDisplayMedia() — шаринг экрана

2. API Gateway / Backend (Go)

// Структура основного сервера
type Server struct {
    router     *http.ServeMux
    roomSvc    *RoomService
    authSvc    *AuthService
    signalSvc  *SignalingService
    sfuPool    *SFUPool
}

func NewServer() *Server {
    return &Server{
        router:    http.NewServeMux(),
        roomSvc:   NewRoomService(),
        authSvc:   NewAuthService(),
        signalSvc: NewSignalingService(),
    }
}

func (s *Server) RegisterRoutes() {
    // REST API
    s.router.HandleFunc("POST /api/rooms", s.handleCreateRoom)
    s.router.HandleFunc("GET /api/rooms/{id}", s.handleGetRoom)
    s.router.HandleFunc("POST /api/rooms/{id}/join", s.handleJoinRoom)
    
    // WebSocket для сигнализации
    s.router.HandleFunc("/ws/{roomID}", s.handleWebSocket)
    
    // Статика веб-клиента
    s.router.Handle("/", http.FileServer(http.Dir("./web")))
}

3. Room Service — управление комнатами

type RoomService struct {
    db    *sql.DB        // PostgreSQL для персистентности
    cache *redis.Client  // Redis для быстрого доступа
}

type Room struct {
    ID          string    `json:"id"`
    CreatorID   string    `json:"creator_id"`
    CreatedAt   time.Time `json:"created_at"`
    Status      string    `json:"status"` // "active", "closed"
    MaxPeers    int       `json:"max_peers"`
}

func (rs *RoomService) CreateRoom(ctx context.Context, creatorID string) (*Room, error) {
    room := &Room{
        ID:        generateRoomID(),
        CreatorID: creatorID,
        CreatedAt: time.Now(),
        Status:    "active",
        MaxPeers:  20,
    }
    
    // Сохраняем в PostgreSQL
    _, err := rs.db.ExecContext(ctx,
        "INSERT INTO rooms (id, creator_id, created_at, status, max_peers) VALUES ($1, $2, $3, $4, $5)",
        room.ID, room.CreatorID, room.CreatedAt, room.Status, room.MaxPeers,
    )
    if err != nil {
        return nil, fmt.Errorf("failed to create room: %w", err)
    }
    
    // Кэшируем в Redis
    rs.cache.Set(ctx, "room:"+room.ID, room, 24*time.Hour)
    
    return room, nil
}

func (rs *RoomService) GetRoom(ctx context.Context, roomID string) (*Room, error) {
    // Сначала проверяем кэш
    var room Room
    err := rs.cache.Get(ctx, "room:"+roomID).Scan(&room)
    if err == nil {
        return &room, nil
    }
    
    // Если нет в кэше — из базы
    err = rs.db.QueryRowContext(ctx,
        "SELECT id, creator_id, created_at, status, max_peers FROM rooms WHERE id = $1",
        roomID,
    ).Scan(&room.ID, &room.CreatorID, &room.CreatedAt, &room.Status, &room.MaxPeers)
    
    return &room, err
}

4. Signaling Service — WebRTC сигнализация

type SignalingService struct {
    upgrader websocket.Upgrader
    rooms    map[string]*SignalingRoom
    mu       sync.RWMutex
}

type SignalingRoom struct {
    RoomID    string
    Peers     map[string]*SignalingPeer
    mu        sync.RWMutex
}

type SignalingPeer struct {
    ID       string
    Conn     *websocket.Conn
    PC       *webrtc.PeerConnection
    RoomID   string
}

func (ss *SignalingService) HandleWebSocket(w http.ResponseWriter, r *http.Request) {
    roomID := r.PathValue("roomID")
    peerID := r.URL.Query().Get("peer_id")
    
    conn, err := ss.upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Printf("WebSocket upgrade failed: %v", err)
        return
    }
    
    peer := &SignalingPeer{
        ID:     peerID,
        Conn:   conn,
        RoomID: roomID,
    }
    
    ss.AddPeer(roomID, peer)
    
    defer func() {
        ss.RemovePeer(roomID, peerID)
        conn.Close()
    }()
    
    // Читаем сообщения от клиента
    for {
        var msg SignalingMessage
        if err := conn.ReadJSON(&msg); err != nil {
            log.Printf("read error: %v", err)
            break
        }
        ss.HandleMessage(roomID, peerID, msg)
    }
}

func (ss *SignalingService) HandleMessage(roomID, peerID string, msg SignalingMessage) {
    switch msg.Type {
    case "offer":
        // Обработка SDP offer
        ss.HandleOffer(roomID, peerID, msg)
    case "answer":
        // Обработка SDP answer
        ss.HandleAnswer(roomID, peerID, msg)
    case "ice_candidate":
        // Обработка ICE candidate
        ss.HandleICECandidate(roomID, peerID, msg)
    }
}

5. In-memory хранилище (Redis)

Используется для:

• Хранения активных комнат (room state)
• Pub/Sub для сигнализации между серверами
• Счётчики участников
• Rate limiting

// Redis схема данных
// room:{id} — хеш с данными комнаты
// room:{id}:peers — множество участников
// peer:{id}:server — на каком сервере находится пир
// rate:{ip} — счётчик запросов для rate limiting

type RedisCache struct {
    client *redis.Client
}

func (c *RedisCache) AddPeerToRoom(ctx context.Context, roomID, peerID string) error {
    pipe := c.client.Pipeline()
    pipe.SAdd(ctx, "room:"+roomID+":peers", peerID)
    pipe.Set(ctx, "peer:"+peerID+":server", os.Getenv("SERVER_ID"), 0)
    pipe.Incr(ctx, "room:"+roomID+":peer_count")
    _, err := pipe.Exec(ctx)
    return err
}

func (c *RedisCache) GetPeerCount(ctx context.Context, roomID string) (int64, error) {
    return c.client.Get(ctx, "room:"+roomID+":peer_count").Int64()
}

6. PostgreSQL — персистентное хранилище

-- Таблица комнат
CREATE TABLE rooms (
    id          VARCHAR(36) PRIMARY KEY,
    creator_id  VARCHAR(36) NOT NULL,
    created_at  TIMESTAMP NOT NULL DEFAULT NOW(),
    closed_at   TIMESTAMP,
    status      VARCHAR(20) NOT NULL DEFAULT 'active',
    max_peers   INTEGER NOT NULL DEFAULT 20
);

-- Таблица участников звонков (для аналитики)
CREATE TABLE call_participants (
    id          BIGSERIAL PRIMARY KEY,
    room_id     VARCHAR(36) REFERENCES rooms(id),
    peer_id     VARCHAR(36) NOT NULL,
    joined_at   TIMESTAMP NOT NULL DEFAULT NOW(),
    left_at     TIMESTAMP,
    duration_ms BIGINT
);

-- Таблица пользователей
CREATE TABLE users (
    id            VARCHAR(36) PRIMARY KEY,
    email         VARCHAR(255) UNIQUE NOT NULL,
    display_name  VARCHAR(255) NOT NULL,
    created_at    TIMESTAMP NOT NULL DEFAULT NOW(),
    last_login    TIMESTAMP
);

-- Индексы
CREATE INDEX idx_rooms_creator ON rooms(creator_id);
CREATE INDEX idx_rooms_status ON rooms(status);
CREATE INDEX idx_call_participants_room ON call_participants(room_id);

Схема взаимодействия для базового сценария:

Пользователь A (Создатель)          Пользователь B (Участник)
        |                                      |
        |  1. POST /api/rooms                  |
        | ──────────────────────────────────>  |
        |  2. { room_id: "abc", link: "..." }  |
        | <──────────────────────────────────  |
        |                                      |
        |  Отправляет ссылку B                 |
        | ──────────────────────────────────>  |
        |                                      |
        |  3. GET /api/rooms/abc               |
        |                                      | ────────────────────────>
        |                                      |  4. { room: {...} }
        |                                      | <────────────────────────
        |                                      |
        |  5. WS /ws/abc?peer_id=A             |
        | ──────────────────────────────────>  |
        |                                      |  6. WS /ws/abc?peer_id=B
        |                                      | ────────────────────────>
        |                                      |
        |  7. Signaling: SDP offer             |
        | <──────────────────────────────────>  |
        |  8. Signaling: SDP answer            |
        | <──────────────────────────────────>  |
        |  9. Signaling: ICE candidates        |
        | <──────────────────────────────────>  |
        |                                      |
        |  10. WebRTC P2P / SFU медиа          |
        | <══════════════════════════════════>  |
        |                                      |
        |  11. DataChannel: chat               |
        | <══════════════════════════════════>  |

Для двух участников возможен P2P режим без SFU, что упрощает архитектуру. Однако кандидат сразу заложил SFU, что правильно для масштабирования до 20 участников.

Вопрос 15. Какой протокол использовать для передачи медиа и как решить проблему NAT при прямой передаче между клиентами?

Таймкод: 00:19:40

Ответ собеседника: Правильный. Кандидат предложил SIP для сигнализации и RTP для передачи медиа, либо WebRTC как альтернативу. Для обхода NAT нужен медиатор (TURN/STUN). WebRTC поддерживается браузерами и позволяет P2P-передачу после установки соединения.

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

Кандидат правильно описал оба подхода. Уточним детали.

Вариант 1: SIP + RTP (классический)

SIP (Session Initiation Protocol) — сигнальный протокол для установки, модификации и завершения мультимедийных сессий.

• SIP — сигнализация (установление вызова, согласование параметров)
• RTP (Real-time Transport Protocol) — передача аудио/видео
• SDP (Session Description Protocol) — описание медиапотоков (кодеки, порты, форматы)

SIP — текстовый протокол, похожий на HTTP:

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 pc33.example.com
s=
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Вариант 2: WebRTC (рекомендуемый для веб-клиента)

WebRTC — комплексное решение, включающее:

• ICE (Interactive Connectivity Establishment) — для обхода NAT
• STUN (Session Traversal Utilities for NAT) — для определения публичного адреса
• TURN (Traversal Using Relays around NAT) — для relay-трафика при невозможности P2P
• DTLS — для шифрования
• SRTP — защищённый RTP для медиа

Почему WebRTC предпочтительнее для веб-клиента:

1. Встроен в браузеры — не нужны плагины
2. Шифрование обязательно (DTLS-SRTP)
3. Автоматический NAT traversal через ICE
4. Встроенный jitter buffer, bandwidth estimation, echo cancellation
5. DataChannel для чата из коробки

Решение проблемы NAT — ICE framework:

// Настройка ICE для WebRTC пира
func createPeerConnection(stunServers []string, turnServers []TURNConfig) (*webrtc.PeerConnection, error) {
    config := webrtc.Configuration{
        ICEServers: []webrtc.ICEServer{
            // STUN серверы — для определения публичного адреса
            {
                URLs: []string{
                    "stun:stun.l.google.com:19302",
                    "stun:stun1.l.google.com:19302",
                },
            },
            // TURN серверы — для relay при невозможности P2P
            {
                URLs:       []string{"turn:turn.example.com:3478"},
                Username:   "user",
                Credential: "password",
            },
            // TURN over TLS — для обхода строгих файрволов
            {
                URLs:       []string{"turns:turn.example.com:5349"},
                Username:   "user",
                Credential: "password",
            },
        },
        ICETransportPolicy: webrtc.ICETransportPolicyAll,
        BundlePolicy:       webrtc.BundlePolicyMaxBundle,
        RTCPMuxPolicy:      webrtc.RTCPMuxPolicyRequire,
    }
    
    return webrtc.NewPeerConnection(config)
}

Типы ICE кандидатов:

Тип	Описание	Приоритет
host	Локальный адрес (192.168.x.x)	Высокий
srflx	Публичный адрес (через STUN)	Средний
relay	Relay через TURN сервер	Низкий

Процесс ICE negotiation:

func (p *SignalingPeer) SetupICECandidates() {
    // Слушаем генерацию ICE кандидатов
    p.PC.OnICECandidate(func(candidate *webrtc.ICECandidate) {
        if candidate == nil {
            // ICE gathering завершён
            return
        }
        
        // Отправляем кандидат через сигнальный сервер
        p.SendSignalingMessage(SignalingMessage{
            Type:      "ice_candidate",
            RoomID:    p.RoomID,
            PeerID:    p.ID,
            Payload:   candidate.ToJSON(),
        })
    })
    
    // Слушаем изменение состояния соединения
    p.PC.OnICEConnectionStateChange(func(state webrtc.ICEConnectionState) {
        log.Printf("ICE state for peer %s: %s", p.ID, state.String())
        
        switch state {
        case webrtc.ICEConnectionStateConnected:
            metrics.IncCounter("ice_connected")
        case webrtc.ICEConnectionStateFailed:
            metrics.IncCounter("ice_failed")
            // Можно попробовать restart ICE
            p.RestartICE()
        case webrtc.ICEConnectionStateDisconnected:
            // Временная потеря связи, ждём восстановления
        }
    })
}

TURN сервер на Go (с использованием pion/turn):

func StartTURNServer() {
    listener, err := net.ListenPacket("udp4", "0.0.0.0:3478")
    if err != nil {
        log.Fatalf("Failed to create TURN listener: %v", err)
    }
    
    server, err := turn.NewServer(turn.ServerConfig{
        Realm: "example.com",
        PacketConnConfigs: []turn.PacketConnConfig{
            {
                PacketConn: listener,
                RelayAddressGenerator: &turn.RelayAddressGeneratorPortRange{
                    RelayAddress: net.ParseIP("0.0.0.0"),
                    Address:      "0.0.0.0",
                    MinPort:      50000,
                    MaxPort:      60000,
                },
            },
        },
        AuthHandler: func(username string, realm string, srcAddr net.Addr) ([]byte, bool) {
            // Проверяем credentials
            return turn.GenerateAuthKey(username, realm, "secret"), true
        },
    })
    
    if err != nil {
        log.Fatalf("Failed to create TURN server: %v", err)
    }
    
    defer server.Close()
}

Сравнение подходов:

Критерий	SIP + RTP	WebRTC
Поддержка браузерами	Нужен плагин/библиотеку	Встроено
Шифрование	Опционально (SRTP)	Обязательно (DTLS-SRTP)
NAT traversal	Требует отдельный TURN	Встроен (ICE)
Чат	Отдельный протокол (XMPP)	DataChannel
Сложность реализации	Высокая	Средняя
Рекомендация для веб	Не рекомендуется	Рекомендуется

Для данного проекта с веб-клиентом WebRTC — единственный разумный выбор.

Вопрос 16. Как масштабировать передачу видео на 20 участников — централизованная (через сервер) или децентрализованная (P2P) топология?

Таймкод: 00:23:06

Ответ собеседника: Правильный. Кандидат обозначил проблему полносвязной топологии (19 потоков на клиента). Обсудили два варианта: 1) Централизованный — Media Conversion Backend комбинирует потоки (проще в реализации, но нагрузка на сервер). 2) Децентрализованный P2P с оптимизациями (не передавать видео невидимым участникам, снижать качество). Кандидат склонился к централизованному варианту как более простому для разработки, но отметил, что оба варианта — равнозначные опции с разными компромиссами.

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

Кандидат корректно провёл анализ обеих топологий. Развернём детали.

Проблема полносвязной (Mesh) P2P топологии:

При 20 участниках каждый клиент:

• Отправляет 19 потоков (по каждому другому участнику)
• Получает 19 потоков
• Итого: 380 одновременных соединений

При битрейте 1.5 Mbps на поток:

• Uplink: 19 × 1.5 = 28.5 Mbps на клиента
• Downlink: 19 × 1.5 = 28.5 Mbps на клиента

Это нереалистично для большинства пользователей.

Вариант 1: SFU (Selective Forwarding Unit) — централизованный

SFU принимает поток от каждого участника и пересылает остальным, не декодируя содержимое.

Клиент A ──┐
Клиент B ──┤
Клиент C ──┼── [ SFU сервер ] ──┬── Клиент A (получает B, C, D...)
Клиент D ──┤                    ├── Клиент B (получает A, C, D...)
...         │                    ├── Клиент C (получает A, B, D...)
Клиент T ──┘                    └── Клиент T (получает A, B, C...)

Расчёт нагрузки на SFU при 20 участниках:

// Расчёт нагрузки SFU
type SFULoad struct {
    Participants    int
    BitratePerStreamKbps int
}

func (s *SFULoad) Calculate() UplinkDownlink {
    // Каждый участник отправляет 1 поток, получает (N-1) потоков
    streamsUplink := s.Participants
    streamsDownlink := s.Participants * (s.Participants - 1)
    totalStreams := streamsUplink + streamsDownlink
    
    return UplinkDownlink{
        UplinkMbps:   float64(streamsUplink*s.BitratePerStreamKbps) / 1000,
        DownlinkMbps: float64(streamsDownlink*s.BitratePerStreamKbps) / 1000,
        TotalStreams: totalStreams,
    }
}

// Для 20 участников при 1500 Kbps:
// Uplink: 20 × 1500 / 1000 = 30 Mbps
// Downlink: 20 × 19 × 1500 / 1000 = 570 Mbps
// Итого: 590 Mbps на один SFU-инстанс

Реализация SFU на Go с pion/webrtc:

type SFUNode struct {
    ID       string
    Rooms    map[string]*SFURoom
    mu       sync.RWMutex
    metrics  *SFUMetrics
}

type SFURoom struct {
    RoomID    string
    Peers     map[string]*SFUPeer
    mu        sync.RWMutex
}

type SFUPeer struct {
    ID           string
    PC           *webrtc.PeerConnection
    Publishers   map[string]*webrtc.TrackRemote  // Треки, которые публикует этот пир
    Subscribers  map[string]*webrtc.TrackLocalStaticRTP // Треки, на которые подписан
}

func (s *SFUNode) AddPublisher(roomID string, peerID string, track *webrtc.TrackRemote) {
    s.mu.RLock()
    room, exists := s.Rooms[roomID]
    s.mu.RUnlock()
    
    if !exists {
        return
    }
    
    room.mu.Lock()
    defer room.mu.Unlock()
    
    // Создаём local track для пересылки
    localTrack, err := webrtc.NewTrackLocalStaticRTP(
        track.Codec().RTPCodecCapability,
        track.ID(),
        track.StreamID(),
    )
    if err != nil {
        log.Printf("failed to create local track: %v", err)
        return
    }
    
    peer := room.Peers[peerID]
    peer.Publishers[track.ID()] = track
    
    // Рассылаем этот трек всем остальным участникам
    for otherPeerID, otherPeer := range room.Peers {
        if otherPeerID == peerID {
            continue
        }
        
        // Добавляем трек к подписчику
        if _, err := otherPeer.PC.AddTrack(localTrack); err != nil {
            log.Printf("failed to add track to peer %s: %v", otherPeerID, err)
            continue
        }
        
        otherPeer.Subscribers[track.ID()] = localTrack
    }
    
    // Читаем RTP пакеты из remote track и пишем в local track
    go func() {
        rtpBuf := make([]byte, 1400)
        for {
            n, _, err := track.Read(rtpBuf)
            if err != nil {
                return
            }
            
            if _, err := localTrack.Write(rtpBuf[:n]); err != nil {
                return
            }
        }
    }()
}

Вариант 2: Mesh P2P с оптимизациями

Оптимизации для снижения нагрузки:

Selective Forwarding — не передавать видео невидимым участникам:

// На стороне браузера — управление отправкой видео
type VideoSelector struct {
    visiblePeers   map[string]bool // Кто виден на экране
    maxVideoStreams int            // Максимум видеопотоков (например, 4)
}

func (vs *VideoSelector) GetPeersToSendVideo() []string {
    // Отправляем видео только видимым участникам
    // Приоритет: говорящий > последние говорившие > остальные
    result := make([]string, 0, vs.maxVideoStreams)
    
    // 1. Говорящий (по уровню аудио)
    if speaker := vs.getCurrentSpeaker(); speaker != "" {
        result = append(result, speaker)
    }
    
    // 2. Видимые на экране
    for peerID := range vs.visiblePeers {
        if len(result) >= vs.maxVideoStreams {
            break
        }
        result = append(result, peerID)
    }
    
    return result
}

Simulcast — передача потока в нескольких разрешениях:

// Настройка simulcast для трека
func setupSimulcast(track *webrtc.TrackLocalStaticRTP) {
    // Три слоя: низкое, среднее, высокое качество
    encodings := []webrtc.RTPEncodingParameters{
        {
            RID:    "low",
            MaxBitrate: 150_000,  // 150 Kbps — 360p
            ScaleResolutionDownBy: 4,
        },
        {
            RID:    "mid",
            MaxBitrate: 600_000,  // 600 Kbps — 540p
            ScaleResolutionDownBy: 2,
        },
        {
            RID:    "high",
            MaxBitrate: 1_500_000, // 1.5 Mbps — 1080p
            ScaleResolutionDownBy: 1,
        },
    }
    
    // SFU выбирает нужный слой для каждого получателя
    // на основе размера окна и доступной полосы
}

Сравнение топологий для 20 участников:

Метрика	Mesh P2P	SFU
Нагрузка на клиент (uplink)	19 × 1.5 = 28.5 Mbps	1 × 1.5 = 1.5 Mbps
Нагрузка на клиент (downlink)	19 × 1.5 = 28.5 Mbps	19 × 1.5 = 28.5 Mbps
Нагрузка на сервер	0	570 Mbps
Задержка	Минимальная (P2P)	Небольшая (+20-50ms на SFU)
Сложность реализации	Высокая	Средняя
Контроль над качеством	Нет	Да (simulcast, SVC)
Запись звонков	Сложно	Просто (на SFU)
Стоимость инфраструктуры	Низкая	Высокая

Рекомендация для данного проекта:

SFU — оптимальный выбор, потому что:

1. Клиентская нагрузка в uplink критична — у пользователей часто слабый upload
2. 20 участников — это предел, где SFU ещё справляется одним инстансом
3. Бюджет не ограничен — можно позволить мощные серверы
4. Simulcast на SFU позволяет адаптировать качество для каждого получателя
5. Запись звонков в будущем реализуется тривиально на SFU

Гибридный подход для оптимизации:

// Автоматический выбор топологии на основе количества участников
func (s *SFUNode) SelectTopology(peerCount int) Topology {
    switch {
    case peerCount <= 3:
        return TopologyMesh // P2P для малых групп — минимальная задержка
    case peerCount <= 20:
        return TopologySFU  // SFU для средних групп
    default:
        return TopologySFUWithCascading // Каскадные SFU для больших групп
    }
}

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

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

Ответ собеседника: Правильный. Кандидат рассчитал: ~1 млн звонков в час, ~3000 новых звонков в секунду (RPS), ~30 000 одновременных открытых сессий. Одна мощная нода справится с такой нагрузкой. Для высокой доступности (четыре девятки) нужно минимум 2-3 ноды.

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

Кандидат провёл расчёт нагрузки. Уточним и расширим.

Расчёт RPS и одновременных сессий:

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

• 40 млрд звонков в месяц
• Средняя длительность звонка: ~10 минут
• Среднее количество участников: 5

Звонков в месяц: 40 × 10^9
Звонков в час: 40 × 10^9 / (30 × 24) ≈ 55.6 × 10^6 звонков/час
Звонков в секунду (среднее): 55.6 × 10^6 / 3600 ≈ 15 432 RPS
Звонков в секунду (пик, ×3): ≈ 46 296 RPS

Одновременных звонков (среднее):
15 432 × 600 сек (10 мин) ≈ 9.26 × 10^6 звонков

Одновременных участников (среднее):
9.26 × 10^6 × 5 ≈ 46.3 × 10^6 участников

Одновременных участников (пик):
46.3 × 10^6 × 3 ≈ 139 × 10^6 участников

Кандидат привёл консервативные оценки (~1 млн звонков/час, ~3000 RPS, ~30 000 сессий) — вероятно, для начального этапа запуска, а не для целевого масштаба.

Расчёт нагрузки на SFU-серверы:

// Расчёт ресурсов для SFU
type SFUNodeCapacity struct {
    MaxBandwidthMbps   int // 10 Gbps NIC
    MaxPeersPerNode    int // Ограничение CPU/RAM
    BandwidthPerPeer   float64 // Mbps (uplink + downlink)
}

type LoadEstimate struct {
    TotalParticipants    int
    AvgParticipantsPerRoom int
    TotalBandwidthGbps   float64
    SFUNodesNeeded       int
}

func CalculateSFUNodes(participants int) LoadEstimate {
    const (
        bandwidthPerPeerMbps = 3.0 // 1.5 uplink + 1.5 downlink (среднее)
        maxBandwidthPerNodeGbps = 10.0
        maxPeersPerNode = 2000 // Консервативная оценка
    )
    
    totalBandwidthGbps := float64(participants) * bandwidthPerPeerMbps / 1000
    
    nodesByBandwidth := int(math.Ceil(totalBandwidthGbps / maxBandwidthPerNodeGbps))
    nodesByPeers := int(math.Ceil(float64(participants) / float64(maxPeersPerNode)))
    
    nodesNeeded := max(nodesByBandwidth, nodesByPeers)
    
    return LoadEstimate{
        TotalParticipants:    participants,
        AvgParticipantsPerRoom: 5,
        TotalBandwidthGbps:   totalBandwidthGbps,
        SFUNodesNeeded:       nodesNeeded,
    }
}

// Для 46.3 млн участников (среднее):
// Bandwidth: 46.3 × 10^6 × 3 / 1000 = 138.9 Tbps
// Nodes by bandwidth: 138.9 × 1000 / 10 = 13 890 нод
// Nodes by peers: 46.3 × 10^6 / 2000 = 23 150 нод
// Total: ~23 150 SFU нод

Для начального этапа (оценка кандидата — 30 000 сессий):

30 000 одновременных участников
Bandwidth: 30 000 × 3 / 1000 = 90 Gbps
Nodes by bandwidth: 90 / 10 = 9 нод
Nodes by peers: 30 000 / 2000 = 15 нод
Total: ~15 SFU нод

Конфигурация SFU-ноды:

type SFUNodeConfig struct {
    // Аппаратные требования
    CPUCores      int     `json:"cpu_cores"`      // 16-32 cores
    RAMGB         int     `json:"ram_gb"`          // 32-64 GB
    NetworkGbps   float64 `json:"network_gbps"`    // 10 Gbps NIC
    
    // Лимиты приложения
    MaxPeers      int     `json:"max_peers"`       // 2000
    MaxBandwidthMbps int  `json:"max_bandwidth_mbps"` // 8000 (80% от 10 Gbps)
}

func DefaultSFUNodeConfig() SFUNodeConfig {
    return SFUNodeConfig{
        CPUCores:      32,
        RAMGB:         64,
        NetworkGbps:   10,
        MaxPeers:      2000,
        MaxBandwidthMbps: 8000,
    }
}

Отказоустойчивость — количество нод:

Для 99.99% доступности применяется правило N+2:

type ClusterConfig struct {
    MinNodes        int     // Минимальное количество нод для нагрузки
    RedundancyNodes int     // +2 для отказоустойчивости
    TotalNodes      int     // Итого
}

func CalculateClusterSize(loadNodes int) ClusterConfig {
    return ClusterConfig{
        MinNodes:        loadNodes,
        RedundancyNodes: 2,
        TotalNodes:      loadNodes + 2,
    }
}

// Для начального этапа (15 нод):
// MinNodes: 15
// TotalNodes: 17 (15 + 2)

// Для целевого масштаба (23 150 нод):
// MinNodes: 23150
// TotalNodes: 23172 (23150 + 22, ~0.1% redundancy)

Распределение по регионам:

type RegionConfig struct {
    Name          string
    SFUNodes      int
    SignalingNodes int
    RedisNodes    int
    PostgresNodes int
}

func GetGlobalDeployment() []RegionConfig {
    return []RegionConfig{
        {
            Name:           "us-east-1",
            SFUNodes:       5000,
            SignalingNodes: 100,
            RedisNodes:     6,
            PostgresNodes:  3,
        },
        {
            Name:           "eu-west-1",
            SFUNodes:       4000,
            SignalingNodes: 80,
            RedisNodes:     6,
            PostgresNodes:  3,
        },
        {
            Name:           "ap-southeast-1",
            SFUNodes:       3000,
            SignalingNodes: 60,
            RedisNodes:     6,
            PostgresNodes:  3,
        },
        // ... другие регионы
    }
}

Автоматическое масштабирование:

type AutoScaler struct {
    k8sClient    kubernetes.Interface
    metricsClient *MetricsClient
    
    // Пороги для масштабирования
    scaleUpCPUThreshold    float64 // 70%
    scaleDownCPUThreshold  float64 // 30%
    scaleUpBandwidthThreshold float64 // 80%
    
    minReplicas int32
    maxReplicas int32
}

func (a *AutoScaler) Evaluate() {
    cpuUsage := a.metricsClient.GetAverageCPU("sfu-deployment")
    bandwidthUsage := a.metricsClient.GetAverageBandwidth("sfu-deployment")
    currentReplicas := a.getCurrentReplicas("sfu-deployment")
    
    if cpuUsage > a.scaleUpCPUThreshold || bandwidthUsage > a.scaleUpBandwidthThreshold {
        newReplicas := min(currentReplicas*2, a.maxReplicas)
        a.scaleDeployment("sfu-deployment", newReplicas)
    } else if cpuUsage < a.scaleDownCPUThreshold && bandwidthUsage < a.scaleDownBandwidthThreshold/2 {
        newReplicas := max(currentReplicas/2, a.minReplicas)
        a.scaleDeployment("sfu-deployment", newReplicas)
    }
}

func (a *AutoScaler) scaleDeployment(deployment string, replicas int32) {
    a.k8sClient.AppsV1().Deployments("sfu-namespace").Update(
        context.TODO(),
        &appsv1.Deployment{
            Spec: appsv1.DeploymentSpec{
                Replicas: &replicas,
            },
        },
        metav1.UpdateOptions{},
    )
}

Итоговая оценка инфраструктуры для целевого масштаба:

Компонент	Количество	Конфигурация
SFU ноды	~23 000	32 CPU, 64 GB RAM, 10 Gbps
Signaling ноды	~500	8 CPU, 16 GB RAM
Redis Cluster	~30 (по 6 на регион)	16 CPU, 64 GB RAM
PostgreSQL	~15 (по 3 на регион)	16 CPU, 128 GB RAM, SSD
TURN серверы	~200	8 CPU, 16 GB RAM, 10 Gbps
Load Balancers	~10	Managed (AWS ALB)

Для начального этапа с 30 000 одновременных участников кандидат верно оценил: ~15 SFU-нод + 2 резервных = 17 нод.

Вопрос 18. Как организовать отказоустойчивость Session Storage и User Storage? Какой алгоритм балансировки выбрать для API Gateway?

Таймкод: 00:35:52

Ответ собеседника: Правильный. Кандидат предложил: для Session Storage — репликация Master-Slave с мониторингом и автоматическим failover в пределах 5-10 секунд. Для User Storage — шардирование + реплики на каждом шарде (данные ~1 ТБ на миллиард пользователей). Для API Gateway — Least Connections или Round Robin (Least Connections предпочтительнее для адаптации к реальной нагрузке). Авторизацию вынести в отдельный компонент.

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

Кандидат дал развёрнутый и корректный ответ. Детализируем каждый компонент.

Session Storage (Redis Cluster):

Для хранения активных сессий, состояния комнат и координации между серверами — Redis Cluster.

// Структура данных в Redis для сессий
type SessionStore struct {
    client *redis.ClusterClient
}

// Хранение состояния комнаты
func (s *SessionStore) SaveRoomState(ctx context.Context, room *Room) error {
    key := fmt.Sprintf("room:%s", room.ID)
    data, err := json.Marshal(room)
    if err != nil {
        return err
    }
    // TTL — 24 часа, после чего комната автоматически удаляется
    return s.client.Set(ctx, key, data, 24*time.Hour).Err()
}

// Хранение маппинга пир -> сервер
func (s *SessionStore) SetPeerServer(ctx context.Context, peerID, serverID string) error {
    key := fmt.Sprintf("peer:%s:server", peerID)
    // TTL — время жизни сессии
    return s.client.Set(ctx, key, serverID, 1*time.Hour).Err()
}

// Pub/Sub для сигнализации между серверами
func (s *SessionStore) SubscribeToRoom(ctx context.Context, roomID string) *redis.PubSub {
    return s.client.Subscribe(ctx, fmt.Sprintf("room:%s:events", roomID))
}

func (s *SessionStore) PublishRoomEvent(ctx context.Context, roomID string, event RoomEvent) error {
    data, _ := json.Marshal(event)
    return s.client.Publish(ctx, fmt.Sprintf("room:%s:events", roomID), data).Err()
}

Redis Cluster конфигурация:

func NewRedisCluster(addrs []string) *redis.ClusterClient {
    return redis.NewClusterClient(&redis.ClusterOptions{
        Addrs:        addrs,
        PoolSize:     100,
        MinIdleConns: 20,
        MaxRetries:   3,
        ReadTimeout:  200 * time.Millisecond,
        WriteTimeout: 200 * time.Millisecond,
        RouteRandomly: true, // Читаем с реплик
    })
}

Redis Cluster обеспечивает:

• Автоматическое шардирование — данные распределяются по 16384 слотам
• Репликация — каждый мастер имеет 1-2 реплики
• Automatic failover — при падении мастера реплика промоутится за 5-10 секунд
• Высокая доступность — кластер работает при потере части нод

User Storage (PostgreSQL с шардированием):

Оценка данных на миллиард пользователей:

-- Таблица пользователей (~1 ТБ)
CREATE TABLE users (
    id            VARCHAR(36) PRIMARY KEY,  -- 36 байт
    email         VARCHAR(255) NOT NULL,     -- ~50 байт среднее
    display_name  VARCHAR(255),              -- ~30 байт среднее
    password_hash VARCHAR(255),              -- 60 байт
    avatar_url    VARCHAR(500),              -- ~100 байт среднее
    created_at    TIMESTAMP,                 -- 8 байт
    last_login    TIMESTAMP,                 -- 8 байт
    settings      JSONB                      -- ~200 байт среднее
);
-- Итого: ~500 байт на пользователя
-- 1 млрд × 500 байт = ~500 ГБ (кандидат оценил в ~1 ТБ с запасом на индексы)

Шардирование по User ID:

// Шардирование PostgreSQL
type ShardRouter struct {
    shards []*sql.DB
    numShards int
}

func NewShardRouter(connStrings []string) (*ShardRouter, error) {
    shards := make([]*sql.DB, len(connStrings))
    for i, cs := range connStrings {
        db, err := sql.Open("pgx", cs)
        if err != nil {
            return nil, err
        }
        db.SetMaxOpenConns(50)
        db.SetMaxIdleConns(10)
        shards[i] = db
    }
    return &ShardRouter{shards: shards, numShards: len(shards)}, nil
}

func (sr *ShardRouter) GetShard(userID string) *sql.DB {
    // Хэш от user_id для определения шарда
    h := fnv.New32a()
    h.Write([]byte(userID))
    shardIndex := int(h.Sum32()) % sr.numShards
    return sr.shards[shardIndex]
}

func (sr *ShardRouter) QueryUser(ctx context.Context, userID string) (*User, error) {
    db := sr.GetShard(userID)
    var user User
    err := db.QueryRowContext(ctx,
        "SELECT id, email, display_name, created_at FROM users WHERE id = $1",
        userID,
    ).Scan(&user.ID, &user.Email, &user.DisplayName, &user.CreatedAt)
    return &user, err
}

Репликация на каждом шарде:

Шард 1: Master (us-east-1a) → Replica 1 (us-east-1b) → Replica 2 (us-west-2a)
Шард 2: Master (us-east-1b) → Replica 1 (us-east-1c) → Replica 2 (eu-west-1a)
Шард 3: Master (eu-west-1a) → Replica 1 (eu-west-1b) → Replica 2 (us-east-1a)
...

// Read-Write splitting для шарда
type Shard struct {
    master  *sql.DB
    replicas []*sql.DB
    mu      sync.RWMutex
}

func (s *Shard) Query(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error) {
    // Читаем с реплики (round-robin)
    replica := s.getNextReplica()
    return replica.QueryContext(ctx, query, args...)
}

func (s *Shard) Exec(ctx context.Context, query string, args ...interface{}) (sql.Result, error) {
    // Пишем в мастер
    return s.master.ExecContext(ctx, query, args...)
}

API Gateway — балансировка:

// Least Connections балансировщик
type LeastConnectionsBalancer struct {
    backends []*Backend
    mu       sync.RWMutex
}

type Backend struct {
    Address    string
    Connections int64 // Атомарный счётик
    Healthy    bool
}

func (lb *LeastConnectionsBalancer) Next() *Backend {
    lb.mu.RLock()
    defer lb.mu.RUnlock()
    
    var selected *Backend
    minConnections := int64(math.MaxInt64)
    
    for _, b := range lb.backends {
        if !b.Healthy {
            continue
        }
        conns := atomic.LoadInt64(&b.Connections)
        if conns < minConnections {
            minConnections = conns
            selected = b
        }
    }
    
    if selected != nil {
        atomic.AddInt64(&selected.Connections, 1)
    }
    return selected
}

func (lb *LeastConnectionsBalancer) Release(backend *Backend) {
    atomic.AddInt64(&backend.Connections, -1)
}

// Middleware для подсчёта соединений
func (lb *LeastConnectionsBalancer) Middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        backend := lb.Next()
        if backend == nil {
            http.Error(w, "no backends available", http.StatusServiceUnavailable)
            return
        }
        defer lb.Release(backend)
        
        // Проксируем запрос
        proxy := httputil.NewSingleHostReverseProxy(backend.URL)
        proxy.ServeHTTP(w, r)
    })
}

Сравнение алгоритмов балансировки:

Алгоритм	Плюсы	Минусы	Когда использовать
Round Robin	Простой, равномерный	Не учитывает нагрузку	Одинаковые бэкенды, короткие запросы
Least Connections	Адаптивный, учитывает загрузку	Сложнее, нужен трекинг	Длинные соединения (WebSocket, gRPC)
IP Hash	Сессионная аффинность	Неравномерное распределение	Нужна привязка клиента к серверу
Weighted	Учитывает мощность нод	Нужна ручная настройка	Разнородные серверы

Least Connections предпочтительнее для данного проекта, потому что:

• WebSocket/gRPC соединения для сигнализации — длинные
• Нагрузка на серверы неравномерна (разное количество участников в комнатах)
• Автоматическая адаптация без ручной настройки весов

Авторизация — отдельный компонент:

// Auth Service — отдельный микросервис
type AuthService struct {
    jwtManager  *JWTManager
    userStore   UserStore
    oauthConfig OAuthConfig
}

type JWTManager struct {
    privateKey *ecdsa.PrivateKey
    publicKey  *ecdsa.PublicKey
    issuer     string
}

func (j *JWTManager) GenerateToken(userID string, roomID string) (string, error) {
    claims := PeerClaims{
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(1 * time.Hour)),
            IssuedAt:  jwt.NewNumericDate(time.Now()),
            Issuer:    j.issuer,
        },
        RoomID: roomID,
        PeerID: userID,
    }
    
    token := jwt.NewWithClaims(jwt.SigningMethodES256, claims)
    return token.SignedString(j.privateKey)
}

func (j *JWTManager) ValidateToken(tokenString string) (*PeerClaims, error) {
    claims := &PeerClaims{}
    token, err := jwt.ParseWithClaims(tokenString, claims, func(t *jwt.Token) (interface{}, error) {
        return j.publicKey, nil
    })
    if err != nil || !token.Valid {
        return nil, fmt.Errorf("invalid token")
    }
    return claims, nil
}

// Auth middleware для API Gateway
func AuthMiddleware(jwtManager *JWTManager) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            token := r.Header.Get("Authorization")
            if token == "" {
                http.Error(w, "missing token", http.StatusUnauthorized)
                return
            }
            
            claims, err := jwtManager.ValidateToken(strings.TrimPrefix(token, "Bearer "))
            if err != nil {
                http.Error(w, "invalid token", http.StatusUnauthorized)
                return
            }
            
            // Добавляем claims в контекст
            ctx := context.WithValue(r.Context(), "peer_claims", claims)
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }
}

Failover для Session Storage:

// Redis Sentinel для automatic failover
func NewRedisSentinel(addrs []string) *redis.Client {
    return redis.NewFailoverClient(&redis.FailoverOptions{
        MasterName:    "mymaster",
        SentinelAddrs: addrs,
        PoolSize:      100,
        MinIdleConns:  20,
        MaxRetries:    3,
        DialTimeout:   5 * time.Second,
        ReadTimeout:   3 * time.Second,
        WriteTimeout:  3 * time.Second,
    })
}

// Failover происходит автоматически:
// 1. Sentinel обнаруживает падение мастера (5-10 секунд)
// 2. Sentinel промоутит реплику в мастера
// 3. Клиенты переключаются на нового мастера
// 4. Время простоя: 5-10 секунд (в пределах SLA 99.99%)

Вопрос 19. Как обеспечить низкую задержку для международных звонков между удалёнными регионами (Сан-Франциско, Гамбург, Токио)? Хватит ли бюджета времени при 600 мс сетевой задержки? Посчитайте битрейт и оцените необходимое количество GPU-серверов.

Таймкод: 00:43:44

Ответ собеседника: Правильный. Кандидат рассчитал: световая задержка Сан-Франциско — Токио ~600 мс RTT, остаётся ~400 мс на обработку. Битрейт 1080p с H.265 ≈ 5 Мбит/с на поток, 20 потоков = 100 Мбит/с входящий. По памяти 30000 звонков влезают в один инстанс. По GPU — одна RTX 4050 справляется с одним звонком (20 потоков), более мощная GPU — ~50 звонков. Итого нужно ~600 GPU (~60-70 серверов по 8-10 GPU). Нагрузка распределяется хэшированием по ID звонка.

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

Кандидат провёл детальный расчёт. Уточним и расширим.

Световая задержка между регионами:

Сан-Франциско ↔ Гамбург:     ~160-180 ms RTT
Сан-Франциско ↔ Токио:       ~200-220 ms RTT  
Гамбург ↔ Токио:             ~280-320 ms RTT

Максимальная RTT (SF ↔ Tokyo): ~220 ms (не 600 ms)
600 ms — это с учётом сетевых задержек (routing, congestion, processing)

Бюджет задержки в 1-2 секунды при RTT ~600ms оставляет ~400-1400ms на обработку — этого достаточно для SFU, но критично для MCU с транскодированием.

Архитектура для минимизации задержки — региональные SFU:

[SF] Клиент A ──→ SFU US-West ──╮
[SF] Клиент B ──→ SFU US-West ──┤
                                 ├── SFU Interconnect (专线)
[HH] Клиент C ──→ SFU EU-Cenral ─┤
[HH] Клиент D ──→ SFU EU-Central ─┤
                                 │
[TY] Клиент E ──→ SFU AP-East ───╯

Каждый участник подключается к ближайшему SFU. Между SFU — выделенные каналы или оптимизированный маршрут.

// Выбор ближайшего SFU для клиента
type GeoRouter struct {
    regions map[string]*SFURegion
}

type SFURegion struct {
    Name     string
    Location string // AWS region
    SFUNodes []*SFUNode
    Latency  map[string]int // RTT до других регионов
}

func (gr *GeoRouter) SelectBestRegion(clientIP string) string {
    // GeoIP lookup
    clientLocation := geoip.Lookup(clientIP)
    
    bestRegion := ""
    minLatency := math.MaxInt64
    
    for name, region := range gr.regions {
        latency := estimateLatency(clientLocation, region.Location)
        if latency < minLatency {
            minLatency = latency
            bestRegion = name
        }
    }
    
    return bestRegion
}

Расчёт битрейта:

Разрешение	Кодек	Битрейт	Примечание
360p	H.264	300-500 Kbps	Минимум
720p	H.264	1.0-1.5 Mbps	Стандарт
1080p	H.264	2.5-4.0 Mbps	HD
1080p	H.265	1.5-2.5 Mbps	HD, эффективнее
1080p	VP8	2.0-3.0 Mbps	WebRTC default

Для 20 участников с 720p:

• Каждый отправляет: 1.5 Mbps
• Каждый получает 19 потоков: 19 × 1.5 = 28.5 Mbps
• SFU обрабатывает: 20 × 1.5 × 19 = 570 Mbps на комнату

GPU-серверы — нужны ли они?

Важное уточнение: SFU не требует GPU. SFU маршрутизирует RTP-пакеты без декодирования — это CPU-операция с сетевыми буферами.

GPU потребуется только при использовании MCU (Multipoint Control Unit), где происходит:

• Декодирование видео
• Композитинг (склейка нескольких видео в один кадр)
• Кодирование результата

Для данного проекта кандидат выбрал SFU, поэтому GPU не нужны для основного сценария. GPU могут понадобиться для:

• Записи звонков с транскодированием (не в scope)
• AI-функций: шумоподавление, фон, субтитры (future)

Расчёт ресурсов SFU (без GPU):

type SFUNodeResources struct {
    CPUThreads    int
    RAMGB         int
    NetworkGbps   float64
}

func CalculateSFUNodeLoad(peerCount int, avgBitrateKbps int) SFUNodeResources {
    // CPU: ~1 core на 500 пиров для RTP маршрутизации
    cpuNeeded := peerCount / 500
    if cpuNeeded < 4 {
        cpuNeeded = 4
    }
    
    // RAM: ~100 КБ на пира (jitter buffer, structs)
    ramNeeded := (peerCount * 100) / 1024 / 1024 // GB
    if ramNeeded < 4 {
        ramNeeded = 4
    }
    
    // Network: полная маршрутизация
    bandwidthMbps := float64(peerCount) * float64(avgBitrateKbps) * 2 / 1000
    
    return SFUNodeResources{
        CPUThreads:  cpuNeeded,
        RAMGB:       ramNeeded,
        NetworkGbps: bandwidthMbps / 1000,
    }
}

// Для 30 000 одновременных участников:
// Распределение по 15 нодам: 2000 пиров на ноду
// CPU: 2000/500 = 4 cores (минимум)
// RAM: 2000 × 100KB = 200MB (минимум 4GB)
// Network: 2000 × 1500 × 2 / 1000 = 6 Gbps

Если MCU всё же используется (для сравнения):

// GPU transcoding estimation
type GPUCapacity struct {
    Model           string
    EncodeStreams   int // Одновременных encode
    DecodeStreams   int // Одновременных decode
    CompositeStreams int // Композитинг потоков
}

var GPUSpecs = map[string]GPUCapacity{
    "NVIDIA T4": {
        EncodeStreams:    30,  // H.264 encode
        DecodeStreams:    50,  // H.264 decode
        CompositeStreams: 5,   // 20 входов → 1 выход
    },
    "NVIDIA A10": {
        EncodeStreams:    60,
        DecodeStreams:    100,
        CompositeStreams: 10,
    },
    "NVIDIA A100": {
        EncodeStreams:    120,
        DecodeStreams:    200,
        CompositeStreams: 20,
    },
}

// Для MCU с 20 участниками:
// Decode: 20 входящих потоков
// Composite: 1 композит (20 → 1)
// Encode: 20 исходящих потоков (каждому — свой layout)
// Итого: 20 decode + 20 encode = 40 streams
// На T4: 50 decode OK, 30 encode → хватит для ~15 участников
// На A10: 100 decode OK, 60 encode → хватит для ~30 участников

Распределение комнат по серверам:

// Consistent hashing для распределения комнат по SFU-нодам
type RoomRouter struct {
    ring *consistent.Consistent
}

func NewRoomRouter(nodeIDs []string) *RoomRouter {
    ring := consistent.New()
    for _, id := range nodeIDs {
        ring.Add(id)
    }
    return &RoomRouter{ring: ring}
}

func (rr *RoomRouter) GetNodeForRoom(roomID string) (string, error) {
    return rr.ring.Get(roomID)
}

// Все участники одной комнаты направляются на один SFU
// Это критично для SFU — иначе нужна SFU-to-SFU передача
func (rr *RoomRouter) RoutePeerToNode(peerID, roomID string) (string, error) {
    nodeID, err := rr.GetNodeForRoom(roomID)
    if err != nil {
        return "", err
    }
    
    // Сохраняем маппинг пир → нода в Redis
    return nodeID, nil
}

Итоговая рекомендация:

Для данного проекта с SFU-архитектурой:

• GPU не требуются — SFU работает на CPU
• Для 30 000 участников: ~15-20 SFU-нод с 32 CPU, 64 GB RAM, 10 Gbps NIC
• Для целевого масштаба (46 млн участников): ~23 000 SFU-нод
• Между региональными SFU — оптимизированный backbone или AWS Global Accelerator
• RTT 600ms — это верхняя граница; при региональных SFU участники подключаются к ближайшему, и RTT снижается до 50-100ms внутри региона

Вопрос 20. Какие метрики мониторинга нужно отслеживать (бизнесовые и технические)? Как организовать Disaster Recovery для сессий и пользовательских данных?

Таймкод: 00:58:51

Ответ собеседника: Правильный. Кандидат разделил мониторинг на бизнесовый и технический. Бизнес-метрики: количество одновременных сессий, график новых звонков (RPS), средняя продолжительность сессии (~1 час, резкое падение — признак проблем). Технические: throughput, количество подключений по компонентам, потребление памяти медиасерверами, алерты на аномалии. Для Disaster Recovery: User Storage — реплики + бэкапы (RPO ~1 час). Session Storage — ротация каждые 15 минут, чтобы при падении терять только сессии длительностью до 1 часа.

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

Кандидат провёл качественный анализ. Детализируем и дополним.

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

// Business Metrics Collector
type BusinessMetrics struct {
    // Активные сессии
    ActiveRooms        prometheus.Gauge
    ActiveParticipants prometheus.Gauge
    
    // Создание звонков
    RoomsCreatedTotal  prometheus.Counter
    RoomsCreatedRate   prometheus.Gauge // RPS
    
    // Качество звонков
    AvgCallDuration    prometheus.Histogram
    CallCompletionRate prometheus.Gauge // % звонков, завершённых нормально
    
    // География
    ParticipantsByRegion *prometheus.GaugeVec
}

func NewBusinessMetrics() *BusinessMetrics {
    return &BusinessMetrics{
        ActiveRooms: prometheus.NewGauge(prometheus.GaugeOpts{
            Name: "vc_active_rooms",
            Help: "Number of active conference rooms",
        }),
        ActiveParticipants: prometheus.NewGauge(prometheus.GaugeOpts{
            Name: "vc_active_participants",
            Help: "Number of active participants",
        }),
        RoomsCreatedTotal: prometheus.NewCounter(prometheus.CounterOpts{
            Name: "vc_rooms_created_total",
            Help: "Total number of created rooms",
        }),
        AvgCallDuration: prometheus.NewHistogram(prometheus.HistogramOpts{
            Name:    "vc_call_duration_seconds",
            Help:    "Call duration distribution",
            Buckets: []float64{60, 300, 600, 1800, 3600, 7200},
        }),
        ParticipantsByRegion: prometheus.NewGaugeVec(prometheus.GaugeOpts{
            Name: "vc_participants_by_region",
            Help: "Number of participants per region",
        }, []string{"region"}),
    }
}

// Ключевая бизнес-метрика: резкое падение средней длительности звонка
// Нормально: 10-60 минут
// Проблема: < 2 минуты (участники отключаются из-за плохого качества)
func (bm *BusinessMetrics) CheckCallQualityAnomaly() {
    avgDuration := bm.AvgCallDuration.Sum() / bm.AvgCallDuration.Count()
    if avgDuration < 120 { // 2 минуты
        alertmanager.Send(Alert{
            Severity: "critical",
            Title:    "Call quality anomaly detected",
            Message:  fmt.Sprintf("Average call duration dropped to %.0f seconds", avgDuration),
        })
    }
}

Технические метрики:

// Technical Metrics
type TechnicalMetrics struct {
    // SFU метрики
    SFUPeers          *prometheus.GaugeVec
    SFUBandwidthIn    *prometheus.GaugeVec
    SFUBandwidthOut   *prometheus.GaugeVec
    SFURTPPacketsRate *prometheus.CounterVec
    SFUPacketLoss     *prometheus.GaugeVec
    SFUJitterMs       *prometheus.HistogramVec
    
    // Signaling метрики
    WSSConnections    prometheus.Gauge
    WSSMessagesRate   prometheus.Counter
    WSSFailedConnections prometheus.Counter
    
    // Системные метрики
    CPUUsage          *prometheus.GaugeVec
    MemoryUsage       *prometheus.GaugeVec
    NetworkIn         *prometheus.GaugeVec
    NetworkOut        *prometheus.GaugeVec
    
    // Зависимости
    RedisLatency      prometheus.Histogram
    PostgresLatency   prometheus.Histogram
    RedisErrors       prometheus.Counter
    PostgresErrors    prometheus.Counter
}

func NewTechnicalMetrics() *TechnicalMetrics {
    return &TechnicalMetrics{
        SFUPeers: prometheus.NewGaugeVec(prometheus.GaugeOpts{
            Name: "sfu_peers",
            Help: "Number of peers per SFU node",
        }, []string{"node_id", "region"}),
        SFUBandwidthIn: prometheus.NewGaugeVec(prometheus.GaugeOpts{
            Name: "sfu_bandwidth_in_mbps",
            Help: "Incoming bandwidth per SFU node",
        }, []string{"node_id"}),
        SFUBandwidthOut: prometheus.NewGaugeVec(prometheus.GaugeOpts{
            Name: "sfu_bandwidth_out_mbps",
            Help: "Outgoing bandwidth per SFU node",
        }, []string{"node_id"}),
        SFUPacketLoss: prometheus.NewGaugeVec(prometheus.GaugeOpts{
            Name: "sfu_packet_loss_percent",
            Help: "RTP packet loss percentage",
        }, []string{"node_id", "peer_id"}),
        SFUJitterMs: prometheus.NewHistogramVec(prometheus.HistogramOpts{
            Name:    "sfu_jitter_ms",
            Help:    "RTP jitter in milliseconds",
            Buckets: []float64{5, 10, 20, 50, 100, 200},
        }, []string{"node_id"}),
        WSSConnections: prometheus.NewGauge(prometheus.GaugeOpts{
            Name: "signaling_ws_connections",
            Help: "Active WebSocket connections",
        }),
        RedisLatency: prometheus.NewHistogram(prometheus.HistogramOpts{
            Name:    "redis_operation_duration_ms",
            Help:    "Redis operation latency",
            Buckets: []float64{1, 5, 10, 25, 50, 100},
        }),
    }
}

Ключевые метрики качества медиа (WebRTC):

// WebRTC статистика из pion
func (p *SFUPeer) CollectStats() {
    stats := p.PC.GetStats()
    
    for _, stat := range stats {
        switch s := stat.(type) {
        case webrtc.InboundRTPStreamStats:
            // Входящий поток
            packetLossPct := float64(s.PacketsLost) / float64(s.PacketsReceived+s.PacketsLost) * 100
            metrics.SFUPacketLoss.WithLabelValues(p.NodeID, p.ID).Set(packetLossPct)
            
        case webrtc.OutboundRTPStreamStats:
            // Исходящий поток
            metrics.SFUBandwidthOut.WithLabelValues(p.NodeID).Add(
                float64(s.BytesSent) * 8 / 1_000_000, // Mbps
            )
            
        case webrtc.RemoteInboundRTPStreamStats:
            // Статистика удалённого пира о нашем потоке
            metrics.SFUJitterMs.WithLabelValues(p.NodeID).Observe(float64(s.Jitter))
        }
    }
}

Алерты:

// Alert rules
type AlertRule struct {
    Name        string
    Expression  string
    Duration    time.Duration
    Severity    string
    Description string
}

var AlertRules = []AlertRule{
    {
        Name:        "HighPacketLoss",
        Expression:  "sfu_packet_loss_percent > 5",
        Duration:    30 * time.Second,
        Severity:    "warning",
        Description: "Packet loss > 5% for 30 seconds",
    },
    {
        Name:        "CriticalPacketLoss",
        Expression:  "sfu_packet_loss_percent > 15",
        Duration:    10 * time.Second,
        Severity:    "critical",
        Description: "Packet loss > 15% for 10 seconds",
    },
    {
        Name:        "HighJitter",
        Expression:  "histogram_quantile(0.99, sfu_jitter_ms) > 100",
        Duration:    1 * time.Minute,
        Severity:    "warning",
        Description: "P99 jitter > 100ms",
    },
    {
        Name:        "SFUHighCPU",
        Expression:  "cpu_usage_percent{component='sfu'} > 80",
        Duration:    5 * time.Minute,
        Severity:    "warning",
        Description: "SFU CPU > 80% for 5 minutes",
    },
    {
        Name:        "CallDurationAnomaly",
        Expression:  "vc_avg_call_duration_seconds < 120",
        Duration:    5 * time.Minute,
        Severity:    "critical",
        Description: "Average call duration < 2 minutes",
    },
    {
        Name:        "RedisHighLatency",
        Expression:  "histogram_quantile(0.99, redis_operation_duration_ms) > 50",
        Duration:    2 * time.Minute,
        Severity:    "warning",
        Description: "Redis P99 latency > 50ms",
    },
}

Disaster Recovery:

User Storage (PostgreSQL):

-- Стратегия бэкапов
-- 1. Continuous WAL archiving (Point-in-Time Recovery)
-- 2. Ежедневные полные бэкапы
-- 3. WAL files реплицируются в S3

-- postgresql.conf
-- archive_mode = on
-- archive_command = 'aws s3 cp %p s3://backups/wal/%f'
-- wal_level = replica
-- max_wal_senders = 5

// DR для User Storage
type UserStorageDR struct {
    primary   *sql.DB
    replicas  []*sql.DB
    backupS3  *s3.Client
}

// RPO (Recovery Point Objective): ~1 час
// RTO (Recovery Time Objective): ~15 минут

func (dr *UserStorageDR) Failover(ctx context.Context) error {
    // 1. Выбираем наиболее актуальную реплику
    bestReplica := dr.selectMostCurrentReplica()
    
    // 2. Промоутим реплику в мастер
    _, err := bestReplica.ExecContext(ctx, "SELECT pg_promote()")
    if err != nil {
        return fmt.Errorf("failed to promote replica: %w", err)
    }
    
    // 3. Переключаем connection pool
    dr.primary = bestReplica
    
    // 4. Создаём новую реплику из промоутенного мастера
    go dr.provisionNewReplica(ctx)
    
    return nil
}

// Point-in-Time Recovery
func (dr *UserStorageDR) PITR(ctx context.Context, targetTime time.Time) error {
    // 1. Восстанавливаем последний полный бэкап до targetTime
    // 2. Применяем WAL files до targetTime
    // 3. Запускаем PostgreSQL в recovery mode
    return nil
}

Session Storage (Redis):

// DR для Session Storage
// Сессии — эфемерные данные, поэтому DR проще

type SessionStorageDR struct {
    cluster *redis.ClusterClient
}

// Стратегия: сессии живут максимум 1 час
// При потере Redis кластера:
// 1. Пользователи переподключаются (5-10 секунд)
// 2. Комнаты пересоздаются
// 3. Потеря данных: только активные сессии

// RPO: 0 (данные не критичны для сохранения)
// RTO: 5-10 секунд (переподключение клиентов)

// Для ускорения восстановления — периодический snapshot
func (dr *SessionStorageDR) PeriodicSnapshot(ctx context.Context) {
    ticker := time.NewTicker(15 * time.Minute)
    defer ticker.Stop()
    
    for range ticker.C {
        // Сохраняем метаданные активных комнат в PostgreSQL
        dr.snapshotRoomMetadata(ctx)
    }
}

func (dr *SessionStorageDR) snapshotRoomMetadata(ctx context.Context) {
    // Итерируем по всем комнатам в Redis
    iter := dr.cluster.Scan(ctx, 0, "room:*", 100).Iterator()
    
    for iter.Next(ctx) {
        roomKey := iter.Val()
        roomData, err := dr.cluster.Get(ctx, roomKey).Bytes()
        if err != nil {
            continue
        }
        
        // Сохраняем в PostgreSQL для восстановления
        var room Room
        json.Unmarshal(roomData, &room)
        
        db.ExecContext(ctx,
            `INSERT INTO room_snapshots (room_id, creator_id, peer_count, snapshot_at)
             VALUES ($1, $2, $3, NOW())
             ON CONFLICT (room_id) DO UPDATE SET peer_count = $3, snapshot_at = NOW()`,
            room.ID, room.CreatorID, len(room.Peers),
        )
    }
}

Сводная таблица DR:

Компонент	RPO	RTO	Стратегия
User Storage (PostgreSQL)	~1 час	~15 мин	Streaming replication + WAL archiving + daily backups
Session Storage (Redis)	0 (эфемерные)	5-10 сек	Redis Cluster + automatic failover + periodic snapshots
SFU (stateless)	N/A	5-30 сек	Auto-scaling + health checks + drain
Signaling (stateless)	N/A	5-10 сек	Load balancer + health checks
TURN	N/A	10-30 сек	Multiple TURN servers + DNS failover

// Health check endpoint для всех компонентов
func (s *Server) RegisterHealthHandlers() {
    http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        checks := map[string]error{
            "postgres": s.checkPostgres(r.Context()),
            "redis":    s.checkRedis(r.Context()),
            "sfu_pool": s.checkSFUPool(),
        }
        
        allHealthy := true
        for name, err := range checks {
            if err != nil {
                log.Printf("health check failed: %s: %v", name, err)
                allHealthy = false
            }
        }
        
        if !allHealthy {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    })
}

Вопрос 21. Нужно ли разносить инфраструктуру по разным дата-центрам (availability zones)? Как решить проблему с задержками при географически распределённых участниках одного звонка?

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

Ответ собеседника: Неполный. Кандидат отметил необходимость разноса по AZ и DNS-балансировку. Для географически распределённых участников предложил привязку к региону создателя и идею выбора средней точки, но не проработал детально.

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

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

Разнос по Availability Zones:

Для 99.99% доступности обязательно распределение по минимум 3 AZ в каждом регионе:

Region: us-east-1 (Virginia)
├── AZ-a: SFU nodes, Signaling, Redis master
├── AZ-b: SFU nodes, Signaling, Redis replica
└── AZ-c: SFU nodes, Signaling, Redis replica

Region: eu-west-1 (Ireland)
├── AZ-a: SFU nodes, Signaling, Redis master
├── AZ-b: SFU nodes, Signaling, Redis replica
└── AZ-c: SFU nodes, Signaling, Redis replica

// Kubernetes topology spread для распределения по AZ
type TopologyConfig struct {
    ZoneSpread   TopologySpreadConstraint
    RegionSpread TopologySpreadConstraint
}

func DefaultTopologyConfig() TopologyConfig {
    return TopologyConfig{
        ZoneSpread: TopologySpreadConstraint{
            MaxSkew:           1,
            TopologyKey:       "topology.kubernetes.io/zone",
            WhenUnsatisfiable: "DoNotSchedule",
        },
        RegionSpread: TopologySpreadConstraint{
            MaxSkew:           2,
            TopologyKey:       "topology.kubernetes.io/region",
            WhenUnsatisfiable: "ScheduleAnyway",
        },
    }
}

Проблема географически распределённых участников:

Сценарий: создатель звонка в Токио, участники в Сан-Франциско, Гамбурге, Сиднее.

Токио ↔ Сан-Франциско: ~110 ms RTT
Токио ↔ Гамбург:       ~250 ms RTT
Токио ↔ Сидней:        ~130 ms RTT

Если SFU размещён в Токио, участник из Гамбурга получает задержку ~250ms только до SFU, плюс обработка — итого ~300-350ms одсторонняя.

Решение 1: SFU в регионе создателя (простое, но не оптимальное)

// Привязка SFU к региону создателя
type RoomPlacementStrategy int

const (
    PlacementCreatorRegion RoomPlacementStrategy = iota
    PlacementMedianRegion
    PlacementDedicatedSFU
)

func (r *RoomService) PlaceRoom(room *Room, participants []*Peer) (string, error) {
    switch r.strategy {
    case PlacementCreatorRegion:
        // Простое решение — SFU в регионе создателя
        return r.getRegionForPeer(room.CreatorID), nil
        
    case PlacementMedianRegion:
        // Выбираем регион с минимальной суммарной задержкой
        return r.findMedianRegion(participants), nil
        
    case PlacementDedicatedSFU:
        // Выделяем отдельный SFU-кластер для звонка
        return r.allocateDedicatedSFU(participants)
    }
}

Решение 2: Медианная точка — оптимальный выбор региона

// Выбор оптимального региона для размещения SFU
type GeoOptimizer struct {
    regions map[string]*RegionLatency
}

type RegionLatency struct {
    Name    string
    Lat     float64
    Lon     float64
    RTTMap  map[string]int // RTT до других регионов
}

func (go *GeoOptimizer) FindOptimalRegion(participants []*Peer) string {
    // Собираем регионы всех участников
    participantRegions := make(map[string]int) // region -> count
    for _, p := range participants {
        region := go.getRegionForPeer(p.ID)
        participantRegions[region]++
    }
    
    // Для каждого возможного региона SFU считаем суммарную задержку
    bestRegion := ""
    minTotalRTT := math.MaxInt64
    
    for candidateRegion := range go.regions {
        totalRTT := 0
        for participantRegion, count := range participantRegions {
            rtt := go.regions[candidateRegion].RTTMap[participantRegion]
            totalRTT += rtt * count
        }
        
        if totalRTT < minTotalRTT {
            minTotalRTT = totalRTT
            bestRegion = candidateRegion
        }
    }
    
    return bestRegion
}

// Пример: участники в SF (3), HH (2), TK (1)
// Вариант SFU в US-West: 3×0 + 2×180 + 1×220 = 580 ms total
// Вариант SFU в EU-Central: 3×180 + 2×0 + 1×250 = 790 ms total
// Вариант SFU в AP-East: 3×220 + 2×250 + 1×0 = 1160 ms total
// Оптимум: US-West

Решение 3: Каскадные SFU (SFU-to-SFU) — для максимальной оптимизации:

[SF] Клиент A ──→ SFU-US ──╮
[SF] Клиент B ──→ SFU-US ──┤
                            ├── Inter-SFU link (专线)
[HH] Клиент C ──→ SFU-EU ──┤
[HH] Клиент D ──→ SFU-EU ──┤
                            │
[TY] Клиент E ──→ SFU-AP ───╯

Каждый участник подключается к ближайшему SFU. Между SFU передаются только медиапотоки.

// Cascaded SFU architecture
type CascadedSFU struct {
    localSFU    *SFUNode
    remotePeers map[string]*RemoteSFUPeer // region -> remote SFU connection
}

type RemoteSFUPeer struct {
    Region    string
    SFUAddr   string
    PC        *webrtc.PeerConnection // Inter-SFU connection
    Tracks    map[string]*webrtc.TrackLocalStaticRTP
}

func (cs *CascadedSFU) SetupInterSFURegion(remoteRegion string, sfuAddr string) error {
    // Устанавливаем WebRTC соединение с удалённым SFU
    config := webrtc.Configuration{
        ICEServers: []webrtc.ICEServer{
            {URLs: []string{"stun:stun.l.google.com:19302"}},
        },
    }
    
    pc, err := webrtc.NewPeerConnection(config)
    if err != nil {
        return err
    }
    
    cs.remotePeers[remoteRegion] = &RemoteSFUPeer{
        Region:  remoteRegion,
        SFUAddr: sfuAddr,
        PC:      pc,
    }
    
    return nil
}

// Пересылка треков между SFU
func (cs *CascadedSFU) RelayTrackToRemote(track *webrtc.TrackLocalStaticRTP, targetRegion string) {
    remote, exists := cs.remotePeers[targetRegion]
    if !exists {
        return
    }
    
    // Добавляем трек к inter-SFU соединению
    if _, err := remote.PC.AddTrack(track); err != nil {
        log.Printf("failed to relay track to %s: %v", targetRegion, err)
    }
}

Сравнение подходов:

Подход	Задержка (макс)	Сложность	Стоимость	Когда использовать
SFU в регионе создателя	Высокая для далёких	Низкая	Низкая	MVP, небольшие команды
Медианная точка	Средняя	Средняя	Средняя	Оптимальный баланс
Каскадные SFU	Минимальная	Высокая	Высокая	Продукт мирового класса

Практическая рекомендация:

Для 6-месячного релиза с командой 100 человек:

// Гибридная стратегия
func (r *RoomService) SelectSFUStrategy(participants []*Peer) SFUStrategy {
    regions := r.getUniqueRegions(participants)
    
    switch {
    case len(regions) == 1:
        // Все в одном регионе — простой SFU
        return SFUStrategy{
            Type:   "single",
            Region: regions[0],
        }
        
    case len(participants) <= 5:
        // Мало участников — медианная точка
        return SFUStrategy{
            Type:   "median",
            Region: r.findMedianRegion(participants),
        }
        
    default:
        // Много участников из разных регионов — каскадные SFU
        return SFUStrategy{
            Type:     "cascaded",
            Clusters: r.allocateRegionalClusters(participants),
        }
    }
}

DNS-балансировка для выбора ближайшего региона:

// GeoDNS — маршрутизация клиента к ближайшему региону
// Используем AWS Route53 или Cloudflare Load Balancing

// Пример DNS ответа:
// client from US → sfu-us-west-1.example.com (18.236.10.100)
// client from EU → sfu-eu-west-1.example.com (3.250.15.200)
// client from Asia → sfu-ap-northeast-1.example.com (54.168.50.100)

// В Go — health-aware DNS resolution
type GeoDNSResolver struct {
    regions map[string][]net.IP
    health  map[string]bool
}

func (r *GeoDNSResolver) Resolve(clientIP net.IP) (string, error) {
    clientRegion := r.geoLookup(clientIP)
    
    // Проверяем здоровье региона
    if !r.isRegionHealthy(clientRegion) {
        // Fallback на ближайший здоровый регион
        clientRegion = r.findNearestHealthyRegion(clientRegion)
    }
    
    ips := r.regions[clientRegion]
    if len(ips) == 0 {
        return "", fmt.Errorf("no healthy IPs for region %s", clientRegion)
    }
    
    // Round-robin внутри региона
    return ips[rand.Intn(len(ips))].String(), nil
}

Итог:

Кандидат правильно определил проблему, но решение требует трёхуровневого подхода:

1. MVP: SFU в регионе создателя — просто и быстро
2. Оптимизация: Медианная точка — баланс задержки и сложности
3. Масштаб: Каскадные SFU — минимальная задержка для глобальных звонков

Для 99.99% доступности разнос по AZ обязателен — это базовое требование, без которого невозможно достичь целевого SLA.