Когда цифры говорят сами за себя...
То, что очевидно для одного, возможно, вызывает вопросы у других. И это нормально👍
Ребята, сейчас разберемся с этим шаблоном😎
Когда один сервис пытается отправить запрос другому, но тот не отвечает (например, из-за перегрузки или ошибки), Circuit Breaker как бы говорит: "Стоп! Больше не пытайся, пока он не починится!".
❗️Это предотвращает дальнейшие попытки, которые только добавили бы больше нагрузки.
Представьте, что вы звоните другу, но он не берет трубку. Вместо того чтобы звонить бесконечно, вы понимаете: "Ладно, перезвоню позже, когда он сможет ответить".
Точно так же Circuit Breaker предотвращает постоянные попытки подключиться к сломанному сервису, чтобы не перегружать систему.
Другие варианты тоже важны, но не совсем про это:
✅ Bulkhead разделяет ресурсы, чтобы сбой одного компонента не повлиял на другие
✅ Retry Pattern пробует повторять запросы, если что-то не получилось, но это может даже ухудшить ситуацию при сбое
✅ Timeout задает время ожидания для ответа, но не решает проблему перегрузки сервиса.
Если все понятно - ставьте🔥
Хотите все же посложнее задачки?)
Не вопрос⬇️
То, что очевидно для одного, возможно, вызывает вопросы у других. И это нормально👍
Ребята, сейчас разберемся с этим шаблоном😎
Circuit Breaker — это шаблон, который помогает защитить микросервис, если другой микросервис вдруг "сломался" или стал слишком медленно работать.
Когда один сервис пытается отправить запрос другому, но тот не отвечает (например, из-за перегрузки или ошибки), Circuit Breaker как бы говорит: "Стоп! Больше не пытайся, пока он не починится!".
❗️Это предотвращает дальнейшие попытки, которые только добавили бы больше нагрузки.
Представьте, что вы звоните другу, но он не берет трубку. Вместо того чтобы звонить бесконечно, вы понимаете: "Ладно, перезвоню позже, когда он сможет ответить".
Точно так же Circuit Breaker предотвращает постоянные попытки подключиться к сломанному сервису, чтобы не перегружать систему.
Другие варианты тоже важны, но не совсем про это:
Если все понятно - ставьте🔥
Хотите все же посложнее задачки?)
Не вопрос⬇️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍3
Какой технический момент проектирования интеграции наиболее критичен при реализации backpressure в асинхронной коммуникации микросервисов?
Anonymous Quiz
22%
Ограничение количества параллельных запросов
17%
Статический баланс нагрузки
44%
Обратная связь (feedback loop) от потребителя к поставщику
17%
Использование REST вместо WebSockets
👍9
Мы тут подарки раздаём… Вы с нами? 😉
Системные аналитики (и все причастные), с профессиональным праздником🔥 Что тут сказать: классных проектов и карьерного роста!
В честь этого праздника мы хотим подарить вам промокод 🎁 на наше обучение (на любой тариф), чтобы вы могли ещё лучше прокачать свои скиллы.
❗️И это еще не все…
При активации промокода, вы получаете личную консультацию с автором курса — отличная возможность получить ценные инсайты по вашей профессиональной теме!
Но, спешите: предложение действует до 1 октября.
Кто хотел обучаться и ждал подходящего момента — welcome! 👇
Базовый тариф — 12.000 рублей (вместо 13 990 рублей).
Тариф с поддержкой — 20.000 рублей (вместо 25.000 рублей).
Тариф с поддержкой и карьерным модулем — 35.000 рублей (вместо 44.000 рублей).
Промокод: ANALYTIC
Системные аналитики (и все причастные), с профессиональным праздником🔥 Что тут сказать: классных проектов и карьерного роста!
В честь этого праздника мы хотим подарить вам промокод 🎁 на наше обучение (на любой тариф), чтобы вы могли ещё лучше прокачать свои скиллы.
❗️И это еще не все…
При активации промокода, вы получаете личную консультацию с автором курса — отличная возможность получить ценные инсайты по вашей профессиональной теме!
Но, спешите: предложение действует до 1 октября.
Кто хотел обучаться и ждал подходящего момента — welcome! 👇
Базовый тариф — 12.000 рублей (вместо 13 990 рублей).
Тариф с поддержкой — 20.000 рублей (вместо 25.000 рублей).
Тариф с поддержкой и карьерным модулем — 35.000 рублей (вместо 44.000 рублей).
Промокод: ANALYTIC
🔥25
Forwarded from Nikolaus.
Подскажите, пожалуйста:
1. Если на "вырост" возьму курс, смогу приступить к обучению через 4 или 6 месяцев, ничего страшного? Консультация с автором не пропадёт?
2. Сколь примерно времени понадобится для прохождения курса новичку, в среднем темпе? Месяц, два ?
3. Как часто воркшопы бывают ? Практические задачи из "жизни"? Приведите примеры решаемых задач, если возможно.
4. Будет ли Ваш курс полезен после Дата сайентс, аналитика данных ?
Благодарю за ответ.
1. Если на "вырост" возьму курс, смогу приступить к обучению через 4 или 6 месяцев, ничего страшного? Консультация с автором не пропадёт?
2. Сколь примерно времени понадобится для прохождения курса новичку, в среднем темпе? Месяц, два ?
3. Как часто воркшопы бывают ? Практические задачи из "жизни"? Приведите примеры решаемых задач, если возможно.
4. Будет ли Ваш курс полезен после Дата сайентс, аналитика данных ?
Благодарю за ответ.
Классные вопросы от подписчика 👆
Отвечаем в той же последовательности по каждому пункту:
1️⃣ Конечно, можете приобретать курс уже сейчас, наше обучение имеет бессрочный доступ к материалам на платформе в личном кабинете и поддержку от преподавателя.
Консультация тоже не пропадёт, если купили до октября (промокод - ANALYTIC)
2️⃣ Если полностью с нуля проходить в плавном темпе обучение займется около 2-х месяцев. Если постараться, можно и быстрее, конечно.
Никаких дедлайнов и сроков вам никто не ставит, свой учебный процесс планируете сами.
3️⃣ Воркшопы планируем запускать в Q4 (сейчас был акцент на консультациях личных).
Воркшопы будут на самые разные темы: проектирование API для интернет магазина, моделирование бизнес-процесса выдачи кредита, проектирование системы с помощью UML, разработка архитектуры системы в C4, и т.д. Весь движ с учениками будет проходить в отдельном закрытом чате.
4️⃣ Да, курс полезен и Data аналитикам, потому что API используется довольно много и в этой сфере, и в том числе понимание архитектуры проекта может быть преимуществом для результативной работы.
⁉️Про действующий промокод ANALYTIC до 1 октября помните? Еще успеваете получить хорошую цену на обучение и личную консультацию Глеба Учителя - подробности ТУТ.
Если еще есть вопросы по обучению - смело задавайте в комментариях 👇
Отвечаем в той же последовательности по каждому пункту:
1️⃣ Конечно, можете приобретать курс уже сейчас, наше обучение имеет бессрочный доступ к материалам на платформе в личном кабинете и поддержку от преподавателя.
Консультация тоже не пропадёт, если купили до октября (промокод - ANALYTIC)
2️⃣ Если полностью с нуля проходить в плавном темпе обучение займется около 2-х месяцев. Если постараться, можно и быстрее, конечно.
Никаких дедлайнов и сроков вам никто не ставит, свой учебный процесс планируете сами.
3️⃣ Воркшопы планируем запускать в Q4 (сейчас был акцент на консультациях личных).
Воркшопы будут на самые разные темы: проектирование API для интернет магазина, моделирование бизнес-процесса выдачи кредита, проектирование системы с помощью UML, разработка архитектуры системы в C4, и т.д. Весь движ с учениками будет проходить в отдельном закрытом чате.
4️⃣ Да, курс полезен и Data аналитикам, потому что API используется довольно много и в этой сфере, и в том числе понимание архитектуры проекта может быть преимуществом для результативной работы.
⁉️Про действующий промокод ANALYTIC до 1 октября помните? Еще успеваете получить хорошую цену на обучение и личную консультацию Глеба Учителя - подробности ТУТ.
Если еще есть вопросы по обучению - смело задавайте в комментариях 👇
🔥12
Это невероятно❗️
И так приятно видеть отзывы о нашей работе и обучении на канале наших коллег👆
#ученикиговорят
Ценим каждый отзыв🤍 Рады, что наше обучение помогает ребятам расти, как профессионалам, и достигать новых высот в сфере IT!
Да, это фишка нашей команды - бесплатный доступ к материалам курса навсегда! Изучайте и применяйте👍
Напоминаем, что сегодня еще действует промокод ANALYTIC на все тарифы курса!
Успевайте забронировать за собой лучшие цены и получить индивидуальную консультацию Глеба Учителя.
И так приятно видеть отзывы о нашей работе и обучении на канале наших коллег👆
#ученикиговорят
Ценим каждый отзыв🤍 Рады, что наше обучение помогает ребятам расти, как профессионалам, и достигать новых высот в сфере IT!
Да, это фишка нашей команды - бесплатный доступ к материалам курса навсегда! Изучайте и применяйте👍
Напоминаем, что сегодня еще действует промокод ANALYTIC на все тарифы курса!
Успевайте забронировать за собой лучшие цены и получить индивидуальную консультацию Глеба Учителя.
🔥7👍3
Интеграция была, есть и будет⚡️
Ведь именно интеграция позволяет отдать системам рутинные задачи, которые сотрудники делали еще вручную. Это ускоряет бизнес-процессы и обходится дешевле. Как говорится, ничего личного - это просто бизнес!
Конечно, основные принципы работы интеграции систем могут различаться (специфика каждой задачи, используемые технологии в компании и т.д.).
Однако, есть стандартные принципы, которые чаще всего мы видим в процессе интеграции систем и, благодаря которым, бизнесы используют/внедряют интеграции в свои процессы:
1️⃣ Гибкость. Это позволяет легко внедрять новое, изменять функциональность, не внося хаос в основную работу всех бизнес-процессов.
2️⃣ Масштабируемость. Система должна быть готова к более повышенной нагрузке, чтобы обрабатывать большие объемы информации, помогая расти бизнесу и улучшать производительность.
3️⃣ Безопасность. Это включает в себя механизмы, которые обеспечивают безопасность данных и сценариев, а также защиту от несанкционированного доступа, минимизацию возможности сбоя.
4️⃣ Управляемость. Это регулярный мониторинг работы системы и постоянное выявление/устранение ошибок
И всю эту конструкцию собирает в техническую документацию именно системный аналитик, который владеет навыками проектирования интеграций. Только потом в игру вступает разработчик. Это к тому, что многие до сих пор думают, что какие-то профессии более престижные или ценные в IT🙈
А для бизнеса важен каждый процесс. И команда эффективна, когда работает, как единый механизм, в котором нет лишней детали.
Поделитесь, на какой позиции сейчас работаете в IT или претендуете? Насколько ощущаете ценность своей работы в команде?
Ведь именно интеграция позволяет отдать системам рутинные задачи, которые сотрудники делали еще вручную. Это ускоряет бизнес-процессы и обходится дешевле. Как говорится, ничего личного - это просто бизнес!
Конечно, основные принципы работы интеграции систем могут различаться (специфика каждой задачи, используемые технологии в компании и т.д.).
Однако, есть стандартные принципы, которые чаще всего мы видим в процессе интеграции систем и, благодаря которым, бизнесы используют/внедряют интеграции в свои процессы:
1️⃣ Гибкость. Это позволяет легко внедрять новое, изменять функциональность, не внося хаос в основную работу всех бизнес-процессов.
2️⃣ Масштабируемость. Система должна быть готова к более повышенной нагрузке, чтобы обрабатывать большие объемы информации, помогая расти бизнесу и улучшать производительность.
3️⃣ Безопасность. Это включает в себя механизмы, которые обеспечивают безопасность данных и сценариев, а также защиту от несанкционированного доступа, минимизацию возможности сбоя.
4️⃣ Управляемость. Это регулярный мониторинг работы системы и постоянное выявление/устранение ошибок
И всю эту конструкцию собирает в техническую документацию именно системный аналитик, который владеет навыками проектирования интеграций. Только потом в игру вступает разработчик. Это к тому, что многие до сих пор думают, что какие-то профессии более престижные или ценные в IT🙈
Начните мыслить другими категориями: есть спрос на эту услугу и вы владеете навыками, знаниями и опытом в этой сфере лучше других - вам не будет равных.
А для бизнеса важен каждый процесс. И команда эффективна, когда работает, как единый механизм, в котором нет лишней детали.
Поделитесь, на какой позиции сейчас работаете в IT или претендуете? Насколько ощущаете ценность своей работы в команде?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Важно ваше мнение❗️Какие темы раскрыть в канале подробнее в ближайшее время (в т.ч. на эфирах)?
Anonymous Poll
47%
Документация API
59%
Брокеры сообщений
33%
Функциональные требования к системе
2%
Другое (напишите в комментариях актуальные для вас темы, которые нужно осветить подробнее)
👍8
Как GitHub перешёл с REST на GraphQL и что из этого получилось?👆
Рассказываю в аудио классный случай из практики!
Поймете, как конкретные изменения в архитектуре API могут существенно улучшить производительность и масштабируемость любого приложения🔥
🎧Слушайте подкаст @openstudyit
Рассказываю в аудио классный случай из практики!
Поймете, как конкретные изменения в архитектуре API могут существенно улучшить производительность и масштабируемость любого приложения🔥
🎧Слушайте подкаст @openstudyit
🔥9👍3
Есть интересная задача по проектированию API + ПОДАРОК для вас🎁
Выбор оптимального API для обновления данных пользователя
Представьте, вы работаете над REST API для приложения управления пользователями. Вам нужно спроектировать конечную точку (endpoint) для обновления информации о пользователе по его уникальному идентификатору (user_id).
❗️Требования:
✔️Обновление данных пользователя должно быть частичным: клиент может отправить только те поля, которые нужно изменить
✔️Необходимо придерживаться RESTful стиля и использовать правильные HTTP методы
✔️Сервер должен обрабатывать запросы безопасно и эффективно
У вас есть три варианта реализации:
1️⃣ HTTP метод: PUT
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}
2️⃣ HTTP метод: PATCH
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}
3️⃣ HTTP метод: POST
URL: /updateUser
Тело запроса:
{
"user_id": 123,
"name": "New Name"
}
Какой из вариантов является наиболее правильным с точки зрения RESTful практик для частичного обновления данных пользователя и ПОЧЕМУ?
Пишите вариант, который считаете верным, в комментариях и почему👇
Первые 5 подписчиков, кто ответит верно - получат крутой подарок от нас🎁
Выбор оптимального API для обновления данных пользователя
Представьте, вы работаете над REST API для приложения управления пользователями. Вам нужно спроектировать конечную точку (endpoint) для обновления информации о пользователе по его уникальному идентификатору (user_id).
❗️Требования:
✔️Обновление данных пользователя должно быть частичным: клиент может отправить только те поля, которые нужно изменить
✔️Необходимо придерживаться RESTful стиля и использовать правильные HTTP методы
✔️Сервер должен обрабатывать запросы безопасно и эффективно
У вас есть три варианта реализации:
1️⃣ HTTP метод: PUT
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}
2️⃣ HTTP метод: PATCH
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}
3️⃣ HTTP метод: POST
URL: /updateUser
Тело запроса:
{
"user_id": 123,
"name": "New Name"
}
Какой из вариантов является наиболее правильным с точки зрения RESTful практик для частичного обновления данных пользователя и ПОЧЕМУ?
Пишите вариант, который считаете верным, в комментариях и почему👇
Первые 5 подписчиков, кто ответит верно - получат крутой подарок от нас🎁
🔥10👍4👏2
This media is not supported in your browser
VIEW IN TELEGRAM
👍8👏1
Да, это был метод PATCH для частичного обновления🔥
Почему? (здесь найдете вопрос)👇
Метод PATCH предназначен специально для частичного обновления ресурса.
✔️Клиент может отправить только те поля, которые нужно изменить, без необходимости предоставлять полное представление ресурса.
✔️ Это соответствует требованию о частичном обновлении данных пользователя.
RESTful URL:
☑️ URL /users/{user_id} правильно идентифицирует ресурс пользователя по его уникальному идентификатору.
☑️ Это соответствует RESTful практике использования путей для обращения к ресурсам.
Часто используете этот метод в интеграции?
Почему? (здесь найдете вопрос)👇
Метод PATCH предназначен специально для частичного обновления ресурса.
✔️Клиент может отправить только те поля, которые нужно изменить, без необходимости предоставлять полное представление ресурса.
✔️ Это соответствует требованию о частичном обновлении данных пользователя.
RESTful URL:
☑️ URL /users/{user_id} правильно идентифицирует ресурс пользователя по его уникальному идентификатору.
☑️ Это соответствует RESTful практике использования путей для обращения к ресурсам.
Часто используете этот метод в интеграции?
🔥8
Patch это понятно)
А можете рассказать другое пожалуйста, почему в данной формулировке и вводных put не походит как ответ в вашем понимании?
Я на чем хочу сконцентрировать внимание:
То что вы не сказали какая метамодель у обьекта user. Если он у вас состоит из только имени и id (который передается в url). То put тут тоже работает.
Да ,действительно, если бы модель юзера состояла из больших атрибутов - то однозначный ответ в этом кейсе был бы Patch.
Я ошибаюсь?
А можете рассказать другое пожалуйста, почему в данной формулировке и вводных put не походит как ответ в вашем понимании?
Я на чем хочу сконцентрировать внимание:
То что вы не сказали какая метамодель у обьекта user. Если он у вас состоит из только имени и id (который передается в url). То put тут тоже работает.
Да ,действительно, если бы модель юзера состояла из больших атрибутов - то однозначный ответ в этом кейсе был бы Patch.
Я ошибаюсь?
🔥7👍1
Отличный вопрос - классная обратная связь от подписчика👆
Давайте разберёмся, почему в этом случае лучше использовать PATCH, а не PUT, даже если у нас у пользователя только id и name.
❗️Повторим разницу между PATCH и PUT
☑️ PUT:
Предназначен для полной замены ресурса. Ожидается, что ты отправляешь полное представление ресурса.
Если какие-то поля не указаны, они могут быть удалены или перезаписаны.
☑️ PATCH:
Предназначен для частичного обновления ресурса.
Можно отправить только те поля, которые нужно изменить.
Остальные поля остаются без изменений.
Почему в нашем случае PUT может не подходить?
1️⃣ Риск потери данных
Если используешь PUT и отправляешь только name, не указывая другие поля, сервер может подумать, что ты хочешь заменить весь ресурс новым, который содержит только name.
Остальные поля могут быть удалены или сброшены, что приведёт к потере данных.
2️⃣ Соответствие стандартам (на них всё же опираются некоторые разработчики 😁)
По стандартам HTTP PUT должен использоваться для полной замены ресурса.
Использовать PUT для частичного обновления — это нарушение этих принципов и может привести к непредсказуемому поведению.
3️⃣ Будущие изменения
Сейчас у пользователя только id и name, но позже могут добавиться другие поля (например, email, age).
Если с самого начала используешь PUT для частичного обновления, потом придётся менять логику на клиенте, чтобы отправлять все поля, иначе новые могут быть потеряны.
Пример проблемы с PUT на пальцах👇
Представьте, что сейчас такая модель пользователя:
{
"id": 123,
"name": "Alice"
}
Вы отправляете запрос:
PUT /users/123
Content-Type: application/json
{
"name": "Bob"
}
Ожидаемый результат:
Изменится только name, остальные поля останутся.
Фактический возможный результат:
Сервер заменяет ресурс новым, где только name указано.
Получаем:
{
"id": null, // или id удаляется
"name": "Bob"
}
...Поле id потеряно, что плохо.
РЕЗЮМЕ
Подписчик прав, что в очень простом случае, когда у пользователя только id и name, использование PUT может показаться нормальным.
НО❗️
С точки зрения стандартов и будущего развития вашего API, PATCH — возможно более оптимальный выбор.
Это обеспечит безопасность данных и устойчивость API к изменениям.
Согласны?
Давайте разберёмся, почему в этом случае лучше использовать PATCH, а не PUT, даже если у нас у пользователя только id и name.
❗️Повторим разницу между PATCH и PUT
☑️ PUT:
Предназначен для полной замены ресурса. Ожидается, что ты отправляешь полное представление ресурса.
Если какие-то поля не указаны, они могут быть удалены или перезаписаны.
☑️ PATCH:
Предназначен для частичного обновления ресурса.
Можно отправить только те поля, которые нужно изменить.
Остальные поля остаются без изменений.
Почему в нашем случае PUT может не подходить?
1️⃣ Риск потери данных
Если используешь PUT и отправляешь только name, не указывая другие поля, сервер может подумать, что ты хочешь заменить весь ресурс новым, который содержит только name.
Остальные поля могут быть удалены или сброшены, что приведёт к потере данных.
2️⃣ Соответствие стандартам (на них всё же опираются некоторые разработчики 😁)
По стандартам HTTP PUT должен использоваться для полной замены ресурса.
Использовать PUT для частичного обновления — это нарушение этих принципов и может привести к непредсказуемому поведению.
3️⃣ Будущие изменения
Сейчас у пользователя только id и name, но позже могут добавиться другие поля (например, email, age).
Если с самого начала используешь PUT для частичного обновления, потом придётся менять логику на клиенте, чтобы отправлять все поля, иначе новые могут быть потеряны.
Пример проблемы с PUT на пальцах👇
Представьте, что сейчас такая модель пользователя:
{
"id": 123,
"name": "Alice"
}
Вы отправляете запрос:
PUT /users/123
Content-Type: application/json
{
"name": "Bob"
}
Ожидаемый результат:
Изменится только name, остальные поля останутся.
Фактический возможный результат:
Сервер заменяет ресурс новым, где только name указано.
Получаем:
{
"id": null, // или id удаляется
"name": "Bob"
}
...Поле id потеряно, что плохо.
РЕЗЮМЕ
Подписчик прав, что в очень простом случае, когда у пользователя только id и name, использование PUT может показаться нормальным.
НО❗️
С точки зрения стандартов и будущего развития вашего API, PATCH — возможно более оптимальный выбор.
Это обеспечит безопасность данных и устойчивость API к изменениям.
Согласны?
👍27