Daria Motorina

Чуть-чуть не изучили вопрос.

Если вы через уязвимость получите хэши паролей, вы не будете знать первоначальный пароль, верно? и не сможете его использовать в качестве ключа.
При этом вы так же не знаете, как формируется ваш хэш пароля. И в этом случае ,как минимум то, что вводит клиент - неизвестно, если вы не знаете исходный код и не внедряетесь внутрь системы. А мы то знаем, что в 95%+ пользователь использует одни и те же пароли везде. И тут мы сохраняем пароль пользователя до более серъезного взлома.

Да. Для этого в каждом password hash есть информация об алгоритмах, соли, количестве итераций

Например: sha1$15000$mysalt$<результат хэша>, bcrypt$3$...

В коде появляется список хэшеров, хэш сплитится по символу (например $) и по алгоритму подбирается хэшер. Он занимается дальнейшей обработкой. Плюс есть дефолтный хэшер, который используется для всех новых паролей.

Если у тебя сейчас все хэши в одном алгоритме, то задача простая — добавить префикс из того самого sha1$15000$mysalt$

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

Если Вы используете MySQL 8.0 и старше, можно написать такой запрос:

select *
from (
  select
	clients.*,
	groups.title `group`, 
	row_number() over (partition by clients.id order by clients.id) rn -- order may be different
  from clients
  join `groups` on groups.id = clients.group_id
) client_groups
where rn < 10

MySQL fiddle

В первую очередь брокеры нужны для балансировки нагрузки и увеличения надежности и скорости работы системы в целом.

В вашем приведенном примере приведен способ уведомления клиента о каком-то событии. Например о том, что его заказ обработан, отправлен, доставлен и т.д. Событий может быть много и их источники могут быть различными.
Например у вас может быть интеграция со сторонней системой логистики. А еще с 10 разными системами оплаты.
Еще есть маркетинг, который тоже хочет отправлять массовые рассылки.
Получается, что под каждый случай вам прийдется хранить информацию о письмах и статусах. Но даже проблема не в этом, проблема в том, что каждое событие имеет разный приоритет и разную ценность.

В случае работы с сайтом у вас будет 1 воркер, который будет просто сканировать таблицы на поиск неуведомленных пользователей. Если у вас будет 2 воркера, надо делать систему блокировок и т.д. Т.е. мы упираемся в проблему масштабирования. Для решения задачи разной скорости уведомлений, вы построите систему приоритетов или будете делать разные таблицы с разными воркерами. Это все будет работать, но нагрузка на базу будет серьезной и она будет увеличиваться с ростом пользовательской базы. Опять вы упретесь в тормоза.
Опять же есть письма, которые должны быть доставлены немедленно, вроде подтверждений аккаунта, смены пароля и т.д. Еще одна таблица? Дополнительный приоритет? Может так произойти, что вы некоторые пользователи вообще никогда не получат писем и уведомлений. Прийдется придумывать способ контроля.
Я уж не говорю о куче кастомных воркеров под каждую ситуацию. И их будет с десяток, не меньше.

Очереди решают, т.к. можно сделать их несколько и на для каждой настроить определенное количество абсолютно одинаковых воркеров. Пример с поллингом отвратителен и сейчас никто так не делает, а с очередями делают так.
У вас может быть цепочка из нескольких воркеров, когда результат работы одного помещается в очередь.
Например, когда надо сначала достать данные из нескольких разных медленных систем, отрендерить в шаблон, а потом отправить письмо. Сборка, рендеринг и отправка - три разные компонента, последние два из которых, можно активно переиспользовать для других целей изменяя лишь конфигурацию времени исполнения.
При таком подходе проще развивать кодовую базу, исправлять ошибки, т.к. они изолированы в одном месте, а не разбросаны по всей системе. И да, косяк в "горячем" модуле вы заметите немедленно. А самое прикольное то, что ваш косяк, пользователи и не заметят, для них это будет выглядеть как простая задержка, а у вас будет время на то, чтобы исправить ошибку. Сообщения посидят в очереди и все.
Но это еще не все, ваши воркеры могут быть написаны на разных языках программирования. Например пользователь может загружать фото на сайт на PHP, объекты распознаваться на Python, видео рендериться на Rust, а отправка писем может быть на Go. И такой подход может подойти для сложных систем с распределенными командами и различным уровнем компетенция в применяемых технологиях. Специалистов превосходно владеющих всеми приведенными технологиями просто единицы, и поверьте, они решают задачи совершенно другого уровня.

Очередь это буфер, куда задачи попадают с разной скоростью, а из него сливаются равномерно, по мере готовности «рабочих» их принять.

В вопросе описана так-себе реализация с поллингом очереди. Различие без-очереди и с-очередью — в направлении инициативы:

• без очередей «рабочий» опрашивает базу снова и снова: «есть чё?». Это как из браузера ajax'ом пинговать сервер раз в секунду в поиске сообщений. Работает, но такое себе..
  
• с очередью инициатор процесса – брокер. Это брокер передаёт очередную задачу на исполнение первому освободившемуся «рабочему».
  

а брокеры очередей в случае падения теряют данные.

Это неверно.
Брокеры бывают разные и настроены по разному.
В общем случае, брокер - вещь гораздо более легковесная, чем база данных. Гораздо проще масштабируется и кластеризируется, чем база данных. Да и работает в основном гораздо быстрее.

Но в вашем случае - отправлять уведомление пользователю, это не совсем задача для брокеров. Брокеры в основном нужны для общения микросервисов/программ друг с другом.

Ну это не Линукс зависает, а вы неправильно конфигурируете виртуальную машину.
В сообщении вполне ясно сказано, что диск переполнен, нет места на диске.