Мессенджер на 1 млрд пользователей - system design

Дизайн мессенджера на млрд и более пользователей по всей планете. Низкий латенси в пределах одного региона и чуть выше между регионами. Канал в телеграме: https://t.me/distributed_system_design Платный курс с роадмапом: https://t.me/tribute/app?startapp=sUJx 1-1 консультация / мок-собеседование: ser.sysd.channel@gmail.com По другим вопросам: ser.sysd.channel@gmail.com Тайм-коды: 00:00 Вступление. 00:29 Требования к системе. 01:39 Дизайн системы (немасштабированное решение). 08:13 Масштабирование, 1 - база данных. 09:19 Выбор базы данных. 09:38 Шардирование базы данных. 10:08 Message Id внутри чата - как генерировать. 12:38 Резюме: бд выбрана, пошардирована, схема данных описана. 13:04 Масштабирование, 2 - kafka и consumer. 14:07 Проблема с кол-вом партиций в kafka и ее решения. 15:39 Масштабирование, 3 - connection server. Схема с Redis-ом. 17:55 Проблемы схемы с Redis-ом. 18:36 Альтернатива схеме с Redis-ом. Кастомное решение. 20:37 Схема с Redis-ом проще и, возможно, более предпочтительна. 20:52 Гео-распределенность. Проблематика. 21:44 Реализация гео-распределенности. Простой, но неудачный вариант. 23:40 Более удачная реализация гео-распределенности. Чтение сообщений/получение уведомлений из другого региона. (Про запись см. комментарий в конце видео) 28:15 Hub-регион. 29:39 Внутрирегиональные чаты хранятся лишь в одном регионе. Межрегиональные - в регионах участников чата. 30:25 Hub - не бутылочное горлышко. 31:13 🏁 Резюме: описание всего флоу. 35:03 Комментарий 1: миграция юзеров между регионами. 36:20 Комментарий 2: запись в другой регион. 37:19 Комментарий 3: схема без веб-сокетов и её преимущества. Мысль про telegram. Важные комментарии: Выбор бд 09:20 забыл сказать о том, что предпочтительна база данных с LSM движком хранения (для большего write throughput). Сказал только о безлидерной репликации. Cassandra подходит по обоим критериям. Шардирование через Consistent hashing в Cassandra - тоже хорошо, тк дополнительно увеличивает доступность. Чтение пропущенных сообщений, когда юзер зашел в сеть: Юзер делает запрос getMessages(chatId, lastMessageId, pageSize), где lastMessageId - последнее сообщение в чате на клиенте. MessageId в чате строго возрастают, поэтому такая пагинация валидна. В этот же момент юзер слушает live-апдейты по веб-сокету. Минус: для одного юзера идем в несколько шардов базы данных (чаты могут жить на разных). Альтернатива: 37:19 Комментарий 3. Латенси на чтение: низкое даже для чатов из других регионов, тк они реплицированы в регион юзера. Канал в телеграмме (есть чат): https://t.me/distributed_system_design