Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Наконец-то наметил свой единственный отпуск в этом году - в конце августа в Турцию. Цены, конечно, космос, но восстанавливать ресурс надо без вариантов 🌴
Пишите в комментариях, у кого как с отпусками в этом году, интересно - поболтаем. И спасибо за такое активное участие в опросах выше🎉
P.S. Для тех, кто не успел на последнюю акцию, продлил промокод -25% на все тарифы до понедельника 3 августа (23:59) - подробнее в [этом посте].
Проходить материалы сможете в своем темпе, хоть осенью.
Пишите в комментариях, у кого как с отпусками в этом году, интересно - поболтаем. И спасибо за такое активное участие в опросах выше🎉
P.S. Для тех, кто не успел на последнюю акцию, продлил промокод -25% на все тарифы до понедельника 3 августа (23:59) - подробнее в [этом посте].
Проходить материалы сможете в своем темпе, хоть осенью.
Telegram
API. Архитектура. Веб-сервисы
Есть одна проблема, о которой не говорят в больших онлайн-школах. Она проявляется уже на первом серьезном техническом собеседовании.
Представьте, вас спрашивают:
«Окей, а почему здесь Kafka, а не обычный REST-запрос?»
После такого вопроса очень быстро…
Представьте, вас спрашивают:
«Окей, а почему здесь Kafka, а не обычный REST-запрос?»
После такого вопроса очень быстро…
😁8
Channel name was changed to «API. Архитектура. Веб-сервисы | Глеб Учитель»
API. Архитектура. Веб-сервисы | Глеб Учитель
Voice message
Понял-понял и по опросу и комментарию на скрине, ИИ-подкасты вам не очень, попробую с этим что-то сделать, пока, как есть, спасибо за честную открытую обратную связь и понимание 😊
Насчет модуля по ИИ из того же комментария на скрине.
Расскажу немного про наше «закулисье». На самом деле курс делает небольшая команда опытных аналитиков.
Сам модуль по ИИ мы писали сами, а видео записывал Глеб (часть материалов действительно озвучена им).
При этом (не буду лукавить) для редактуры текста команда иногда использует ИИ.
Если кажется, что где-то текст стал слишком «гладким» и потерял живую подачу, значит, не попали в баланс.
Спасибо, что обратили на это внимание, попробуем другие подходы к редактуре.
Что касается голосовых в канале: да, сейчас тестируем ИИ-озвучку. Но именно озвучку. Сам текст, идеи и структура остаются от Глеба. Нам просто интересно попробовать новый формат и понять, насколько он удобен аудитории.
И точно не хочется превращаться в очередной «завод по производству ИИ-контента».
Думаю, если бы это было нашей целью, с нашими навыками Вы бы уже давно были завалены таким контентом. Мы сами скорее против этого и ценим человеческую экспертность.
Кто еще смотрел модуль по ИИ? Пишите обратку в комментариях👇🏻
Насчет модуля по ИИ из того же комментария на скрине.
Расскажу немного про наше «закулисье». На самом деле курс делает небольшая команда опытных аналитиков.
Сам модуль по ИИ мы писали сами, а видео записывал Глеб (часть материалов действительно озвучена им).
При этом (не буду лукавить) для редактуры текста команда иногда использует ИИ.
Если кажется, что где-то текст стал слишком «гладким» и потерял живую подачу, значит, не попали в баланс.
Спасибо, что обратили на это внимание, попробуем другие подходы к редактуре.
Что касается голосовых в канале: да, сейчас тестируем ИИ-озвучку. Но именно озвучку. Сам текст, идеи и структура остаются от Глеба. Нам просто интересно попробовать новый формат и понять, насколько он удобен аудитории.
И точно не хочется превращаться в очередной «завод по производству ИИ-контента».
Думаю, если бы это было нашей целью, с нашими навыками Вы бы уже давно были завалены таким контентом. Мы сами скорее против этого и ценим человеческую экспертность.
Кто еще смотрел модуль по ИИ? Пишите обратку в комментариях👇🏻
🔥1
API. Архитектура. Веб-сервисы | Глеб Учитель
СНАЧАЛА ЧИТАЙ ТУТ👇👇👇 Привет, рад видеть, я Глеб — Technical Product Manager и автор этого канала. В IT более 8 лет: прошёл путь от инженера поддержки до системного аналитика и технического продакта. С 2023 года вместе с командой обучили 2000+ специалистов…
Обновил закрепленное сообщение в канале, оцените👆🏼
Оно больше для новых подписчиков канала, но возможно, кто-то какие-то обновления еще не видел.
Сейчас с командой немного переупаковываемся. Основа остается. Самое лучшее для понимания, что мы идем в верном направлении - ваша обратная связь🔥 как вы поняли - всегда рад, как здесь, так и лично.
Отличного дня и настроения😎
Оно больше для новых подписчиков канала, но возможно, кто-то какие-то обновления еще не видел.
Сейчас с командой немного переупаковываемся. Основа остается. Самое лучшее для понимания, что мы идем в верном направлении - ваша обратная связь🔥 как вы поняли - всегда рад, как здесь, так и лично.
Отличного дня и настроения😎
🔥6👍2
🎙Продолжение. На связи Глеб Учитель, в этих двух аудио, делюсь мыслями на хайповые темы, которые звучат в информационном поле 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 (вводные уроки доступны бесплатно).
👇 Коллеги, сталкивались на проде с падением цепочек синхронных вызовов? Как развязывали — через саги, брокеры или ретраи с таймаутами?