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

Новогодний портал @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. Нужно пользоваться моментом😎

Как вырасти системному аналитику?

Брать новые задачи на проектирование интеграций API.

Это только звучит серьезно и сложно. А на самом деле интересно! И приносит пользу бизнесу, а вам карьерный рост и увеличение дохода👍 Перспективы роста карьеры обсуждали ТУТ.

#ученикиговорят

Уложил у себя разрозненные знания о проектировании API, баз данных. Узнал о принципах проектирования систем.

Короткие уроки, обучающая информация дана с примерами, переводом терминов.

Как же нам приятно наблюдать ваш рост!

Схема простая: изучаете новые навыки▶️ прокачиваете свои скиллы▶️ растёте в IT🚀

У нас есть курс, как и по системному анализу, так и по проектированию API.

✅ обратная связь от преподавателя по заданиям, много практики

✅ доступ к материалам и вашему личному кабинету ПОКА бессрочный

Обязательно делитесь обратной связью. Картинки, схемы, таблички - принято👍 Мы ведь растём вместе с вами!

Какой формат обучения вам ближе: видео, текстовые материалы, личные встречи и т.д.? Делитесь в комментариях👇

❗️Attention❗️

На связи Глеб Учитель👍

У вас есть веб-приложение для бронирования номеров в отелях. Каждый номер (Room) имеет свой ID и информацию о доступности на определённые даты. При оформлении брони пользователь указывает дату заезда и дату выезда.

Условие:

Если два (или более) пользователя одновременно пытаются забронировать один и тот же номер на пересекающиеся даты, система должна корректно обработать эту ситуацию — не допустить “двойного бронирования”.

⁉️Задача:

— Как вы спроектируете API, чтобы избежать "double booking"?

— Кратко опишите, как будете обрабатывать одновременные запросы на бронь.

За самые креативные, развернутые и правильные ответы отправлю подарок в личку🎁

P.S. Еще не придумал, что подарю... точно что-то полезное👍 У нас много ценных материалов.

Проверьте себя👇

Ответ на ЗАДАЧКУ.

Как спроектировать API бронирования номеров без «double booking»?

1️⃣ Создание брони (POST /api/bookings)
▪️Принимает room_id, start_date, end_date, user_id.
▪️Перед сохранением система проверяет, есть ли уже пересечение дат по room_id.
▪️Если занято → ответ 409 Conflict. Если свободно → 201 Created и информация о брони.

2️⃣ Редактирование брони (PATCH /api/bookings/{id})
▪️Аналогично: если меняются даты, проверяем пересечение. При конфликте тоже 409 Conflict.

3️⃣ Ответы API
▪️Успешное создание: 201 Created + JSON с деталями брони.
▪️Конфликт дат: 409 Conflict + сообщение вида { "error": "Room is already booked for these dates" }.

4️⃣ Защита от одновременных бронирований
▪️Даже если два запроса приходят одновременно, финальная проверка (внутри бэкенда) не даст создать две пересекающиеся брони.
▪️Реализовать это можно транзакцией или другим механизмом конкурентного доступа (но клиенту достаточно знать, что получит 409 Conflict при коллизии).

✨На уровне API всё сводится к двум моментам: обязательная проверка занятости при создании/обновлении и правильные коды ответа (особенно 409) при конфликте.

Благодарю всех за активность👍 Ответы порадовали)

Ждите подарки🎁 в личку от нашего менеджера.

Все мы немного Олег🔥

Гайз, есть возможность попасть на конференцию🔥

15 февраля состоится онлайн-конференция для SА\BA, состоящая из блоков: ТECH SKILLS, ИБ и AI.

Analyst Marathon #12. ТECH SKILLS, ИБ и AI в работе BA/SA

Что будет на мероприятии:

✔️Математический аппарат в работе аналитика
✔️Как аналитики стали кодить АРI и что нового про АРI узнали
✔️Как брокеры НЕ гарантируют доставку сообщений
✔️ИБ в работе аналитика: как собирать требования и готовить модель угроз
✔️Нестандартные AI Use Case в работе СА
✔️Программа

Формат: онлайн

Дата: 15 февраля (с 10.00 до 17.00 мск)

Цена: 3100-3800 RUB (только до 9 февраля) + видеозаписи, презентации, материалы докладов

Представление докладов и общение со спикерами в чате конференции.

Регистрация физ лиц 👉 ЗДЕСЬ.

Среди своих учеников проведем розыгрыш 1 билета от нас🔥

Консультация с Глебом Учителем — готовы?

На связи Глеб. У нас есть такая опция —люблю с вами общаться лично👍

Вот какие результаты после консультации у Надежды:
#ученикиговорят

Понравилось, что ты очень бережно и аккуратно подошел к моей проблеме самозванца. И в целом по шагам предложил отличные идеи. По резюме уже сделала несколько правок.

Да, мы успеваем много вопросов закрыть за одну консультацию и ученики еще потом пишут спустя время про свои успехи👍

Предлагаю честную сделку😎 Условия простые:

— вы отмечаете своих друзей в комментариях под этим постом (они все должны подписаться на канал)

— 1 февраля я рандомно выберу из ваших комментариев одного победителя и с ним проведем личный созвон

Готовьтесь к консультации) Погнали👇

Это то, о чем мы уже говорили👆

Глеб на связи с вами и после консультации: мы ценим открытость и поддержку в комьюнити, радуемся вашим успехам❤️

#ученикиговорят

У вас прекрасный курс про интеграцию, сама прохожу и всем рекомендую.

И мы благодарим за доверие и теплую обратную связь!

❗️Это важная информация. Мы с командой сейчас пересматриваем тарифную сетку, начинку курса, доступы к платформе и ценовую политику.

Кто заходит сейчас - у вас остаются те условия, которые действуют на момент покупки обучения.

У нас есть секретный промокод только для Своих (скидка 20%)🤫 Его срок истекает сегодня 31 января.

Если кто сомневался или "кусались" цены - это ваша возможность зайти выгодно на обучение! Мир любит смелых - принимайте решение быстро⏰

Пишите в личку 👉 https://t.me/glebteach_bot кодовую фразу "Хочу секретный промокод" и сможете им воспользоваться.

Подтверждаю. Курс действительно просто супер. Невероятная концентрация полезноты в одном месте.