Медиа и хранилище: разбор по памяти
Промпты на свободное воспроизведение по разборам медиа-хранилища. Сначала восстанови каждый дизайн своими словами — раскол байты/метаданные, пайплайн транскодинга, чанкинг и разрешение конфликтов, долговечность через erasure coding и почта на масштабе — затем открой и сверься.
Воспроизведение бьёт перечитывание. На каждый промпт восстанови полный дизайн по памяти — поток данных, раскол, отказ, что он избегает — прежде чем открыть образец. Усилие пересборки архитектуры и заставляет её закрепиться.
Восстанови каждый дизайн, не подглядывая: как раскалываются пути записи и чтения YouTube, что производит транскодинг и почему, как Drive двигает наименьшие байты и разрешает конфликты, как объектное хранилище дёшево достигает одиннадцати девяток и как почта масштабируется партиционированием всего на пользователя.
- 01Восстанови два пути YouTube и правило, что правит обоими.
- 02Почему транскодинг производит лестницу сегментированных рендиций плюс манифест?
- 03Как Drive двигает наименьшие байты и как разрешает конфликтные правки без потери данных?
- 04Как хранилище как S3 дёшево достигает ~11 девяток долговечности и где живёт согласованность?
- 05Как масштабируется почта Gmail и назови два решения по тяжёлым байтам и структурированному состоянию.
Если ты смог восстановить каждый дизайн по памяти, держишь спину юнита. YouTube раскалывает async путь записи (загрузка прямо в объектное хранилище, транскод в сегментированную лестницу рендиций + манифест ради adaptive bitrate) и быстрый путь чтения (зритель→CDN), держа API на пути управления и делая счётчики просмотров eventually consistent. Drive двигает наименьшие байты через адресацию по содержимому (delta-синк + дедуп) и никогда не перезаписывает — цепочка версий ловит конфликты, разрешаемые конфликтными копиями. Объектное хранилище дёшево достигает ~11 девяток с erasure coding (10+4 ≈ 1.4× vs 3× репликация) для холодных данных, держит согласованность в сервисе метаданных и использует multipart upload для огромных объектов. Почта партиционирует всё по пользователю, отвергает спам на приёме, дедуплицирует вложения в объектном хранилище, обслуживает поиск из инвертированного индекса на пользователя, моделирует метки как many-to-many оверлей и синкает инкрементально через журнал изменений. Единая нить: отделяй тяжёлые байты (объектное хранилище, дедуплицировано, отдача с CDN) от структурированного состояния (метаданные, индексы, версии, журналы изменений) и трать бюджет согласованности лишь там, где человек заметит.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.