🎙Продолжение. На связи Глеб Учитель, в этих двух аудио, делюсь мыслями на хайповые темы, которые звучат в информационном поле IT.
В подкасте:
💥 Главная причина фейлов ИИ в реальной разработке: отсутствие контекста, размазанные знания и противоречия стейкхолдеров.
💥 Грань делегирования: какую рутину я на 100% отдам ИИ, а какие задачи никогда не доверю.
💥 Цена ошибки: почему ИИ лишь рассчитывает вероятности, а инженер отвечает за принятые решения ДЕНЬГАМИ И РЕПУТАЦИЕЙ.
Предлагаю послушать всем продактам, бизнес-аналитикам, TPM и архитекторам, чтобы перестать заучивать сотни промптов и наконец сфокусироваться на понимании физики работы систем.
Делитесь, что думаете на этот счет, коллеги?
Еще интересные материалы:
👉 «Почему ваш ИИ — гениальный стажер, а не сеньор-архитектор»
👉 Разбор практики: «Гонка вооружений: ИИ-рекрутер против кандидата с ChatGPT или 9 кругов ИИ-собеса»
Мы в МАКС
В подкасте:
💥 Главная причина фейлов ИИ в реальной разработке: отсутствие контекста, размазанные знания и противоречия стейкхолдеров.
💥 Грань делегирования: какую рутину я на 100% отдам ИИ, а какие задачи никогда не доверю.
💥 Цена ошибки: почему ИИ лишь рассчитывает вероятности, а инженер отвечает за принятые решения ДЕНЬГАМИ И РЕПУТАЦИЕЙ.
Предлагаю послушать всем продактам, бизнес-аналитикам, TPM и архитекторам, чтобы перестать заучивать сотни промптов и наконец сфокусироваться на понимании физики работы систем.
Делитесь, что думаете на этот счет, коллеги?
Еще интересные материалы:
👉 «Почему ваш ИИ — гениальный стажер, а не сеньор-архитектор»
👉 Разбор практики: «Гонка вооружений: ИИ-рекрутер против кандидата с ChatGPT или 9 кругов ИИ-собеса»
Мы в МАКС
🔥5
Как один REST-запрос может положить банковскую систему. И почему Kafka - это не «модно», а жизненно необходимо.
Разберем показательный кейс: грань между «красивым Swagger от нейросети» и реальным боевым продакшеном.
Если попросить ChatGPT спроектировать API для выдачи кредита, он за 30 секунд выдаст аккуратную документацию. На бумаге всё выглядит стерильно - классическая цепочка из последовательных синхронных REST-вызовов:
1. POST /applications - создание заявки
2. POST /scoring - скоринг клиента
3. POST /accounts/credit - открытие кредитного счета
4. POST /cards/issue - выпуск карты
5. POST /notifications/sms - отправка SMS
6. POST /loyalty/bonuses - начисление приветственных бонусов
7. POST /antifraud/log - фиксация сделки в антифроде
8. POST /crm/update - обновление статуса в CRM
Пока нагрузка околонулевая, а все сервисы живы - схема работает. Но реальный прод всегда бьет по слабым местам.
Что происходит, когда на 6-м шаге падает сервис бонусов?
Синхронный REST запускает эффект домино:
• Деньги с кредитного счета уже ушли клиенту;
• Карта выпущена и активна;
• Сервис бонусов лежит с HTTP 504 Gateway Timeout;
• Запрос завис, а до антифрода и CRM очередь вообще не дошла.
В итоге: транзакция не завершена, данные рассинхронизированы, клиент получил деньги, но система безопасности о сделке даже не в курсе.
Почему так происходит?
Нейросети и начинающие аналитики выбирают синхронный REST просто потому, что это самый частый паттерн в сети. Создается иллюзия полного контроля. На практике жесткая связка превращает падение второстепенного сервиса в катастрофу для всей бизнес-транзакции.
⚙️ Как эту проблему решает брокер сообщений (Event-Driven Architecture):
Главная задача Kafka или RabbitMQ в таком сценарии — изоляция сбоев.
Вместо синхронной команды «сделай прямо сейчас» ядро системы публикует факт: Event: CreditIssued (кредит выдан).
Сервисы получают законное право болеть поодиночке:
1. Критичные шаги (счет и деньги) выполняются в ядре.
2. Второстепенные сервисы (бонусы, CRM, нотификации) подписаны на событие и вычитывают его независимо.
3. Если сервис бонусов упал — он спокойно поднимется через полчаса, дочитает очередь и начислит баллы без риска для основной операции.
Проектировать отказоустойчивые контракты и выбирать между REST, gRPC и брокерами, понимая не просто ЧТО использовать, а КОГДА и ПОЧЕМУ, мы подробно проходим на курсе «Проектирование архитектуры и интеграций сервисов» на Stepik (вводные уроки доступны бесплатно).
👇 Коллеги, сталкивались на проде с падением цепочек синхронных вызовов? Как развязывали — через саги, брокеры или ретраи с таймаутами?
Разберем показательный кейс: грань между «красивым Swagger от нейросети» и реальным боевым продакшеном.
Если попросить ChatGPT спроектировать API для выдачи кредита, он за 30 секунд выдаст аккуратную документацию. На бумаге всё выглядит стерильно - классическая цепочка из последовательных синхронных REST-вызовов:
1. POST /applications - создание заявки
2. POST /scoring - скоринг клиента
3. POST /accounts/credit - открытие кредитного счета
4. POST /cards/issue - выпуск карты
5. POST /notifications/sms - отправка SMS
6. POST /loyalty/bonuses - начисление приветственных бонусов
7. POST /antifraud/log - фиксация сделки в антифроде
8. POST /crm/update - обновление статуса в CRM
Пока нагрузка околонулевая, а все сервисы живы - схема работает. Но реальный прод всегда бьет по слабым местам.
Что происходит, когда на 6-м шаге падает сервис бонусов?
Синхронный REST запускает эффект домино:
• Деньги с кредитного счета уже ушли клиенту;
• Карта выпущена и активна;
• Сервис бонусов лежит с HTTP 504 Gateway Timeout;
• Запрос завис, а до антифрода и CRM очередь вообще не дошла.
В итоге: транзакция не завершена, данные рассинхронизированы, клиент получил деньги, но система безопасности о сделке даже не в курсе.
Почему так происходит?
Нейросети и начинающие аналитики выбирают синхронный REST просто потому, что это самый частый паттерн в сети. Создается иллюзия полного контроля. На практике жесткая связка превращает падение второстепенного сервиса в катастрофу для всей бизнес-транзакции.
⚙️ Как эту проблему решает брокер сообщений (Event-Driven Architecture):
Главная задача Kafka или RabbitMQ в таком сценарии — изоляция сбоев.
Вместо синхронной команды «сделай прямо сейчас» ядро системы публикует факт: Event: CreditIssued (кредит выдан).
Сервисы получают законное право болеть поодиночке:
1. Критичные шаги (счет и деньги) выполняются в ядре.
2. Второстепенные сервисы (бонусы, CRM, нотификации) подписаны на событие и вычитывают его независимо.
3. Если сервис бонусов упал — он спокойно поднимется через полчаса, дочитает очередь и начислит баллы без риска для основной операции.
Проектировать отказоустойчивые контракты и выбирать между REST, gRPC и брокерами, понимая не просто ЧТО использовать, а КОГДА и ПОЧЕМУ, мы подробно проходим на курсе «Проектирование архитектуры и интеграций сервисов» на Stepik (вводные уроки доступны бесплатно).
👇 Коллеги, сталкивались на проде с падением цепочек синхронных вызовов? Как развязывали — через саги, брокеры или ретраи с таймаутами?
🔥7
Дайджест любимая рубрика: ТОП-5 самых полезных постов канала за июль 2026📌
Если вы недавно присоединились к каналу или пропустили что-то в ленте среди рабочих спринтов, ниже материалы, которые вызвали больше всего обсуждений, сохранений и реакций.
Забирайте в закладки, пересылайте коллегам:
🔥 1. Разбор резюме: «Почему вам не звонят после резюме с Kafka?»
Разобрали частую ошибку системных аналитиков: когда в резюме указано «знаю Kafka», а на собеседовании соискатель сыплется на базовом вопросе про консьюмер-группы и гарантии доставки. Внутри чек-лист того, что реально проверяют техлиды.
🧠 2. Про ИИ в работе: «Почему ваш ИИ - гениальный стажер, а не сеньор»
Лидер по репостам.
Почему слепое делегирование архитектуры ChatGPT ведет к багам на проде, и как использовать нейросети для рутины, не теряя контроля над системной логикой и требованиями.
💼 3. Кейс из практики: История и результаты Павла
Рекордсмен по реакциям и огням.
Реальный опыт ученика: как прокачка навыков интеграций и проектирования контрактов помогла преодолеть синдром самозванца, перейти на новый грейд и уверенно общаться с бэкенд-командой.
🎯 4. Мышление аналитика: «Есть одна фраза...»
Короткая заметка, которая срезонировала с десятками коллег.
О маркерах в коммуникации, которые сразу отличают зрелого системного аналитика от того, кто просто перекладывает чужие слова в тикеты Jira.
⚔️ 5. Аналитика рынка: «Гонка вооружений в IT»
В топе по сохранениям и пересылкам в рабочие чаты.
Что сейчас происходит с требованиями к аналитикам: почему «просто писать User Story» уже недостаточно и почему понимание архитектуры сервисов стало обязательным фильтром на входе.
Какую тему копнуть глубже в следующих разборах - напишите в комментариях!
Если вы недавно присоединились к каналу или пропустили что-то в ленте среди рабочих спринтов, ниже материалы, которые вызвали больше всего обсуждений, сохранений и реакций.
Забирайте в закладки, пересылайте коллегам:
🔥 1. Разбор резюме: «Почему вам не звонят после резюме с Kafka?»
Разобрали частую ошибку системных аналитиков: когда в резюме указано «знаю Kafka», а на собеседовании соискатель сыплется на базовом вопросе про консьюмер-группы и гарантии доставки. Внутри чек-лист того, что реально проверяют техлиды.
🧠 2. Про ИИ в работе: «Почему ваш ИИ - гениальный стажер, а не сеньор»
Лидер по репостам.
Почему слепое делегирование архитектуры ChatGPT ведет к багам на проде, и как использовать нейросети для рутины, не теряя контроля над системной логикой и требованиями.
💼 3. Кейс из практики: История и результаты Павла
Рекордсмен по реакциям и огням.
Реальный опыт ученика: как прокачка навыков интеграций и проектирования контрактов помогла преодолеть синдром самозванца, перейти на новый грейд и уверенно общаться с бэкенд-командой.
🎯 4. Мышление аналитика: «Есть одна фраза...»
Короткая заметка, которая срезонировала с десятками коллег.
О маркерах в коммуникации, которые сразу отличают зрелого системного аналитика от того, кто просто перекладывает чужие слова в тикеты Jira.
⚔️ 5. Аналитика рынка: «Гонка вооружений в IT»
В топе по сохранениям и пересылкам в рабочие чаты.
Что сейчас происходит с требованиями к аналитикам: почему «просто писать User Story» уже недостаточно и почему понимание архитектуры сервисов стало обязательным фильтром на входе.
Какую тему копнуть глубже в следующих разборах - напишите в комментариях!
Telegram
API. Архитектура. Веб-сервисы | Глеб Учитель
Почему вам не звонят после резюме с Kafka? Секрет внутри👆
За 1.5 минуты Глеб рассказал:
🔹 почему HR не верит списку ваших умений
🔹 чем резюме с "инженерным мышлением" отличается от "списка слов"
🔹 реальный кейс ученика, который за день до собеса открыл…
За 1.5 минуты Глеб рассказал:
🔹 почему HR не верит списку ваших умений
🔹 чем резюме с "инженерным мышлением" отличается от "списка слов"
🔹 реальный кейс ученика, который за день до собеса открыл…
This media is not supported in your browser
VIEW IN TELEGRAM
👍4🔥1
Тест на инженерное мышление: почему упал прод и произошло двойное списание? 🧠💥
Самые дорогие системные аварии случаются не из-за сложного стека, а из-за одной неочевидной ошибки в логике интеграции.
Ниже классический кейс из реальной практики. Давайте проверим, как вы спроектируете этот узел, а заодно устроим конкурс с полезными призами.
📌 Дано (типичная архитектурная ловушка):
Платежный сервис принимает запрос на оплату, списывает деньги с баланса и отправляет HTTP-запрос во внешний банковский эквайринг.
В «черную пятницу» под нагрузкой эквайринг отвечает с задержкой, и внутренний сервис падает по таймауту (HTTP 504 Gateway Timeout). Аналитик заложил в ТЗ логику: «если получили таймаут, автоматически повторяем запрос каждые 3 секунды до победного».
На тестовом стенде всё работало безупречно. На проде у сотен клиентов произошло двойное (и тройное) списание денег за один заказ.
Разработчики предлагают просто «подкрутить таймауты до 30 секунд и добавить серверов». Но проблема зашита в самой логике взаимодействия.
❓ Вопрос к системным аналитикам и инженерам:
1. В чем фундаментальная ошибка в логике этой интеграции?
2. Какой архитектурный паттерн и механизм нужно внедрить, чтобы списания гарантированно не дублировались даже при обрывах сети и повторных запросах?
Призы:
🥇 Автору самого четкого и аргументированного ответа на выбор:
• Полный доступ к Веб API-симулятору
• ИЛИ большая пицца в ваш офис / домой
📄 Всем, кто оставит свой вариант решения в комментариях я или команда отправим в ЛС PDF-схему правильного проектирования этого шлюза с чек-листом по идемпотентности API.
👇 Пишите ваши гипотезы в комментариях! Итоги подведем в конце месяца (с публикацией победителя и пруфами отправки приза).
Самые дорогие системные аварии случаются не из-за сложного стека, а из-за одной неочевидной ошибки в логике интеграции.
Ниже классический кейс из реальной практики. Давайте проверим, как вы спроектируете этот узел, а заодно устроим конкурс с полезными призами.
📌 Дано (типичная архитектурная ловушка):
Платежный сервис принимает запрос на оплату, списывает деньги с баланса и отправляет HTTP-запрос во внешний банковский эквайринг.
В «черную пятницу» под нагрузкой эквайринг отвечает с задержкой, и внутренний сервис падает по таймауту (HTTP 504 Gateway Timeout). Аналитик заложил в ТЗ логику: «если получили таймаут, автоматически повторяем запрос каждые 3 секунды до победного».
На тестовом стенде всё работало безупречно. На проде у сотен клиентов произошло двойное (и тройное) списание денег за один заказ.
Разработчики предлагают просто «подкрутить таймауты до 30 секунд и добавить серверов». Но проблема зашита в самой логике взаимодействия.
❓ Вопрос к системным аналитикам и инженерам:
1. В чем фундаментальная ошибка в логике этой интеграции?
2. Какой архитектурный паттерн и механизм нужно внедрить, чтобы списания гарантированно не дублировались даже при обрывах сети и повторных запросах?
Призы:
🥇 Автору самого четкого и аргументированного ответа на выбор:
• Полный доступ к Веб API-симулятору
• ИЛИ большая пицца в ваш офис / домой
📄 Всем, кто оставит свой вариант решения в комментариях я или команда отправим в ЛС PDF-схему правильного проектирования этого шлюза с чек-листом по идемпотентности API.
👇 Пишите ваши гипотезы в комментариях! Итоги подведем в конце месяца (с публикацией победителя и пруфами отправки приза).
Web API Симулятор
Web API Симулятор - платформа для практического изучения веб-сервисов и API через учебные сценарии, которые основаны на реальных веб-приложениях. Изучайте облачные приложения, сетевые запросы и интеграции на практике.
То есть выиграть доступ к API-симулятору не мотивирует?😁
П.с. Рад, что активно включились в решение задачи, скрин комментария к посту про конкурс и призы ВЫШЕ👈🏻
П.с. Рад, что активно включились в решение задачи, скрин комментария к посту про конкурс и призы ВЫШЕ👈🏻
😁8
С 100к до 230к за полгода: почему база решает больше, чем «накрученный» опыт 🚀 #ученикиговорят
Получил в личку очень честный и показательный отзыв от ученика. Скрины прикрепил выше, а здесь разберу саму суть, потому что это классический путь входа в профессию со всеми его граблями.
Точка А: «Немного приукрасил резюме, но без понимания было тяжело»
Парень честно признается: на старте попытался «крутануть» опыт. Но собеседования шли со скрипом, когда нет фундаментального понимания, как под капотом ходят данные, любой нормальный техлид раскалывает легенду за пару вопросов.
В итоге позвали в небольшую компанию на 100 000 руб., где пришлось быть и лоу-код разработчиком, и системным аналитиком одновременно.
Что стало переломным моментом?
Парадокс в том, что многие пытаются сразу зазубрить сложные термины из ChatGPT, не понимая физики процесса: как формируется HTTP-пакет, что такое заголовки, где границы ответственности клиент-серверной архитектуры и чем JSON отличается от XML на уровне контракта.
Когда эта картинка в голове сложилась - рабочий опыт начал наматываться в 5 раз быстрее.
Точка Б: 10 собеседований, 2 оффера и выбор в пользу 230 000 руб.
Спустя 6 месяцев реальной практики он снова вышел на рынок. И здесь уже включилась профессиональная зрелость:
1. Один оффер дали прямо на собеседовании со словами: «Документацию не пишем, интеграциями занимаются разработчики, а СА нужен просто чтобы был». Он отказался.
2. Выбрал второй оффер на 230 000 руб. - в команду со сложными интеграциями через Kafka и ESB, где системный аналитик реально проектирует архитектуру и прокачивает хард-скиллы.
Испытательный срок закончился, а задачи по шинам и брокерам он решает уже на уверенном мидл-уровне.
Главный вывод:
Вам не нужно учиться годами, чтобы сделать первый рывок в доходе. Достаточно перестать плавать в базе и научиться говорить с разработчиками на одном инженерном языке.
Нужен личный промо на скидку - пишите в лс: https://t.me/glebteach_bot
💬 Как вы искали свою первую работу в IT — честно признавались, что джун, или приходилось «докручивать» опыт в резюме? Делитесь в комментариях!
Мы в МАКС
Получил в личку очень честный и показательный отзыв от ученика. Скрины прикрепил выше, а здесь разберу саму суть, потому что это классический путь входа в профессию со всеми его граблями.
Точка А: «Немного приукрасил резюме, но без понимания было тяжело»
Парень честно признается: на старте попытался «крутануть» опыт. Но собеседования шли со скрипом, когда нет фундаментального понимания, как под капотом ходят данные, любой нормальный техлид раскалывает легенду за пару вопросов.
В итоге позвали в небольшую компанию на 100 000 руб., где пришлось быть и лоу-код разработчиком, и системным аналитиком одновременно.
Что стало переломным моментом?
«Мне сильно много дала глава самая первая, где объясняется вообще как интернет работает, про SOAP и REST... потом дальше все было легко. Курс мне помог, пусть я и не прошел его весь.»
Парадокс в том, что многие пытаются сразу зазубрить сложные термины из ChatGPT, не понимая физики процесса: как формируется HTTP-пакет, что такое заголовки, где границы ответственности клиент-серверной архитектуры и чем JSON отличается от XML на уровне контракта.
Когда эта картинка в голове сложилась - рабочий опыт начал наматываться в 5 раз быстрее.
Точка Б: 10 собеседований, 2 оффера и выбор в пользу 230 000 руб.
Спустя 6 месяцев реальной практики он снова вышел на рынок. И здесь уже включилась профессиональная зрелость:
1. Один оффер дали прямо на собеседовании со словами: «Документацию не пишем, интеграциями занимаются разработчики, а СА нужен просто чтобы был». Он отказался.
2. Выбрал второй оффер на 230 000 руб. - в команду со сложными интеграциями через Kafka и ESB, где системный аналитик реально проектирует архитектуру и прокачивает хард-скиллы.
Испытательный срок закончился, а задачи по шинам и брокерам он решает уже на уверенном мидл-уровне.
Главный вывод:
Вам не нужно учиться годами, чтобы сделать первый рывок в доходе. Достаточно перестать плавать в базе и научиться говорить с разработчиками на одном инженерном языке.
Ту самую первую главу (как устроен веб, клиент-серверное взаимодействие и архитектура запросов), которая дала такой буст, можно пройти в бесплатных вводных уроках курса «Проектирование архитектуры и интеграций сервисов» на Stepik.
Выбирайте трек под себя:
• Самостоятельный
• С поддержкой преподавателя
• С поддержкой преподавателя + упаковкой резюме, стратегией собеседований и доведением до оффера от 200к+
Нужен личный промо на скидку - пишите в лс: https://t.me/glebteach_bot
💬 Как вы искали свою первую работу в IT — честно признавались, что джун, или приходилось «докручивать» опыт в резюме? Делитесь в комментариях!
Мы в МАКС
🔥8
Почему кривой JSON Schema ломает и разработку, и ИИ-агентов: микро-урок по частым ошибкам 🛠📐
На днях под постом о будущем аналитиков подписчик Виталий оставил отличный комментарий (прикрепил на скрине выше): с развитием ИИ системным аналитикам придется проектировать контракты, воркфлоу и инструменты для ИИ-агентов.
И вот здесь кроется главный нюанс.
Если человек-разработчик при небрежно составленном Swagger еще может прийти в чат и переспросить: «Слушай, а в каком формате тут дата и может ли поле быть null?», то ИИ-агент или строгий валидатор просто упадут с ошибкой, либо агент начнет галлюцинировать.
Сегодня разберем 3 классические ошибки в JSON Schema / OpenAPI, которые ежедневно портят жизнь и бэкендерам, и ИИ-инструментам.
❌ Ошибка 1. Путаница между `required` и `nullable`
Частая картина в спеках: аналитик не добавляет поле в список
Как надо - четко разделять:
❌ Ошибка 2. Вездесущий `type: string` без ограничений
Когда в схеме на статус заказа или код валюты пишется просто
Как надо - Если набор значений конечен - всегда используйте `enum`:
Если это дата, UUID или email - обязательно задавайте
❌ Ошибка 3. Массивы без описания элементов (`type: array`)
Классика на скорую руку: указать
В итоге ни генератор автотестов, ни кодогенерация DTO, ни LLM не понимают, что именно лежит внутри — массив строк, чисел или сложных составных объектов.
Как надо: Любой массив обязан содержать спецификацию своих элементов:
💡 Грамотно спроектированная схема данных - это не бюрократия. Это универсальный цифровой контракт, благодаря которому сервисы, разработчики и ИИ-агенты понимают друг друга без бесконечных созвонов и багов на проде.
Первые вводные модули по веб-сервисам и REST доступны бесплатно (скоро доступ к ним закроем).
💬 Какие самые дикие ошибки в Swagger и схемах данных прилетали к вам от коллег или смежных команд? Делитесь в комментариях!
Еще почитать в канале:
💥5 ошибок в OpenAPI, которые обязательно дождутся вашего релиза.
💥Эфир с Глебом «Что выбрать в 2026, чтобы расти, а не просто учиться?»
На днях под постом о будущем аналитиков подписчик Виталий оставил отличный комментарий (прикрепил на скрине выше): с развитием ИИ системным аналитикам придется проектировать контракты, воркфлоу и инструменты для ИИ-агентов.
И вот здесь кроется главный нюанс.
Если человек-разработчик при небрежно составленном Swagger еще может прийти в чат и переспросить: «Слушай, а в каком формате тут дата и может ли поле быть null?», то ИИ-агент или строгий валидатор просто упадут с ошибкой, либо агент начнет галлюцинировать.
Сегодня разберем 3 классические ошибки в JSON Schema / OpenAPI, которые ежедневно портят жизнь и бэкендерам, и ИИ-инструментам.
❌ Ошибка 1. Путаница между `required` и `nullable`
Частая картина в спеках: аналитик не добавляет поле в список
required, думая, что этого достаточно, но не описывает, что делать, если поле передано как null.Как надо - четко разделять:
* Поле обязательное (должно всегда присутствовать в JSON-объекте) → указываем в массиве `required: [id, amount]`.
* Поле опциональное (может отсутствовать в запросе).
* Поле nullable (может прийти с явным значением `null`) → в OpenAPI 3.0 указываем `nullable: true` (или `type: [string, "null"]` в JSON Schema Draft 7+).
❌ Ошибка 2. Вездесущий `type: string` без ограничений
Когда в схеме на статус заказа или код валюты пишется просто
type: string, вы даете карт-бланш на любые данные. Разработчику приходится писать лишние проверки, а ИИ-агент при генерации вызова может передать "status": "completed" вместо "SUCCESS"`.Как надо - Если набор значений конечен - всегда используйте `enum`:
status:
type: string
enum: [DRAFT, PENDING, COMPLETED, REJECTED]
description: Текущий статус обработки заявки
Если это дата, UUID или email - обязательно задавайте
format: date-time, format: uuid или pattern (регулярное выражение).❌ Ошибка 3. Массивы без описания элементов (`type: array`)
Классика на скорую руку: указать
type: array и забыть блок items.В итоге ни генератор автотестов, ни кодогенерация DTO, ни LLM не понимают, что именно лежит внутри — массив строк, чисел или сложных составных объектов.
Как надо: Любой массив обязан содержать спецификацию своих элементов:
items:
type: object
required: [itemId, quantity]
properties:
itemId:
type: string
format: uuid
quantity:
type: integer
minimum: 1
💡 Грамотно спроектированная схема данных - это не бюрократия. Это универсальный цифровой контракт, благодаря которому сервисы, разработчики и ИИ-агенты понимают друг друга без бесконечных созвонов и багов на проде.
Первые вводные модули по веб-сервисам и REST доступны бесплатно (скоро доступ к ним закроем).
💬 Какие самые дикие ошибки в Swagger и схемах данных прилетали к вам от коллег или смежных команд? Делитесь в комментариях!
Еще почитать в канале:
💥5 ошибок в OpenAPI, которые обязательно дождутся вашего релиза.
💥Эфир с Глебом «Что выбрать в 2026, чтобы расти, а не просто учиться?»
🔥5
Выхожу в люди просить бусты.
Прогресс-бар говорит - осталось 2 из 3 до релиза историй 🚀
Если есть Telegram Premium - буду благодарен и смогу постить всего 1 историю за 24 часа👇
https://t.me/boost/openstudyit
Прогресс-бар говорит - осталось 2 из 3 до релиза историй 🚀
Если есть Telegram Premium - буду благодарен и смогу постить всего 1 историю за 24 часа👇
https://t.me/boost/openstudyit
👍6😁1
Как прокачать проектирование API и интеграций без удара по бюджету: честно про тарифы и рассрочку на Stepik
Частая ситуация: аналитик или разработчик понимает, что уперся в потолок. На созвонах с бэкендом сложно аргументировать выбор Kafka вместо REST, в контрактах Swagger регулярно всплывают косяки, а на собеседованиях срезают на вопросах про идемпотентность и распределенные транзакции.
Хочется сесть, один раз системно закрыть все пробелы на реальных боевых кейсах и вырасти в грейде. Но отдавать всю сумму за качественное обучение разом бывает не всегда комфортно.
На Stepik доступна беспроцентная рассрочка (оплата частями без скрытых комиссий и переплат). Платеж делится на равные части, а доступ ко всем материалам и практике открывается сразу. Подробнее на сайте Stepik.
Какой формат обучения выбрать под ваши задачи:
🔹 1. Тариф «Без обратной связи» за 13 990 руб.
Подойдет тем, кто привык учиться самостоятельно и кому нужна только структурированная база: вся теория по архитектуре, брокерам сообщений, REST/gRPC, практические задания и бессрочный доступ к материалам.
🔹 2. Тариф «С проверкой преподавателя» за 25 000 руб.
(🔥 Основной выбор) Фокус для тех, кто хочет максимального результата без иллюзий. Здесь каждое ваше домашнее задание и схема интеграции проходят детальное ревью от наших кураторов с разбором краевых кейсов и ошибок, которые обычно вскрываются только на проде.
🔹 3. Тариф с модулем «Карьера» за 44 000 руб.
Комплексный трек: помимо полной программы и проверки всех заданий, мы помогаем упаковать ваше резюме и портфолио кейсов, проводим тренировочные технические собеседования и готовим к каверзным вопросам лидов на интервью.
Все еще открыты бесплатных вводных уроки в разных модулях - лучший способ оценить подачу материала и глубину практики перед покупкой.
Любой из тарифов выше можно оформить в беспроцентную рассрочку прямо при оплате. Нужен личный промо на скидку - пишите в лс: https://t.me/glebteach_bot
👇 Коллеги, в какой момент работы вы поняли, что базовой теории из статей уже не хватает и нужно глубоко разбираться в архитектуре систем?
Частая ситуация: аналитик или разработчик понимает, что уперся в потолок. На созвонах с бэкендом сложно аргументировать выбор Kafka вместо REST, в контрактах Swagger регулярно всплывают косяки, а на собеседованиях срезают на вопросах про идемпотентность и распределенные транзакции.
Хочется сесть, один раз системно закрыть все пробелы на реальных боевых кейсах и вырасти в грейде. Но отдавать всю сумму за качественное обучение разом бывает не всегда комфортно.
На Stepik доступна беспроцентная рассрочка (оплата частями без скрытых комиссий и переплат). Платеж делится на равные части, а доступ ко всем материалам и практике открывается сразу. Подробнее на сайте Stepik.
Какой формат обучения выбрать под ваши задачи:
🔹 1. Тариф «Без обратной связи» за 13 990 руб.
Подойдет тем, кто привык учиться самостоятельно и кому нужна только структурированная база: вся теория по архитектуре, брокерам сообщений, REST/gRPC, практические задания и бессрочный доступ к материалам.
🔹 2. Тариф «С проверкой преподавателя» за 25 000 руб.
(🔥 Основной выбор) Фокус для тех, кто хочет максимального результата без иллюзий. Здесь каждое ваше домашнее задание и схема интеграции проходят детальное ревью от наших кураторов с разбором краевых кейсов и ошибок, которые обычно вскрываются только на проде.
🔹 3. Тариф с модулем «Карьера» за 44 000 руб.
Комплексный трек: помимо полной программы и проверки всех заданий, мы помогаем упаковать ваше резюме и портфолио кейсов, проводим тренировочные технические собеседования и готовим к каверзным вопросам лидов на интервью.
Все еще открыты бесплатных вводных уроки в разных модулях - лучший способ оценить подачу материала и глубину практики перед покупкой.
Любой из тарифов выше можно оформить в беспроцентную рассрочку прямо при оплате. Нужен личный промо на скидку - пишите в лс: https://t.me/glebteach_bot
👇 Коллеги, в какой момент работы вы поняли, что базовой теории из статей уже не хватает и нужно глубоко разбираться в архитектуре систем?
This media is not supported in your browser
VIEW IN TELEGRAM
🔥4
Победителя конкурса выбрал🔥Пиццу отправил
Мы к отпуску готовы😎 В понедельник команда напишет ответ (пока я буду без связи) и отправим всем участникам обещанные пдф-ки👍
Мы к отпуску готовы😎 В понедельник команда напишет ответ (пока я буду без связи) и отправим всем участникам обещанные пдф-ки👍
❤🔥4
Итоги теста на инженерное мышление: разбор двойного списания и отправка пиццы 🍕🧠
Коллеги, спасибо за участие в разборе платежного кейса! Мы получили более 10 крутых комментариев с самыми разными гипотезами. Приятно видеть такой уровень инженерного мышления в канале.
Напомню задачу:
Разбор решения:
1. Фундаментальная ошибка: повторные запросы отправлялись как новые транзакции. Внутренний сервис никак не сообщал внешнему эквайрингу, что это повтор той же самой операции.
2. Как это чинить: единственный надежный способ: внедрение механизма идемпотентности. Клиент или ядро системы генерируют уникальный ключ операции (например, UUID в заголовке `Idempotency-Key`). Внешний эквайринг, получив запрос с уже знакомым ключом, возвращает сохраненный статус предыдущей операции без проведения повторного списания.
Также хорошей практикой является проверка статуса платежа через `GET`-запрос перед выполнением автоматических повторов.
🏆 Победитель: идеального ответа никогда не бывает, но быстрее и ближе к решению оказалась Анна (читать ее комментарий)
Анна выбрала пиццу, и мы её уже отправили (подтверждение и фото в карусели выше)!
🎁 Для участников, как и обещал, команда отправит в личные сообщения подробную PDF-схему проектирования платежного шлюза с чек-листом по идемпотентности API.
И последнее. Кто уже приобрел курс на Stepik в этом месяце, но еще не вступил в наш закрытый чат учеников, обязательно проверьте переходите по ссылке из первых уроках. Ждем вас в комьюнити!
Коллеги, спасибо за участие в разборе платежного кейса! Мы получили более 10 крутых комментариев с самыми разными гипотезами. Приятно видеть такой уровень инженерного мышления в канале.
Напомню задачу:
платежный сервис отправлял запрос во внешний эквайринг, падал по таймауту HTTP 504 и автоматически повторял запросы, что привело к двойным списаниям у клиентов на проде.
Разбор решения:
1. Фундаментальная ошибка: повторные запросы отправлялись как новые транзакции. Внутренний сервис никак не сообщал внешнему эквайрингу, что это повтор той же самой операции.
2. Как это чинить: единственный надежный способ: внедрение механизма идемпотентности. Клиент или ядро системы генерируют уникальный ключ операции (например, UUID в заголовке `Idempotency-Key`). Внешний эквайринг, получив запрос с уже знакомым ключом, возвращает сохраненный статус предыдущей операции без проведения повторного списания.
Также хорошей практикой является проверка статуса платежа через `GET`-запрос перед выполнением автоматических повторов.
🏆 Победитель: идеального ответа никогда не бывает, но быстрее и ближе к решению оказалась Анна (читать ее комментарий)
Анна выбрала пиццу, и мы её уже отправили (подтверждение и фото в карусели выше)!
🎁 Для участников, как и обещал, команда отправит в личные сообщения подробную PDF-схему проектирования платежного шлюза с чек-листом по идемпотентности API.
И последнее. Кто уже приобрел курс на Stepik в этом месяце, но еще не вступил в наш закрытый чат учеников, обязательно проверьте переходите по ссылке из первых уроках. Ждем вас в комьюнити!
🔥2👏1