Источник: Распределенные системы и system design

Когда одной базы уже недостаточно по объёму, чтению и записи, шардирование выглядит неизбежным решением. Но на этом масштабирование не заканчивается — оно только начинается. Как только сообщения распределяются по шардам, приходится отдельно решать проблему порядка, генерации ID, Kafka, WebSocket-соединений и доставки между регионами.

В авторском ролике разбирается system design мессенджера на миллиард пользователей. Требования намеренно ограничены: создать чат, добавить или удалить участника, отправить текстовое сообщение и доставить его в реальном времени пользователям, которые сейчас онлайн. Статусы прочтения, реакции и медиа автор не рассматривает — они могут быть добавлены поверх предложенной архитектуры.

Кому смотреть: backend-разработчикам и тем, кто готовится к system design-интервью, но хочет увидеть не список модных технологий, а цепочку инженерных компромиссов: какое решение принимается первым и какие новые проблемы оно создаёт дальше.

Из этого можно взять в работу: при шардировании сначала зафиксируйте инварианты. В этом дизайне сообщения одного чата должны оставаться в одном логическом потоке, а их ID — возрастать. Именно эти требования определяют и ключ шардирования базы, и распределение сообщений в Kafka.