У кого было?😂

Мы вас понимаем)

Бронируем пятницу 13-го🔥

К новому воркшопу готовы?

Тема: Концепция продукта: от User Story к User Story Mapping
Дата: 13.12.24 в 19.00 по мск
Формат: онлайн-трансляция в закрытом чате

Что изучите за 2 часа?

❗️ Научитесь быстро формировать концепцию продукта, которую поймут и заказчики, и команда: от сырых идей к структурированной карте ценности.

Что будет полезного?

✔️поймете, как правильно писать User Stories, чтобы они отражали реальную пользу для бизнеса и пользователей

✔️ освоите User Story Mapping — технику, которая помогает создать визуальную карту продукта, выделить MVP и разложить функциональность по итерациям

Короче) Материала много - приходите на прямой эфир, сможете в процессе задавать уточняющие вопросы.

Кто еще не в нашем закрытом чате и хочет присоединиться к воркшопу?
👉Ставьте + в комментариях, добавим.

А вы готовы к воркшопу?

Мы - ДА🔥

Написали для вас полное руководство по User Story для чайников!

Изучайте и погружайтесь в тему перед практикумом🔥

❗️13 декабря в 19.00 (мск) в ЗАКРЫТОМ ЧАТЕ❗️

👉https://dzen.ru/a/Z1roWFjRrwS34X2R

Накидайте 🔥, кто ждет воркшоп!

Получили награду от Stepik🔥

Приятно, конечно) Я — не мастер речей, не готовился даже) Дедлайн горел на проекте - вы меня поймете😅

Рады быть полезными для своего комьюнити, для каждого, что хочет попасть в сферу IT и строит свою карьеру в этой нише 🚀 Это наша общая победа!

Благодарю за поддержку и доверие нашему обучению❤️

Город засыпает…

И пошла жара 🔥😅

Ребята, вы - крутые😎

Ближе к воркшопу начинается движ, активно готовимся принимать контент!

Вопросы смело сможете тоже задавать по ходу - мы не на контрольной) Общаемся в формате win\win.

До встречи на эфире в 19.00🔥

Было такое?😂

Делитесь опытом, тут все - свои😉

С началом рабочей недели, друзья🔥

Вы просили — мы сделали!

Готовы к погружению в брокеры сообщений?🔥

❓ЧТО — Воркшоп "Брокеры сообщений: основы и интеграция с Apache Kafka
❓ГДЕ — Закрытая группа
❓КОГДА — 19 декабря в 19.00 мск

Покажем способ облегчить интеграцию сервисов в распределённой архитектуре с помощью Kafka. Это один из самых мощных инструментов для асинхронной коммуникации и event-driven подхода.

Что вас ждет?

✔️ разберём базовые концепции Kafka: топики, партиции, продюсеры, консюмеры (не волнуйтесь, все объясним максимально простыми словами)

✔️ научимся грамотно проектировать интеграции: от формата сообщений до стратегии хранения и т.д.

До встречи 19 декабря!

По традиции)))) Чтобы попасть в Закрытую группу для воркшопов (странно, что вы еще не там) — ставьте + в комментариях👇

Контрольный прогон перед воркшопом🔥

Вы же в теме брокеров?

Написали полезную статью: "Брокеры сообщений: основы и интеграция с Apache Kafka".

— что такое брокер сообщений

— как их использовать

— примеры интеграции через брокер

— почему именно Kafka

Изучайте статью и делитесь своим опытом работы с брокерами сообщений🔥

✅ Воркшоп 19 декабря в 19.00 (мск) в ЗАКРЫТОМ ЧАТЕ

Читаем тут 👉https://dzen.ru/a/Z2KP0k_qQwFmhJ4e

Накидайте 🔥, кому актуальна тема брокеров.

P.S. Делитесь с коллегами и давайте дискутировать - ждем вас в комментариях👇

Подготовьтесь к Новому Году правильно🚀

Новогодний портал @openstudyit открыт🎄

Искренне считаем, что лучшая инвестиция для вашего успешного будущего - это знания.

Впереди новогодние каникулы: "Один дома", "Гарри Поттер", оливье, посиделки у ёлки с близкими❤️ Когда обязательная программа будет пройдена еще останется кучу времени на изучение новых навыков, которые позволят вам получить более крупные проекты и дополнительный доход!

🎁 Мы дарим вам праздничный промокод на все наши флагманские продукты: NEWYEAR2025 (срок действия - 31.12.2024)

✔️ API: Тариф Стандарт (без обратной связи)

✔️ API: Тариф С поддержкой наставника

✔️ API: Тариф Карьера в IT (с обратной связью и блоком "Карьера")

✔️ Курс Системный анализ по-взрослому

Цены и тарифы на курсы в новом году будут пересматриваться... Кто хотел прийти к нам учиться и откладывал - это время настало😉

Делитесь этим постом с коллегами/друзьями - будем рады новым ученикам и участникам нашего комьюнити👍

P.S. Если приведете на курс друга - сделаем индивидуальную скидку, пишите в личку Глебу Учителю👉 https://t.me/glebteach_bot

Интересная задача по проектированию Kafka + ПОДАРОК для вас 🎁

Контекст
Представьте, вы проектируете микросервисное приложение для онлайн-магазина, в котором есть несколько бизнес-сущностей:
Заказы (Orders) — создание, обновление, отмена заказа.
Оплаты (Payments) — подтверждение, отмена, возвраты по оплатам.
Уведомления (Notifications) — рассылка писем, SMS и push-сообщений пользователям.
Каталог (Catalog) — обновление информации о товарах (цены, наличие, описание).
Аналитика (Analytics) — события просмотра товаров, клики, метрики работы пользователей.

Требования

Надёжность: нельзя потерять важные события (заказы, оплаты).
Масштабируемость: система должна выдерживать пиковые нагрузки (распродажи и т.п.).
Гибкость: возможность легко добавлять новые типы событий без переделки всей архитектуры.
Отслеживание порядка: изменения в заказе или платеже должны обрабатываться в строгом порядке для одного и того же order_id или payment_id.

Вопросы к вам

1️⃣ Как разделить события по топикам? Рассматривать ли один общий топик для всех событий, или сделать отдельные топики под заказы, оплаты, уведомления и т.д.? Почему именно так?

2️⃣ Как выбрать ключ (partition key)? По каким полям будете партиционировать: order_id, payment_id, user_id или другим?

3️⃣ Какую гарантию доставки применять?
At-most-once, At-least-once или Exactly-once? Где это критично и почему?

Пишите ваши ответы и обоснование в комментариях👇

Первые 5 человек, кто даст наиболее развёрнутый и правильный ответ, получат подарок от нас🎁

Kafka для онлайн-магазина: решение❗️

Условия задачи ищите👉 ТУТ.

1. Разделение топиков

Самый надёжный способ — отдельные топики под каждый домен: orders, payments, catalog, notifications, analytics.

Так мы сможем:
— гибко настраивать число партиций и репликаций под нагрузку конкретного домена (например, у заказов обычно выше поток)

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

— обеспечивать высокую отказоустойчивость: сбой или перегрузка в одном топике не влияет напрямую на другие

2. Ключ (Partition Key)
Чтобы сохранять порядок внутри одного объекта, ключ привязывают к ID этого объекта — order_id (для заказов), payment_id (для оплат).

— Если мы случайно используем, например, user_id вместо order_id, у одного пользователя могут быть несколько заказов, и их события перемешаются в одной партиции. Это нарушит требование «строгого порядка по заказу».

— Для уведомлений можно использовать notification_id (если важен порядок по конкретному уведомлению) или user_id (если важнее держать сообщения одного пользователя в одной партиции).

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

3. Гарантия доставки

Чаще всего основная практика — At-least-once: события не теряются (в случае сбоя они переотправятся), но могут дублироваться. Такие дубли легко отсеять в сервисе (например, по ID события).

— Exactly-once (строго один раз) настраивается через транзакции в Kafka (idempotent producer, transactional consumer). Это более сложно и “дорого”, поэтому используют обычно там, где недопустимы дубли (например, в финансовых расчётах).

— At-most-once подходит, если потери событий не страшны (часть аналитики). Однако для важных доменов (заказы, оплаты, каталог) такой вариант рисковый.

❗️Нюансы, о которых лучше не забывать

1️⃣ Один общий топик для всего удобен «на бумаге», но на практике превращается в «бутылочное горлышко» и усложняет масштабирование.

2️⃣ Чрезмерное дробление (например, «orders.created», «orders.updated», «orders.canceled» отдельными топиками) может быть оправдано, если система очень большая и это действительно нужно для отдельных микросервисов. Но чаще достаточно одного топика на «orders» с указанием типа события.

3️⃣ «Exactly-once везде» звучит идеально, но реализация сложна: нужно аккуратно настроить транзакции, а это повышает нагрузку и сложность.

4️⃣ Можно делать ключ = session_id для заказа или оплаты, однако если это не 1:1 с order_id/payment_id, порядок внутри одного заказа может пострадать.

В итоге оптимальное решение:

✔️ Чётко разбитые топики (orders, payments и т.д.)

✔️ Ключи по сущностям (order_id, payment_id...)

✔️ Гарантия доставки at-least-once (самый частый баланс между надёжностью и сложностью).

Если у вас есть опыт (или «шишки») в настройке Kafka — обязательно поделитесь в комментариях👇

Ребята, кто описал решение задачи в комментариях — ответы верные, принимаются👍
Благодарим за активность! Проверяйте личку - направили в подарок полезные гайды по API🎁