Автор: Listen IT · YouTube · статья Highload Today

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

Ролик Listen IT даёт короткое введение в оба подхода. Реплики можно использовать для резервирования и переноса части чтений с основного узла. Шардинг нужен, когда объём данных или нагрузка перестают помещаться на одном сервере: система выбирает shard key и по нему определяет, где должна находиться каждая запись.

Разница становится особенно важной при отказе. Реплика может заменить основной узел только при наличии механизма failover. У шарда замены вообще может не быть, если его не реплицировать отдельно. Поэтому production-система часто сочетает оба подхода: данные разделены на шарды, а внутри каждого шарда есть несколько копий.

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

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

Автор: Сергей Петренко · HighLoad++ 2022

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

В докладе Сергея Петренко команда Tarantool пробует сочетать оба режима: использовать Raft и синхронную репликацию, но сохранять возможность вручную ослабить ограничения во время аварии. CAP-теорему такая настройка не отменяет. Она лишь переносит последствия решения на тот момент, когда связь восстановится и две части кластера попытаются снова работать вместе.

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

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

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

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

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

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

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