Как пройти секцию system design на собеседовании по Go: проектируем YouTube | Эйч Навыки

• Обсуждение секции дизайна на собеседованиях в бигтех.  

• Представление спикеров: Дима, бывший разработчик, и Владимир, ментор и руководитель команды.  

• Разбор секции дизайна на примере кейса по проектированию YouTube.  

• Обсуждение, что ожидать от интервьюера и как улучшить свои ответы.  

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

• Трудности самостоятельного обучения и подготовки к собеседованиям.  

• Необходимость поддержки и рекомендаций для эффективного обучения.  

• Описание продукта, который помогает людям учиться самостоятельно.  

• Подстройка программы под конкретного человека и предоставление доступа к материалам.  

• Двухчасовое собеседование для оценки навыков.  

• Определение текущего грейда и построение образовательной траектории.  

• Предоставление файла с оценками и рекомендациями по изучению тем.  

• Примеры тем и уровней знаний для каждого грейда.  

• Предоставление лекций, статей и задач для самостоятельного изучения.  

• Переход к решению задачи и представление Владимира.  

• Владимир рассказывает о своей роли в команде Яндекс и участии в вебинаре.  

• Цель вебинара: разобраться в сути систем дизайн-собеседований.  

• Обсуждение различных подходов к решению задач и подходов к их изучению.  

• В систем дизайн интервью нет правильного ответа.  

• Разные люди могут интерпретировать задачу по-разному.  

• Важно понимать, что интервьюер может иметь свои предпочтения в технологиях и паттернах.  

• В систем дизайн важен общий технический кругозор.  

• Необходимо понимать различные типы хранилищ, очередей и микросервисов.  

• Систем дизайн обязателен для кандидатов на высокие позиции.  

• Заранее изучите высокоуровневую архитектуру компании.  

• Это поможет подготовиться к специфическим вопросам.  

• Важно освежить знания о доменных темах.  

• Важно выяснить, что именно требуется от вас.  

• YouTube включает множество сервисов и функций.  

• Необходимо конкретизировать требования и выделить нужные технические пути.  

• В YouTube есть основной функционал: загрузка и просмотр видео.  

• Важно уточнить, нужны ли социальные функции, лайки, репосты и т.д.  

• Необходимо сосредоточиться на обработке и показе видео.  

• Важно выяснить количество активных пользователей в день.  

• Необходимо определить, сколько времени средний пользователь смотрит видео.  

• Эти данные помогут в проектировании системы.  

• Один процент пользователей заливает видео, в среднем два видео в неделю.  

• Важно задавать много существенных вопросов для уточнения картины.  

• Среднее видео длится пять минут и имеет битрейт восемь мегабит в секунду.  

• Переход от общих параметров к конкретным пользователям и нагрузке.  

• Оценка требуемого места, ресурсов процессора и других параметров.  

• Видео является тяжелым контентом, что требует значительных объемов данных.  

• Оценка прироста хранилища в день: 30 тысяч видео в день.  

• Умножение на среднюю длину и битрейт видео дает 9 терабайт в сутки.  

• Это требует значительных ресурсов и оптимизации.  

• Стоимость хранения данных в облаке, например, в Amazon S3.  

• Примерная стоимость хранения 83 доллара в день.  

• Это подчеркивает важность оптимизации и управления ресурсами.  

• Видео нужно не только загружать, но и отдавать пользователям.  

• Важность пропускной способности и использования CDN.  

• CDN распределяют нагрузку и улучшают качество обслуживания.  

• 10 миллионов пользователей смотрят 30 минут видео в день.  

• Умножение на битрейт видео дает 16,8 мегабайт трафика в день.  

• Стоимость трафика в Amazon CDN составляет 350 долларов в день.  

• Подведение итогов первой стадии собеседования.  

• Ограничение общности и подсчет проблемных мест.  

• Основные узкие места: облачное хранилище и CDN.  

• Начинается второй этап систем дизайна с крупноблочной архитектуры.  

• Пользователь представлен звездочкой, а YouTube - квадратиком.  

• Пользователь хочет загружать и смотреть видео.  

• Используется неформальная схема для иллюстрации.  

• База данных представлена баночкой, сервисы - кружочками.  

• Интервью не требует строгих нотаций, таких как UML.  

• Пользователь приходит на YouTube для просмотра видео.  

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

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

• Следующий шаг - углубление схемы, описание работы сервисов.  

• Важно не углубляться в технические детали, если задача не масштабная.  

• Схема должна быть понятной и не слишком детальной.  

• Видео должно обрабатываться для разных разрешений и форматов.  

• Процесс обработки видео называется транскодирование.  

• Необходимо поддерживать транскодирование для нормального видеохостинга.  

• Заливка видео может быть долгим процессом, особенно для пользователей с телефонов.  

• Технология докачки позволяет продолжать загрузку с прерванного места.  

• Важно учитывать, что многие пользователи загружают видео с телефонов.  

• Данные от клиента идут в облачную платформу.  

• Необходим персистентный сторож для хранения метаинформации о загрузках.  

• Рассматривается использование Redis для обеспечения строгих гарантий и транзакционности.  

• Модель загрузки включает метапараметры и пользователей.  

• Личный кабинет и лента фида требуют перенаправления запросов в разные сервисы.  

• Авторизация и другие функции выносятся за скобки для фокусировки на видео.  

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

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

• Используется масштабируемая и персистентная очередь, например, Kafka или Amazon SQS.  

• Транскодер обрабатывает видео и заливает его в сторож.  

• Сторож используется для хранения обработанного видео и метаинформации.  

• Видео менеджер читает данные из очереди и сохраняет их в базе данных.  

• Метаинформация о видео должна храниться отдельно для управления доступом.  

• Видео менеджер использует базу данных для хранения метаданных и видео.  

• Для быстрого доступа к видео используется API, который будет обращаться к базе данных.  

• Запросы на получение ссылок и изменение метаданных.  

• Использование кэша для оптимизации запросов на чтение.  

• Возможные стратегии кэширования: Redis, Memcached.  

• Система загружает и обрабатывает видео.  

• Обновляет метаданные о видео.  

• Транскодер как критическая точка производительности.  

• Транскодер должен быть масштабируемым и производительным.  

• Использование асинхронной архитектуры и очередей.  

• Валидация видео перед транскодированием.  

• Валидация видео на адекватность.  

• Обработка длинных видео на нескольких машинах.  

• Параллельная обработка видео на независимые блоки.  

• Сплиттер разделяет видео на независимые блоки.  

• Таск-воркеры обрабатывают эти блоки.  

• Гибкая система управления задачами.  

• Временное хранилище для промежуточных артефактов.  

• Комбайнер собирает итоговые видео.  

• Использование масштабируемой базы данных для метаданных.  

• Система может распадаться на несколько частей для каждого сервиса.  

• Комбайнер получает таски из трансподера и проверяет их статус.  

• Можно использовать сервис-демон для проверки состояний видео и отправки уведомлений.  

• Комбайнер проверяет завершенные таски и пишет результаты в базу данных.  

• Архитектура включает множество нюансов, таких как синхронизация и использование очередей.  

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

• Обсуждение отказоустойчивости и добавления новых функций.  

• Пример: стриминг и его влияние на архитектуру.  

• Вопросы о снижении затрат на трафик и оптимизации контента.  

• Важность безопасности при приеме контента от пользователей.  

• Изоляция подсистем для предотвращения вредоносного кода.  

• Обсуждение модерации и защиты от вредоносного контента.  

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

• Важно уметь защищать проект и предлагать решения на лету.  

• Архитектура системы может быть изменена, но важно понимать ход размышлений в ходе собеседования.  

• Не решайте задачу сразу, сначала выясните требования и ограничения.  

• Прорисуйте пользовательские пути и основные юзкейсы.  

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

• Обсуждайте дополнительные вызовы и защиту решений.  

• Используйте книги и ресурсы для подготовки.  

• Готовьтесь к вопросам и защите решений.  

• Продукт помогает в подготовке к смене стека или компании.  

• Включает фидбек и план развития с лекциями и статьями.  

• Начинается с двухчасового технического собеседования.  

• Оцениваются навыки по 58 темам.  

• Интервьюеры – опытные разработчики из Big Tech.  

• После собеседования составляется индивидуальный план развития.  

• Карта навыков показывает проблемные области.  

• Включает набор скилов для каждой темы.  

• База материалов для самостоятельного обучения.  

• Возможность вызова ментора для помощи.  

• Доступ к базе знаний и лекциям.  

• Два тарифа: базовый и с менторскими звонками.  

• Продукт включает двухчасовое собеседование и доступ к базе знаний.  

• Возможность оставить заявку и выбрать удобный способ оплаты.  

• Благодарность за внимание.  

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

• Часто приходится самому выяснять и уточнять требования, даже на уровне заказчиков.  

• Важно понимать, как правильно собирать и обрабатывать требования.  

• Для описания пайплайна обработки видео можно использовать DAG-графы.  

• Нет единого правильного решения, важно пояснить, как работает система.  

• Вопросы о загрузке видео и обработке ошибок.  

• Если загрузка оборвалась, можно использовать cron или таймаут для очистки данных.  

• Вопрос о том, почему не грузить видео с клиента, а использовать API.  

• API абстрагирует доступ к сторожу, что позволяет управлять метаинформацией и общаться с клиентами.  

• Многие базы данных, такие как PostgreSQL и MongoDB, хорошо масштабируются.  

• Важно учитывать личные предпочтения и опыт при выборе базы данных.  

• Выбор базы данных зависит от конкретных задач и требований.  

• Выбор технологий и баз данных зависит от требований и нагрузок.  

• Важно объяснить, почему выбраны определенные технологии и базы данных.  

• Рекомендуется читать книги, такие как "Кабанчик", для глубокого понимания темы.  

• Можно купить только интервью без курса, заполнив заявку в боте или написав менеджеру.  

• Менеджер поможет с оформлением и ответит на все вопросы.  

• Вопрос о проектировании чата, аналогичного Slack, и выборе хранилища для сообщений.  

• Доставка сообщений: Kafka, веб-сокеты, шардирование клиентов по бэкендам, персистентные очереди.  

• Хранение сообщений: обычные базы данных для небольших объемов текста, ссылки на вложения.  

• Чаты требуют тщательного проектирования и оценки пользователей.  

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

• Рекомендация книги "Системный дизайн интервью" Алекса Ксузу.  

• Возможность приобретения практики без курса.  

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

• Бесплатная сессия с ментором для новых участников.  

• Призыв к оценке вебинара и переходу на лендинг.  

• Подарок в виде бесплатной сессии с ментором для новых участников.  

• Рекомендация книги Алекса Ксузу для подготовки к собеседованию.  

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

• Призыв к подписке на канал и лайки.  

• Завершение вебинара и благодарность участникам.