Какие термины применимы для горизонтального масштабирования?

Давай разжую эту тему про горизонтальное масштабирование, а то звучит страшно, а на деле всё проще, чем кажется. Представь, что у тебя один сервер — это как один здоровенный мужик, который тащит на себе всё: и базу, и логику, и фронт. Он жрёт бензина дохуя, а когда падает, то падает всё разом. Ёперный театр, а не архитектура.

Так вот, scaling out — это когда ты вместо того, чтобы качать этого одного мужика стероидами (вертикальное масштабирование), просто нанимаешь ему в помощь толпу таких же чуваков. Добавляешь новые узлы в систему. И вот тут начинается магия, а точнее, куча терминов, от которых голова идёт кругом. Но мы по порядку.

• Шардирование (Sharding): Это когда ты свою здоровенную таблицу с пользователями берешь и режешь, как пирог. Одному узлу отдаёшь пользователей с user_id от 1 до 1000000, другому — от 1000001 до 2000000 и так далее. Каждый кусок — это шард. Главное, ключ для резки выбрать умно, а то получится пиздопроебибна, где все запросы летят в один шард, а остальные прохлаждаются.
• Репликация (Replication): А это страховка. Чтоб не было так, что один узел накрылся медным тазом, и данные нахуй пропали. Ты создаёшь его точные копии на других серверах. Одна — главная (пишешь в неё), остальные — её подпевалы (читаешь с них). Отказоустойчивость и скорость чтения — красота.
• Балансировка нагрузки (Load Balancing): Это такой умный диспетчер-хитрая жопа, который стоит перед твоей толпой серверов. К нему приходит запрос от пользователя, а он смотрит, кто из серверов сейчас меньше всего загружен, и швыряет запрос ему. Чтобы не вышло, что один вздрачивается до белой горячки, а остальные бздят в облака.
• Консистентное хеширование (Consistent Hashing): О, это вообще песня для распределённых кэшей вроде Redis. Когда ты добавляешь или убираешь сервер из кластера, этот алгоритм делает так, чтобы переехать пришлось минимальному количеству данных. Без него каждый раз при изменении количества серверов у тебя бы половина кэша летела в пизду, и всё начиналось заново. Выглядит сложно, но идея гениальная.
• Микросервисы (Microservices): Вместо одной жирной монолитной помойки, где всё свалено в кучу, ты делаешь кучу маленьких, независимых служб. Сервис авторизации, сервис платежей, сервис нотификаций. Каждый живёт в своём контейнере и ходит сам по себе. Захотел масштабировать только отправку писем — пожалуйста, запускай ещё десять инстансов сервиса нотификаций. Один упал — остальные даже не чихнули. Но, чувак, доверия ебать ноль между ними, поэтому нужно ещё и грамотно их подружить.
• Очереди сообщений (Message Queues): Типа Kafka или RabbitMQ. Это как буфер, спасающий от цунами запросов. Допустим, пользователь что-то загрузил. Вместо того чтобы обрабатывать это прямо сейчас и тормозить, сервис кладёт сообщение «разберись с этим файлом» в очередь и сразу отвечает: «OK». А где-то там с другой стороны тусуется толпа worker'ов, которые медленно, но верно разгребают эту очередь. Без очередей при пиковой нагрузке всё просто впиздюрит.
• Stateless-сервисы: Святая святых. Сервис, который не помнит, кто ты и что ты делал в прошлый раз. Всё состояние — в cookie, токене или базе. Запрос пришёл на любой сервер — он его обработал и забыл. Такие сервисы масштабировать — одно удовольствие. Добавил ещё десять таких же — и да похуй, на какой из них попал запрос.

Ну и пример, чтобы вообще всё встало на свои места: Раньше у тебя была одна здоровая мамка-база PostgreSQL на сервере за овердохуища денег. Она грелась, тормозила, и все молились, чтоб не легла. А теперь по новой схеме: у тебя кластер. Данные пользователей порезаны на шарды по диапазонам ID (шардирование). К каждому шарду приделано по две-три реплики (репликация), с которых все только читают. А пишут в одну главную. И всё это хозяйство стоит за балансировщиком. Один шард захлебнулся? Реплика подхватывает. Надо больше мощности для чтения? Добавил ещё реплик. Красота, да и только. Главное — не накосячить с архитектурой, а то будет не масштабирование, а одно волнение ебать.