Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
Консьюмер может сам ходить за сообщения в Rabbit MQ. Т.е подключился запросил данные из очереди, завершил выполнение. Но также консьюмер может выполняться как демон, т.е. не завершать выполнение после чтения из очереди, а продолжать ждать новые сообщения
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд. Пс. Лайк и подписка
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
03:00 - Что значит "RabbitMQ сам дёргает получателя?" Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить? Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
Для новичков может и ок но проблем потом будет дофига. Если есть знания по алгоритмам и опыт программирования от года лучше почитать Designing Data Intensive Applications ибо презентация далека от реальности. Может предираюсь)
День добрый! Не совсем понятно к какой части доклада относится ваш комментарий. Основная задача была просто кратко-кратко рассказать о том или ином инструменте. По поводу корректной работы с ними можно отдельные курсы составлять)
Вопрос по постгресу и его возможности использовать json атрибуты. Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями. Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё. Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно. Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато. А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL): 1. EAV (ознакомьтесь с этим методом поподробнее) 2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса. Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
@@Rclass 18:40 есть список фич Redis'а. Однако нет упоминания Redis streams. Поскольку перед тем докладчик делал акцент на сравнении брокеров сообщений и взглянув на дату публикации видео, то мне показалось странным, что стримы не упомянуты, хотя уже давно о них известно)
@@nazarparuna Да, нужно было упомянуть хотя бы. Сам со стримами не работал, в качестве брокера обычно выбираю RabbitMQ. Возможно, про Redis как про брокер сообщений стоит сделать отдельное видео. Так же я говорил о том, что в монге нет транзакций. Их подвезли. Там есть ряд ограничений, но тоже по сути моё упущение.
0:40 RabbitMQ
9:34 Apache Kafka
15:10 Redis
19:30 Memcached
21:19 NuxtJS
25:55 MongoDB
30:33 PostgreSQL
Спасибо, в закреп :)
Eeeeeeeeeeeeee eeeeee eeeeeeetteeeeeee eeeeeee
Очень смешно получилось когда докладчик постиг дзен и стал невидимым на 20:43 секунде 😂
Это новая технология! :)
Закэшировался)))
Немного испугался
особенно смешно то, что он в этот момент как раз говорил про время жизни объекта))
@@Илья-м4н9т garbage collector в действии)
Спасибо докладчику, стояла задача понять отличие RabbitMQ от Kafka - это лучшее русскоязычное видео, поверьте.
Cпасибо :) Стараемся для вас ^_^
Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Спасибо за доверие :)
Докладчик заработал мою подписку на этот канал. Красавчик!
Стараемся :)
Аналогично
А я свою подписку не считаю чем то что можно заслужить, просто дикое спасибо за техничность,наглядность и понятность!
+
Классно, что редис работает пиздец как быстро) спасибо за видео
Господи, как найти работу, чтобы начальник был вот таким грамотным и весёлым дядькой?
Да это не так сложно как вам кажется)
А вообще можно самому стать вот таким "веселым дядькой")
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Спасибо за отзыв, мы старались :)
Считаю, что это лучшая реклама кофе якобс монарх. Большое спасибо, было очень интересно
Спасибо)
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Ура! Рады, что помогли :) Спасибо за отклик :)
Докладчик очень хорошо рассказывает и без воды! Прямо топ! Подписка однозначно!
Спасибо :)
испугался, когда лектор сказал "истекло время жизни" и исчез
Спецэффекты которые мы заслужили ))))
Быстро, понятно, без лишней информации! Спасибо за видо!
Спасибо за отклик :)
Прямо выжимка ценного! Огромное спасибо за такие видео!
Спасибо, стараемся для вас :)
Наконец кто-то объяснил человеческим языком как всё это работает, а не миллионом технических терминов. Спасибо!!
Спасибо, мы старались :)
"Отдай свежатину!". Сердечно благодарю за ролик)
Спасибо большое :)
Спасибо, для знакомства аналитикам и техническим менеджерам - отличный формат.
Спасибо, мы старались :)
Вот прямо классно рассказал! Нужно больше материала:))
Спасибо, стараемся ^_^
Спасибо, спасибо, спасибо! Наконец-то я что-то знаю про брокеры сообщений
Всегда пожалуйста :)
Это именно тот способ изложения инфы, который я хотел услышать!
Спасибо, мы старались :)
Спасибо, очень интересный доклад!
Благодарим вас :)
Отличный видос! Все кратко и понятно. Подписка!
Спасибо, мы старались! :)
Отлично, без пафоса и воды. Четко и понятно!
Спасибо, мы старались :)
Классный обзор
очень крутой выпуск для понимания баз данных неожидал тут Nuxt увидеть) сам пишу на нем
Тут не только о базах, тут в целом по технологиям и решениям)
Чисто отдельная подписка за презентацию:)
Ай спасибо! :)
Нахватался бэкендерских словечек ))
Спасибо, подписался 🔥
Это только начало) Можете начинать собирать словарь)))
@@Rclass Буду выходить с этим словарем в курилку и обсуждать всякие редИсы со взрослыми дядями бэкендерами )
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
День добрый! Не совсем поняли что вы имеете ввиду, но полностью с вами согласны)))
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
Спасибо что смотрите :) Да, ранее уже сообщали :)
Интересно было узнать про PostgreSQL. Спасибо!
Спасибо за отклик, мы старались ^_^
Отличное видео! Большое спасибо!
Спасибо, мы старались
Отличный докладчик👍🏻👍🏻👍🏻
Спасибо! :)
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
Спасибо за уточнение :)
на пальцах и по делу!
Консьюмер может сам ходить за сообщения в Rabbit MQ. Т.е подключился запросил данные из очереди, завершил выполнение. Но также консьюмер может выполняться как демон, т.е. не завершать выполнение после чтения из очереди, а продолжать ждать новые сообщения
Часто реализации только второго варианта встречаются, учтем, спасибо 🙏
Отличнейший обзор, ничего лишнего!
Мы рады что вам понравилось :)
Спасибо большое за это прекрасное видео! 👍
Спасибо, что смотрите)
Четко и по делу, без лишней воды. Вообще красава.
Спасибо, мы старались ^_^
Ахеренный видос, спасибо
Стараемся ^_^
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
Ага, отмечали уже в комментах) В целом надо было примерно прикинуть что это за зверь и чем принципиально от других брокеров отличается.
Истекло время жизни🤣🤣🤣
Так бывает)))
Спасибо! Видео ТОП!!
Спасибо, мы старались :)
Оч крутое видео. Спасибо)
Спасибо, что вы с нами)
Лектор очень крут, спасибо за презентацию
Спасибо, стараемся для вас :)
спасибо, понятно и ёмко
Спасибо, мы старались!
Отличная подача материала, коротко и ясно! Спасибо!)
Спасибо, стараемся ^_^
Спасибо за доклад! В Nuxt при создании SPA понятно, что проблемы с SEO, но при SSR ведь не должно быть проблем
SSR и решает (как одну из) проблему с SEO :)
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
Отличное замечание, учту.
и оффсет это не байтовое смещение
Класс, спасибо!)
Спасибо, мы старались :)
Хороший обзор... Хотелось бы подробнее о RabbitMQ (В частности в Kubernetes, как все работает...)
Спасибо, мы старались! К сожалению, про работу в Kubernetes нам нечего рассказать (
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
40 минут смотрел рекламу Якобс. Чет кофейку захотелось
Сработало! Там еще скотч сантехнический, лейбл только потерялся)
Блин..Тоже что то захотелось...А был в завяске от кофе ((
@@Дмитрийсекрет-н7о так давайте к нам на кофе? У нас кофемашина неплохая и кофе свежий, мы вам такой капучино сварим, ууух!
@@Rclass Classое предложение))))
@@Rclass )))))
Класс! Очень хороший обзор, спасибо!
Спасибо, мы старались :)
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд.
Пс. Лайк и подписка
Интересная идея. Давайте я подумаю над этим. Возможно, сформирую список задач и расскажу например как бы я их решал :)
@@OkulovAnton вот это было бы супер!
за Раббит и Редис спасибооу, также и за Монгу (за инфо, что в ней можно вставлять жабоскрипт-код).
Мы рады, что вам зашло :)
Отличное обзорное видео! Спасибо! Не знал, что в Postgres можно хранить массивы)
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
Лови подписку брат!
Спасибо, мы старались :)
@@Rclass ну тогда ловите подписку братья)
+ respect
Thx for watching :)
Спасибо большое, все очень понятно объясняете. Отдельный лайк за оптимизм 🤣
Спасибо, мы старались :)
Безумно классный рассказчик)) прям хоть под пиво сиди смотри))
Спасибо, мы старались :)
12:27 - как связаны Partition и очередь?
Это одно и то же или нет?
Один Partition = 1 COnsumer. А что с очередями? 1 Queue = 1 Consumer????
Крутой обзор! И канал топчик. Лайк, подписка!
Спасибо, мы старались ^_^
Как ты научился исчезать? 2:41 Сделай следующее видео про это. Типо "невероятно, но факт..." ))))))
ой на 20:41
Отвлекли в середине доклада) пришлось пропасть)
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Писать руками кеширование в мемкеш внутри приложения. Если всё правильно поняли.
@@Rclass я понял. Но я не разработчик, эти жава аппликейшны не я писал.
@@kazakman7772 тогда вряд ли что-нибудь получится(
6:13 Funout ??? Maybe "fanout" ?
:facepalm: fanout естессно)
в MongoDB есть aggregation framework, и аналог join можно сделать, в монго это называется Lookup
Да, действительно. Правда стоит помнить что с распределенными БД этот вариант не работает :)
Бро, спасибо!
Вам спасибо за отклик :) Стараемся ^_^
Вот смотрю я ролик и понимаю, не Монго бд...
Видео потрясающе, спасибо большое!
Спасибо, мы старались :)
Спасибо!
Пожалуйста :) Стараемся для вас!
Шикарно
Спасибо, мы старались!
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
Учтем, обычно работали со строками)
Спасибо
Спасибо, мы старались :)
03:00 - Что значит "RabbitMQ сам дёргает получателя?"
Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить?
Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
Да, слушатель поднимается и работает рядом с producer. Да, если слушатель один и он занят - то сообщения обработаются по очереди, одно за другим)
Отлично, спасибо!
Спасибо, мы старались ^_^
вот это я понимаю экспресс обучение
Быстрее только список ссылок дать)
Хорошо получилось
20:44 - докладчик исчез, надеюсь, он закешировался.
Ахаха) Лучшая шутка про исчезновение, жаль два закрепа нельзя) Спасибо что смотрите)
Как брокер сообщений , очереди на redis сделать?
Добрый день! Подключаете редис и используете)
Непонятно зачем в этот список Nuxt попал)
Там половина не понятно зачем) Дикий компот :) Но вот так попросили осветить)
Для новичков может и ок но проблем потом будет дофига. Если есть знания по алгоритмам и опыт программирования от года лучше почитать Designing Data Intensive Applications ибо презентация далека от реальности. Может предираюсь)
День добрый! Не совсем понятно к какой части доклада относится ваш комментарий. Основная задача была просто кратко-кратко рассказать о том или ином инструменте. По поводу корректной работы с ними можно отдельные курсы составлять)
Вопрос по постгресу и его возможности использовать json атрибуты.
Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями.
Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё.
Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно.
Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато.
А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL):
1. EAV (ознакомьтесь с этим методом поподробнее)
2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса.
Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
@@Rclass почитаю подробнее, спасибо!)
истекло время жизни...жестоко, очень 20:39
Здорово ведёте урок, спасибо!
Спасибо, мы старались ^_^
Забавное совпадение когда лектор исчез рассказывая про TTL для memcached
Магия, не иначе :)
Godlike
Thx)
Докладчик пиздатый чел)
Аееее, спасибо)
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Не очень понятно как связаны кеш и сессии?
@@Rclass извиняюсь, вопрос про сессии только
Что за фокус с исчезнлвением произошел на 21.10-21.16 ?
Это неназванная технология)
@@Rclass а на кого вы учите свою группу ? Админис раторы базы данных ?
Нафига монго если есть редис?
JSON = Головастик, ибо: J=Жаба , SON=сын, а сын жабы = головастик. ЧТД
Интересное мнение, запомним)
что за магия на 20:40 ?
Ловкость рук, монтаж и никакого мошенничества! :)
Столько всего придумано, что вроде не чего не надо, но продолжают и продолжают что то изобретать :-)
Что-то устаревает, что-то становится более востребованным... Не стоит на месте отрасль)
А кофе у вас на полке растворимый или зерновой?
Откроем страшный секрет: там не кофе :) А кофе у нас в целом зерновой и очень неплохой, приходите при случае, мы вас угостим :)
На 20:43 изчезновение. Это какая технология?)
Мы проверяем пока, обкатываем и тестируем. Как только будет готово в прод - обязательно сообщим! :)
у ведущего истекло время жизни
Докладчик отличный
Спасибо, мы старались ^_^
Может всё-таки 1 партишн = 1 консьюмер группа? У нас вроде овер 50 консьюмеров читают из топиков с партиционированием 3
Да-да, всё так, поправили уже раньше :) Спасибо что смотрите :)
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
@@Rclass ну если мне нужен брокер сообщений хороший, неужели самому писать
@@maksimsergeevich5939 тогда используйте конечно)
20:40 Антон, если так по фану использовать кольцо, Назгулы на тебя выйдут быстрее
Ужас! Я буду осторожен! Только никому!
А когда готовился доклад?
Достаточно давно. В открытый доступ попал только сейчас. Часть информации уже не актуальна, часть изменилась. Но нам показалось что стоит оставить.
Если есть какие-то уточнения по изменениям - можете указать комментарием - закрепим :)
@@Rclass 18:40 есть список фич Redis'а. Однако нет упоминания Redis streams. Поскольку перед тем докладчик делал акцент на сравнении брокеров сообщений и взглянув на дату публикации видео, то мне показалось странным, что стримы не упомянуты, хотя уже давно о них известно)
@@nazarparuna Да, нужно было упомянуть хотя бы. Сам со стримами не работал, в качестве брокера обычно выбираю RabbitMQ. Возможно, про Redis как про брокер сообщений стоит сделать отдельное видео. Так же я говорил о том, что в монге нет транзакций. Их подвезли. Там есть ряд ограничений, но тоже по сути моё упущение.
Про kafka consumer groups не рассказал
Да, важное замечание, ранее поправили уже. Но и вам тоже спасибо :)