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

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

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

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

Вопросы смело сможете тоже задавать по ходу - мы не на контрольной) Общаемся в формате 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🎁

Мы следим за трендами👀

Поэтому тоже делимся итогами года в канале👍

Говорят, это был год кармы... Как вы там, живы?)) Мы не специалисты по карме, а вот в нашем комьюнити и онлайн школе год прошел очень успешно!

Спасибо, 2024:

✔️ + 934 новых ученика

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

✔️получили награду от Stepik (Специальный приз от маркетинга)

✔️ обзавелись новыми партнерами (уже сделали выплаты и расширяем базу партнеров)

✔️ провели коллаборацию с организаторами конференции OPEN API 2024 ЭВОЛЮЦИЯ и подарили билет на конференцию нашей ученице

✔️ запустили воркшопы в закрытой группе (уже провели 4), получили много обратной связи — вам зашел такой формат, будем продолжать

Сделано много, впереди еще миллион идей и целей для достижения успеха!

Благодарим каждого из вас, что с нами на этом пути, доверяете нашим продуктам и разделяете наши ценности❤️

Давайте пошумим🔥

Как ваш год прошел? Делитесь успехами или факапами, тут же все свои👇

Не заскучали под ёлкой?

Предлагаем провести новогодние каникулы с пользой — открываем БЕСПЛАТНЫЙ демо-доступ на 5 дней к 4 урокам курса по API.

1️⃣ Синхронные и асинхронные запросы - в чём разница?

2️⃣ Асинхронное HTTP API - Callback, Polling, Long Polling

3️⃣ Webhooks

4️⃣ WebSocket, Server Sent Events

Узнаете, как внедрить асинхронные API (HTTP Long Polling, WebSockets и SSE) в свои проекты

Переходите по ссылке
👉https://stepik.org/a/175243?utm_medium=tg

Раздел 9 - Event-based▶️Уроки 9.1 — 9.4

Спасём ваши праздничные будни) Делитесь с друзьями/коллегами!

И не благодарите😉

Поезд уходит...😱

Демо-доступ к 4-м урокам Раздела 9 - Event-based курса по API истекает СЕГОДНЯ⏰

Успели изучить?

Доступ по ссылке
👉https://stepik.org/a/175243?utm_medium=tg

Раздел 9 - Event-based▶️Уроки 9.1 — 9.4

Если есть какие вопросы по урокам - пишите в комментариях, обсудим👇

Маркетинг от Бога😂😂

Но, курс имеется - записывайтесь)

✅ Курс Проектирование архитектуры и интеграций (API / брокеры) сервисов: Тариф С поддержкой наставника

P.S. Нужно пользоваться моментом😎