В этом посте собрана подборка материалов по разным способам взаимодействия систем.
⚡ REST
📚 Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
📚 Postman: навык тестирования REST API за вечер
📚 Вопросы и ответы по REST API: собеседование на системного аналитика (подкаст)
Пример API-документации:
Wildberries
⚡ SOAP
Пример API-документации:
PayPal (обратите внимание, что устаревший)
⚡ WebSocket
Пример API-документации:
Binance Биржа
⚡ GraphQL
📚 GraphQL — знакомство на практике через Postman [пошаговая инструкция]
Пример API-документации:
Contentful
⚡ gRPC
📚 gRCP vs REST - что выбрать для проекта (подкаст + материалы)
Пример API-документации:
Dropbox от Google
⚡ SSE
⚡+ есть Socket.IO
Знание всех подходов к взаимодействию между системами помогает в работе с проектированием архитектуры.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥42👍13❤10👏3
GetAnalyst FarmFresh - Архитектура - этап 1.png
307.1 KB
💎 Пример схемы архитектуры проекта #FarmFreshGA 💎
Самое простое в проектировании архитектуры микросервисов — создать схему, в которой есть только синхронные взаимодействия и один вид API, например, REST API. Однако в реальных системах редко встречаются решения, где используется только синхронный обмен данными.
Рассказываю, что к чему при проектировании архитектуры на примере схемы, прикреплённой к посту, где пока отсутствуют асинхронные взаимодействия.
1. Для проектирования архитектуры FarmFresh выбран шаблон API Gateway
Все запросы от клиентских приложений (Frontend) направляются в единый централизованный шлюз и далее проксируются (перенаправляются) на отдельные микросервисы, в зависимости от запроса.
2. Согласно предложенной схеме, внутреннее взаимодействие микросервисов организовано также через API Gateway
Надо понимать, что такое решение не всегда удачно.
Пример: Если сервису заказов нужно вернуть полную информацию о нём на Frontend, включая данные о товарах, то вместо прямого запроса в микросервис "Каталог товаров" придётся прогонять запрос через лишний слой API Gateway. Это может создавать ненужную задержку.
3. Снаружи для клиентов может быть только REST API, а “под капотом” всё что угодно
На предложенной схеме видим, что часть микросервисов предлагает взаимодействие через gRPC для ускорения обмена данными, а часть — через REST API. Однако слишком много разных видов API может усложнить разработку и сопровождение.
Простота и единообразие — залог успешной архитектуры.
Но зависит от проекта))) Где-то это просто нужно и точка.
#АрхитектураGA
Продолжение 👇
Самое простое в проектировании архитектуры микросервисов — создать схему, в которой есть только синхронные взаимодействия и один вид API, например, REST API. Однако в реальных системах редко встречаются решения, где используется только синхронный обмен данными.
Рассказываю, что к чему при проектировании архитектуры на примере схемы, прикреплённой к посту, где пока отсутствуют асинхронные взаимодействия.
1. Для проектирования архитектуры FarmFresh выбран шаблон API Gateway
Все запросы от клиентских приложений (Frontend) направляются в единый централизованный шлюз и далее проксируются (перенаправляются) на отдельные микросервисы, в зависимости от запроса.
2. Согласно предложенной схеме, внутреннее взаимодействие микросервисов организовано также через API Gateway
Надо понимать, что такое решение не всегда удачно.
Пример: Если сервису заказов нужно вернуть полную информацию о нём на Frontend, включая данные о товарах, то вместо прямого запроса в микросервис "Каталог товаров" придётся прогонять запрос через лишний слой API Gateway. Это может создавать ненужную задержку.
3. Снаружи для клиентов может быть только REST API, а “под капотом” всё что угодно
На предложенной схеме видим, что часть микросервисов предлагает взаимодействие через gRPC для ускорения обмена данными, а часть — через REST API. Однако слишком много разных видов API может усложнить разработку и сопровождение.
Простота и единообразие — залог успешной архитектуры.
Но зависит от проекта))) Где-то это просто нужно и точка.
#АрхитектураGA
Продолжение 👇
👍20🔥5❤3💯1
💎 Пример схемы архитектуры проекта #FarmFreshGA (продолжение 👇) 💎
4. Отправка уведомлений пользователям — задача важная, но она не должна тормозить работу системы
По текущей схеме, как минимум сервисы авторизации, управления пользователями, доставки, заказов и платежей могут генерировать уведомления для пользователей.
Итог: 5 сервисов обращаются к одному, что может привести к задержкам при синхронном взаимодействии из-за загрузки
Решение: для уменьшения нагрузки использовать асинхронное взаимодействие через брокеры сообщений (например, RabbitMQ или Kafka), чтобы уведомления отправлялись без ожидания ответа.
5. У каждого микросервиса своя БД
Это строго соответствует принципам микросервисной архитектуры.
Однако в реальных проектах иногда используются общие базы для нескольких микросервисов, чтобы упростить синхронизацию данных. Такой подход нарушает принципы, но может ускорить разработку на ранних стадиях.
6. Взаимодействие с сервисом чата организовано через WebSocket
Сервис чата работает в режиме реального времени. Чтобы не нагружать API Gateway постоянными открытыми соединениями, WebSocket вынесен на отдельный слой. Это решение выбрано для повышения производительности и отказоустойчивости.
Это одно из возможных решений.
--------------
Заключение:
Предложенная схема архитектуры FarmFresh демонстрирует базовую реализацию микросервисного взаимодействия с шаблоном API Gateway.
Для повышения производительности и надёжности системы стоит рассмотреть:
👉 Внедрение асинхронного взаимодействия через брокеры сообщений.
👉 Прямые вызовы между микросервисами там, где это оправдано.
👉 Минимизацию разнообразия API-протоколов для упрощения разработки и поддержки.
#АрхитектураGA
4. Отправка уведомлений пользователям — задача важная, но она не должна тормозить работу системы
По текущей схеме, как минимум сервисы авторизации, управления пользователями, доставки, заказов и платежей могут генерировать уведомления для пользователей.
Итог: 5 сервисов обращаются к одному, что может привести к задержкам при синхронном взаимодействии из-за загрузки
Решение: для уменьшения нагрузки использовать асинхронное взаимодействие через брокеры сообщений (например, RabbitMQ или Kafka), чтобы уведомления отправлялись без ожидания ответа.
5. У каждого микросервиса своя БД
Это строго соответствует принципам микросервисной архитектуры.
Однако в реальных проектах иногда используются общие базы для нескольких микросервисов, чтобы упростить синхронизацию данных. Такой подход нарушает принципы, но может ускорить разработку на ранних стадиях.
6. Взаимодействие с сервисом чата организовано через WebSocket
Сервис чата работает в режиме реального времени. Чтобы не нагружать API Gateway постоянными открытыми соединениями, WebSocket вынесен на отдельный слой. Это решение выбрано для повышения производительности и отказоустойчивости.
Это одно из возможных решений.
--------------
Заключение:
Предложенная схема архитектуры FarmFresh демонстрирует базовую реализацию микросервисного взаимодействия с шаблоном API Gateway.
Для повышения производительности и надёжности системы стоит рассмотреть:
👉 Внедрение асинхронного взаимодействия через брокеры сообщений.
👉 Прямые вызовы между микросервисами там, где это оправдано.
👉 Минимизацию разнообразия API-протоколов для упрощения разработки и поддержки.
#АрхитектураGA
🔥12❤🔥8👍6❤2
🚀 Асинхронное взаимодействие в архитектуре систем 🚀
Часто при разработке архитектуры начинают с простого: сервисы напрямую общаются друг с другом в реальном времени, используя синхронные вызовы, например через REST API, SOAP или gRPC.
Это удобно на старте, но по мере роста системы такое взаимодействие может создавать проблемы:
😬 высокую связанность,
😬 задержки в работе из-за высокой нагрузки на микросервис,
😬 или полное "падение" цепочки сервисов в алгоритме из-за сбоя одного из них.
С этими проблемами помогает справиться асинхронное взаимодействие, которое позволяет сервисам обмениваться сообщениями без ожидания ответа.
Ключевые преимущества такого решения:
👍 Развязка сервисов
Сервисы не зависят от доступности друг друга. Если один сервис временно недоступен, сообщения сохраняются в очереди и будут обработаны позже.
👍 Масштабируемость
Асинхронные системы легче масштабировать, так как взаимодействие сервисов не требует немедленного ответа.
👍 Отказоустойчивость
Если один из сервисов выходит из строя, система продолжает работать, а сообщения обрабатываются, когда сервис снова становится доступным.
Технологии, помогающие реализовать асинхронное взаимодействие:
1. Apache Kafka
2. RabbitMQ
3. ActiveMQ
4. Amazon MQ, Amazon SQS
5. Яндекс Message Queue (YMQ) - аналог Amazon
и другие.
Также для любого асинхронного взаимодействия можно добиться при помощи синхронных API с использованием механизмов:
1. WebHook
2. Polling
3. LongPolling
в сочетании с кронами, таймерами и воркерами.
Выбор технологии всегда будет зависеть не только от общей архитектуры системы и подходов к ней, но и от конкретного сценария, для которого предстоит делать реализацию.
#АрхитектураGA
Часто при разработке архитектуры начинают с простого: сервисы напрямую общаются друг с другом в реальном времени, используя синхронные вызовы, например через REST API, SOAP или gRPC.
Синхронное взаимодействие предполагает, что один сервис отправляет запрос другому и ждёт ответа.
Это удобно на старте, но по мере роста системы такое взаимодействие может создавать проблемы:
😬 высокую связанность,
😬 задержки в работе из-за высокой нагрузки на микросервис,
😬 или полное "падение" цепочки сервисов в алгоритме из-за сбоя одного из них.
С этими проблемами помогает справиться асинхронное взаимодействие, которое позволяет сервисам обмениваться сообщениями без ожидания ответа.
Асинхронное взаимодействие достигается за счёт использования очередей сообщений или публикации событий.
Ключевые преимущества такого решения:
👍 Развязка сервисов
Сервисы не зависят от доступности друг друга. Если один сервис временно недоступен, сообщения сохраняются в очереди и будут обработаны позже.
👍 Масштабируемость
Асинхронные системы легче масштабировать, так как взаимодействие сервисов не требует немедленного ответа.
👍 Отказоустойчивость
Если один из сервисов выходит из строя, система продолжает работать, а сообщения обрабатываются, когда сервис снова становится доступным.
Технологии, помогающие реализовать асинхронное взаимодействие:
1. Apache Kafka
2. RabbitMQ
3. ActiveMQ
4. Amazon MQ, Amazon SQS
5. Яндекс Message Queue (YMQ) - аналог Amazon
и другие.
Также для любого асинхронного взаимодействия можно добиться при помощи синхронных API с использованием механизмов:
1. WebHook
2. Polling
3. LongPolling
в сочетании с кронами, таймерами и воркерами.
Выбор технологии всегда будет зависеть не только от общей архитектуры системы и подходов к ней, но и от конкретного сценария, для которого предстоит делать реализацию.
#АрхитектураGA
👌17👍12❤7🔥5❤🔥3
🚀 Завершается запись на открытый урок по Архитектуре 🚀
Коллеги, кому актуально освоение навыков для middle+ и senior аналитиков - вам сюда!
Простыми словами, решая реальную задачу, разбираю тему:
💎 Проектирование архитектуры: от монолита к микросервисам
🗓 Доступ с 30 ноября до 2 декабря (СБ-ПН)
👉 Подробности и регистрация
В результате этого обучения:
🌟 Поймете основы проектирования архитектуры.
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов.
🌟 Научитесь проектировать архитектуру с нуля.
🌟 Узнаете, как происходит переезд с монолита на микросервисы.
🌟 Получите готовые схемы и подходы по проектированию.
Смотрите, перенимайте опыт, и применяйте в своей работе!⚡️
Коллеги, кому актуально освоение навыков для middle+ и senior аналитиков - вам сюда!
Простыми словами, решая реальную задачу, разбираю тему:
👉 Подробности и регистрация
В результате этого обучения:
🌟 Поймете основы проектирования архитектуры.
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов.
🌟 Научитесь проектировать архитектуру с нуля.
🌟 Узнаете, как происходит переезд с монолита на микросервисы.
🌟 Получите готовые схемы и подходы по проектированию.
Смотрите, перенимайте опыт, и применяйте в своей работе!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8😢2❤🔥1
Я много читаю. Это один из путей узнавать больше и самостоятельно учиться. В этом году мне попалась книга про публичные выступления TED от Кармин Галло.
TED это:
👉 25+млн подписчиков на YouTube
👉 Спикеры уровня Илон Маск, Билл Гейтс, и другие мировые личности.
Читала её, чтобы стать лучшей версией себя, и помогать коллегам, кто работает со мной.
И конечно, есть у меня мечта когда-то выступить на TED любого уровня 🤓
Для этого я:
+ Занимаюсь улучшением английского.
+ Хожу на занятия по публичным выступлениям.
+ Продолжаю карьеру и исследования в разработке ПО.
Всё ещё впереди.
Но почему-то знакомство с основателем местного TEDx (локальные TED в разных городах всего мира) происходит примерно на этой неделе 😄 Я пока не готова, но считаю это знаком Вселенной, что иду в правильном направлении.
На картинке к посту фото с моего планшета. Выделила цитаты из книги TED, которые рассказывают о моих ценностях:
О чем это?
Мне безумно приятно окружать себя людьми, которые жадные до знаний, ставят цели и постоянно растут. Я сама такая.
В GetAnalyst это 100%! Здесь вы, кому важно и нужно знать больше, быть лучше.
Даже комментировать не буду эту часть. Это взяли из моей головы.
Мне кажется, в этом и суть.
Если не пробовать, если не делать шаги вперёд, не стараться, всё остаётся на том же месте.
Знания, которые мы не получаем. Возможности, которые упускаем.
И жизнь, которая могла бы стать лучше, но.
Это не про деньги или время — это про веру в себя и в то, что ты можешь.
Ведь никто за нас ничего не сделает, к сожалению.
Только мы сами создаём то, что будет завтра.
Поэтому если есть идея. Есть желание. Есть цель. Пробуйте!
Не получается? Пробуйте еще!
В один момент все ваши попытки обернутся лучшими результатами!
TED это:
👉 25+млн подписчиков на YouTube
👉 Спикеры уровня Илон Маск, Билл Гейтс, и другие мировые личности.
Читала её, чтобы стать лучшей версией себя, и помогать коллегам, кто работает со мной.
И конечно, есть у меня мечта когда-то выступить на TED любого уровня 🤓
Для этого я:
+ Занимаюсь улучшением английского.
+ Хожу на занятия по публичным выступлениям.
+ Продолжаю карьеру и исследования в разработке ПО.
Всё ещё впереди.
Но почему-то знакомство с основателем местного TEDx (локальные TED в разных городах всего мира) происходит примерно на этой неделе 😄 Я пока не готова, но считаю это знаком Вселенной, что иду в правильном направлении.
На картинке к посту фото с моего планшета. Выделила цитаты из книги TED, которые рассказывают о моих ценностях:
Вы можете подарить кому-то идею.
Но что вы будете делать, если он не желает ее реализовывать?
Страсть человека к собственному росту — вот что важнее всего.
О чем это?
Мне безумно приятно окружать себя людьми, которые жадные до знаний, ставят цели и постоянно растут. Я сама такая.
В GetAnalyst это 100%! Здесь вы, кому важно и нужно знать больше, быть лучше.
А мы помогаем ему искать знания — ведь никто в мире не может добиться успеха в одиночку. Человеку с идеей может недоставать каких-то знаний, но знания можно получить».
Даже комментировать не буду эту часть. Это взяли из моей головы.
Мне кажется, в этом и суть.
Если не пробовать, если не делать шаги вперёд, не стараться, всё остаётся на том же месте.
Знания, которые мы не получаем. Возможности, которые упускаем.
И жизнь, которая могла бы стать лучше, но.
Это не про деньги или время — это про веру в себя и в то, что ты можешь.
Ведь никто за нас ничего не сделает, к сожалению.
Только мы сами создаём то, что будет завтра.
Поэтому если есть идея. Есть желание. Есть цель. Пробуйте!
Не получается? Пробуйте еще!
В один момент все ваши попытки обернутся лучшими результатами!
❤41🔥9👍5👏3💯2
GetAnalyst_Очередь_сообщений_что_это_и_как_работает.pdf
5.5 MB
Очередь сообщений — это структура данных, которая хранит сообщения или пакеты данных до тех пор, пока их не заберёт получатель для последующей обработки.
Очередь сообщений выделяют как отдельный компонент на схеме архитектуры, на таком же уровне, как и связанные с ней сервисы, которые:
✔️ Публикуют в неё сообщения (Producer).
✔️ Читают и обрабатывают сообщения из неё (Consumer).
Подробнее про очереди сообщений можно узнать в мини-книге, прикрепленной к посту 🙂
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
👍39❤14🔥11🤔2😁1
💬 Очередь сообщений VS Брокер сообщений 💬
Очередь сообщений — это структура данных, которая хранит сообщения до тех пор, пока их не заберёт получатель.
Брокер сообщений — это программное обеспечение, которое управляет обменом сообщений между приложениями. Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.
❗️Вопросы с подвохом:
👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
Очередь сообщений — это только структура данных для хранения сообщений, а брокер сообщений предоставляет дополнительные функции, такие как:
+ Управление множеством очередей.
+ Маршрутизация сообщений.
+ Поддержка нескольких потребителей.
Брокер — это более комплексная система, в состав которой входят очереди.
👉 2. Может ли очередь работать без брокера?
Да, тогда это будет просто временное хранилище сообщений.
👉 3. Могу ли я использовать брокер без очередей сообщений?
Нет. Очереди — одна из базовых составляющих большинства брокеров. Однако брокеры предоставляют более широкую функциональность, например, топики для публикации/подписки, что выходит за рамки простых очередей.
👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
Не всегда. Очередь сообщений сама по себе не гарантирует доставку, если нет спец. механизмов. Брокер сообщений, с другой стороны, предоставляет такие функции, как подтверждение доставки и повторная доставка сообщений в случае сбоя.
👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
Нет, не всегда. Хотя FIFO — это распространённый механизм, очереди могут быть:
+ Приоритетными (Priority Queue): Сообщения с высоким приоритетом обрабатываются первыми.
+ LIFO (Last In, First Out): Последнее сообщение обрабатывается первым.
и другие.
👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Технически да, но это усложняет реализацию, если очередь реализована без брокера.
#АрхитектураGA
Очередь сообщений — это структура данных, которая хранит сообщения до тех пор, пока их не заберёт получатель.
Брокер сообщений — это программное обеспечение, которое управляет обменом сообщений между приложениями. Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.
❗️Вопросы с подвохом:
👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
Очередь сообщений — это только структура данных для хранения сообщений, а брокер сообщений предоставляет дополнительные функции, такие как:
+ Управление множеством очередей.
+ Маршрутизация сообщений.
+ Поддержка нескольких потребителей.
Брокер — это более комплексная система, в состав которой входят очереди.
👉 2. Может ли очередь работать без брокера?
Да, тогда это будет просто временное хранилище сообщений.
👉 3. Могу ли я использовать брокер без очередей сообщений?
Нет. Очереди — одна из базовых составляющих большинства брокеров. Однако брокеры предоставляют более широкую функциональность, например, топики для публикации/подписки, что выходит за рамки простых очередей.
👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
Не всегда. Очередь сообщений сама по себе не гарантирует доставку, если нет спец. механизмов. Брокер сообщений, с другой стороны, предоставляет такие функции, как подтверждение доставки и повторная доставка сообщений в случае сбоя.
👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
Нет, не всегда. Хотя FIFO — это распространённый механизм, очереди могут быть:
+ Приоритетными (Priority Queue): Сообщения с высоким приоритетом обрабатываются первыми.
+ LIFO (Last In, First Out): Последнее сообщение обрабатывается первым.
и другие.
👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Технически да, но это усложняет реализацию, если очередь реализована без брокера.
#АрхитектураGA
👍49❤4🔥1
Брокер сообщений — это программное обеспечение, которое управляет обменом сообщениями между приложениями, сервисами или системами.
Брокеры сообщений могут валидировать, хранить, маршрутизировать и доставлять сообщения в нужные сервисы.
Они выполняют роль посредников между различными сервисами, позволяя отправителям отправлять сообщения, не зная:
▫️ где находятся получатели,
▫️ активны ли они в данный момент,
▫️ сколько их.
Для обеспечения надёжного хранения сообщений и гарантированной доставки, брокеры сообщений часто используют компонент, называемый очередью сообщений.
Очередь хранит и упорядочивает сообщения до тех пор, пока потребляющие приложения не смогут их обработать. В ней сообщения обычно хранятся в том порядке, в котором они были переданы от отправителя (Producer), и остаются там до подтверждения их получения получателем (Consumer).
Брокеры сообщений предлагают два основных паттерна (шаблона) обмена данными:
1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.
2. Публикация-подписка (Publish/Subscribe Messaging)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.
Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.
Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.
#АрхитектураGA
Брокеры сообщений могут валидировать, хранить, маршрутизировать и доставлять сообщения в нужные сервисы.
Они выполняют роль посредников между различными сервисами, позволяя отправителям отправлять сообщения, не зная:
▫️ где находятся получатели,
▫️ активны ли они в данный момент,
▫️ сколько их.
Для обеспечения надёжного хранения сообщений и гарантированной доставки, брокеры сообщений часто используют компонент, называемый очередью сообщений.
Очередь хранит и упорядочивает сообщения до тех пор, пока потребляющие приложения не смогут их обработать. В ней сообщения обычно хранятся в том порядке, в котором они были переданы от отправителя (Producer), и остаются там до подтверждения их получения получателем (Consumer).
Брокеры сообщений предлагают два основных паттерна (шаблона) обмена данными:
1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.
2. Публикация-подписка (Publish/Subscribe Messaging)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.
Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.
Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.
#АрхитектураGA
❤30👍21❤🔥5
🔲 Про брокер Kafka 🔲
Kafka — это:
1. Брокер сообщений: Kafka позволяет приложениям обмениваться данными, как через очереди сообщений.
2. Платформа потоковой обработки: Она не только пересылает данные, но и позволяет обрабатывать их в реальном времени.
3. Хранилище событий: Kafka может сохранять данные длительное время, что делает её подходящей для анализа и аудита.
👉 Kafka состоит из следующих ключевых компонентов:
◽️ Producer (Производитель)
Приложение, которое отправляет данные (сообщения) в Kafka.
Пример: Сервис интернет-магазина отправляет данные о новых заказах.
◽️ Broker (Брокер)
Узел (сервер) в кластере Kafka, который обрабатывает сообщения.
В кластере может быть несколько брокеров, чтобы обеспечить масштабируемость и отказоустойчивость.
◽️ Topic (Топик)
Логическое место, куда отправляются сообщения.
Сообщения в топике упорядочены и распределены по разделам (partitions).
◽️ Partition (Раздел)
Каждый топик делится на разделы (partitions).
Сообщения в разделе упорядочены (по времени или оффсету).
◽️ Consumer (Потребитель)
Приложение, которое читает данные из топика.
Может быть несколько потребителей, объединённых в группы.
◽️ ZooKeeper (или KRaft)
Система координации, которая управляет метаданными Kafka. В новых версиях ZooKeeper заменён на собственный механизм KRaft.
👉 Особенности Kafka
➕ Высокая производительность: Kafka может обрабатывать миллионы сообщений в секунду.
➕ Масштабируемость: Кластер Kafka можно масштабировать, добавляя новые брокеры.
➕ Долговременное хранение:
Сообщения сохраняются в Kafka на заданное время или пока не удалены вручную.
➕ Устойчивость к сбоям:
Репликация разделов (partitions) между брокерами обеспечивает отказоустойчивость.
#АрхитектураGA
Продолжение завтра 👇
Kafka — это:
1. Брокер сообщений: Kafka позволяет приложениям обмениваться данными, как через очереди сообщений.
2. Платформа потоковой обработки: Она не только пересылает данные, но и позволяет обрабатывать их в реальном времени.
3. Хранилище событий: Kafka может сохранять данные длительное время, что делает её подходящей для анализа и аудита.
👉 Kafka состоит из следующих ключевых компонентов:
◽️ Producer (Производитель)
Приложение, которое отправляет данные (сообщения) в Kafka.
Пример: Сервис интернет-магазина отправляет данные о новых заказах.
◽️ Broker (Брокер)
Узел (сервер) в кластере Kafka, который обрабатывает сообщения.
В кластере может быть несколько брокеров, чтобы обеспечить масштабируемость и отказоустойчивость.
◽️ Topic (Топик)
Логическое место, куда отправляются сообщения.
Сообщения в топике упорядочены и распределены по разделам (partitions).
◽️ Partition (Раздел)
Каждый топик делится на разделы (partitions).
Сообщения в разделе упорядочены (по времени или оффсету).
◽️ Consumer (Потребитель)
Приложение, которое читает данные из топика.
Может быть несколько потребителей, объединённых в группы.
◽️ ZooKeeper (или KRaft)
Система координации, которая управляет метаданными Kafka. В новых версиях ZooKeeper заменён на собственный механизм KRaft.
👉 Особенности Kafka
➕ Высокая производительность: Kafka может обрабатывать миллионы сообщений в секунду.
➕ Масштабируемость: Кластер Kafka можно масштабировать, добавляя новые брокеры.
➕ Долговременное хранение:
Сообщения сохраняются в Kafka на заданное время или пока не удалены вручную.
➕ Устойчивость к сбоям:
Репликация разделов (partitions) между брокерами обеспечивает отказоустойчивость.
#АрхитектураGA
Продолжение завтра 👇
👍41❤12🔥10
👉 Алгоритм работы Kafka
1. Producer отправляет сообщение в определённый топик, разделы которого распределены по брокерам.
2. Kafka сохраняет сообщение.
Сообщение записывается в раздел топика и сохраняется на диске.
3. Consumer подключается к Kafka, выбирает топик и читает сообщения из нужного раздела.
👉 Kafka поддерживает несколько моделей доставки:
+ Сообщение доставляется максимум один раз.
+ Сообщение может быть доставлено несколько раз (с гарантией доставки).
+ Сообщение доставляется ровно один раз.
👉 Примеры использования Kafka:
Финансовые транзакции
1. Банковские системы отправляют транзакции в Kafka.
2. Сервисы банка получают и обрабатывают транзакции в реальном времени с высокой степенью надежности.
Централизованная система уведомлений
1. Разные сервисы системы отправляют уведомления в Kafka.
2. Отдельные сервис Уведомлений получает их для отправки email, SMS и push через интеграции.
👉 Проблемы Kafka
➖ Нуждается в хорошей настройке (особенно при больших объёмах данных).
➖ Не всегда оптимальна для задач с малым количеством данных.
👉 Почему выбирают
Kafka выделяется среди других решений по брокерам благодаря своей надёжности и способности обрабатывать огромные объёмы данных. Это делает её оптимальным выбором для высоконагруженных систем.
🔎 Я только начинаю знакомство с Kafka? Что делать?
Я бы рекомендовала начать с изучения официальной документации Kafka (не стесняемся пользоваться Google Translate или ChatGPT для переводов) или книги Kafka Streams в действии.
#АрхитектураGA
1. Producer отправляет сообщение в определённый топик, разделы которого распределены по брокерам.
2. Kafka сохраняет сообщение.
Сообщение записывается в раздел топика и сохраняется на диске.
3. Consumer подключается к Kafka, выбирает топик и читает сообщения из нужного раздела.
👉 Kafka поддерживает несколько моделей доставки:
+ Сообщение доставляется максимум один раз.
+ Сообщение может быть доставлено несколько раз (с гарантией доставки).
+ Сообщение доставляется ровно один раз.
👉 Примеры использования Kafka:
Финансовые транзакции
1. Банковские системы отправляют транзакции в Kafka.
2. Сервисы банка получают и обрабатывают транзакции в реальном времени с высокой степенью надежности.
Централизованная система уведомлений
1. Разные сервисы системы отправляют уведомления в Kafka.
2. Отдельные сервис Уведомлений получает их для отправки email, SMS и push через интеграции.
👉 Проблемы Kafka
➖ Нуждается в хорошей настройке (особенно при больших объёмах данных).
➖ Не всегда оптимальна для задач с малым количеством данных.
👉 Почему выбирают
Kafka выделяется среди других решений по брокерам благодаря своей надёжности и способности обрабатывать огромные объёмы данных. Это делает её оптимальным выбором для высоконагруженных систем.
🔎 Я только начинаю знакомство с Kafka? Что делать?
Я бы рекомендовала начать с изучения официальной документации Kafka (не стесняемся пользоваться Google Translate или ChatGPT для переводов) или книги Kafka Streams в действии.
#АрхитектураGA
👍31❤10❤🔥3👏1😁1
GetAnalyst Kafka примеры использования.pdf
7 MB
👀 Пример использования Kafka в #FarmFreshGA 👀
На примере реальных задач давайте разберемся, как можно использовать брокер Kafka для асинхронного взаимодействия - фонового выполнения задач.
Примеры:
1. SMS после регистрации пользователя
2. фоновые задачи после оплаты заказа
Алгоритмы с картинками в прикрепленном файле 🤝
#АрхитектураGA
На примере реальных задач давайте разберемся, как можно использовать брокер Kafka для асинхронного взаимодействия - фонового выполнения задач.
Примеры:
1. SMS после регистрации пользователя
2. фоновые задачи после оплаты заказа
Алгоритмы с картинками в прикрепленном файле 🤝
#АрхитектураGA
👍26❤5🔥2
📚 Моделирование архитектуры в нотации С4 📚
Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично! Первый шаг к пониманию работы системы сделан.
Но если мы работаем со сложной архитектурой, то в некоторых моментах будут вопросы, и автора "картины" можно понять по-разному.
Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией C4, где есть несколько уровней описания системы, которые помогают понять её 🙂
📚C4 - нотация моделирования архитектуры, которая упрощает визуализацию сложных систем.
Она помогает архитекторам, разработчикам и системным аналитикам представлять архитектуру в виде четырех абстракций:
👉 Контекст (C4 / Context) - система, её интеграции и пользователи.
👉 Контейнеры (C4 / Container) - независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.
👉 Компоненты (C4 / Component) - модули кода и зависимости между ними, детализирует один из контейнеров с C4 / Container.
👉 Код (C4 / Code) - описывает реализацию кода для конкретных компонентов системы, детализирует C4 / Component.
Материалы для быстрого самостоятельного изучения C4:
🔗 Официальный сайт C4 (англ)
🔗 Шаблон с примером архитектуры в Miro
🔗 Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты
#АрхитектураGA
Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично! Первый шаг к пониманию работы системы сделан.
Но если мы работаем со сложной архитектурой, то в некоторых моментах будут вопросы, и автора "картины" можно понять по-разному.
Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией C4, где есть несколько уровней описания системы, которые помогают понять её 🙂
📚C4 - нотация моделирования архитектуры, которая упрощает визуализацию сложных систем.
Она помогает архитекторам, разработчикам и системным аналитикам представлять архитектуру в виде четырех абстракций:
👉 Контекст (C4 / Context) - система, её интеграции и пользователи.
👉 Контейнеры (C4 / Container) - независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.
👉 Компоненты (C4 / Component) - модули кода и зависимости между ними, детализирует один из контейнеров с C4 / Container.
👉 Код (C4 / Code) - описывает реализацию кода для конкретных компонентов системы, детализирует C4 / Component.
Материалы для быстрого самостоятельного изучения C4:
🔗 Официальный сайт C4 (англ)
🔗 Шаблон с примером архитектуры в Miro
🔗 Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты
#АрхитектураGA
👍31🔥8❤5⚡3👏1
🔵 Sructurizr - один из основных инструментов, который позволяет создавать схемы архитетуры в нотации C4 через код 🔵
В этой статье я показывала примеры кода для одного из демо-проектов, которые ранее разбирались в канале GetAnalyst.
P.S. В нем уровень контейнеров для Backend у меня упрощен.
Сейчас я хочу предложить вам познакомиться с архитектурой в C4 и кодом Sructurizr для проекта #FarmFreshGA и посмотреть на пару уровней, согласно официальным требованиям нотации по визуализации архитектуры.
👉 Уровень Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние системы
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам.
👉 Контейнеры (C4 / Container)
Независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
Схемы в виде скрина из Structurizr прикрепрены к посту.
Исходный код для вставки в Structurizr:
🔗 ссылка на файл с кодом
#АрхитектураGA
В этой статье я показывала примеры кода для одного из демо-проектов, которые ранее разбирались в канале GetAnalyst.
P.S. В нем уровень контейнеров для Backend у меня упрощен.
Сейчас я хочу предложить вам познакомиться с архитектурой в C4 и кодом Sructurizr для проекта #FarmFreshGA и посмотреть на пару уровней, согласно официальным требованиям нотации по визуализации архитектуры.
👉 Уровень Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние системы
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам.
👉 Контейнеры (C4 / Container)
Независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
Схемы в виде скрина из Structurizr прикрепрены к посту.
Исходный код для вставки в Structurizr:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25❤4
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
💚 DDD и Event Storming - архитектура для системного аналитика 💚
В этом эпизоде мы рассказываем об архитектуре систем, а именно о двух мощных инструментах, которые могут существенно изменить подход системного аналитика к проектированию сложных систем: Domain Driven Design (DDD) и Event Storming.
Мы обсудим, почему эти подходы становятся всё более популярными, как их правильно применять и каких ошибок стоит избегать. Вы узнаете, как Event Storming помогает разложить сложные процессы на отдельные события, почему это важно для проектирования архитектуры и как использовать эти инструменты в новых проектах и при пересмотре существующих решений.
🔗 Сайт эпизода
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Следите за подкастом, чтобы регулярно получать новый опыт и знания в системном анализе 😉
В этом эпизоде мы рассказываем об архитектуре систем, а именно о двух мощных инструментах, которые могут существенно изменить подход системного аналитика к проектированию сложных систем: Domain Driven Design (DDD) и Event Storming.
Мы обсудим, почему эти подходы становятся всё более популярными, как их правильно применять и каких ошибок стоит избегать. Вы узнаете, как Event Storming помогает разложить сложные процессы на отдельные события, почему это важно для проектирования архитектуры и как использовать эти инструменты в новых проектах и при пересмотре существующих решений.
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Следите за подкастом, чтобы регулярно получать новый опыт и знания в системном анализе 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤4👍2🤔1
Так сложилось, что день рождения у меня перед Новым годом. Ровно за неделю до него.
Новый год жизни, новый год в календаре. Это всегда время подведения итогов и постановки новых целей.
Обычно я подвожу черту 31 декабря.
Это отдельная задача в плане:
- в полном одиночестве,
- 2-3 часа с ручкой и тетрадкой в руках,
- проверяю достижения по записанным в неё целям и пишу новые.
А вот в день рождения я почти всегда работаю.
Минимум 4 часа, а иногда и все 10.
Но в этом году я хочу сделать что-то иначе — устроить небольшой отпуск.
Не на 100%, но хотя бы его подобие.
Хочу отдохнуть и отпраздновать день рождения.
Хочу сначала набраться сил, а потом подводить итоги прошедшего года и ставить новые цели.
Мне нужна перезарядка. Я хочу войти в Новый год радостной и счастливой.
Только так я смогу сделать еще больше для себя и для вас.
Поэтому с 25 декабря по 8 января я в отпуске🎄
Но... В этом году я всё же планирую выйти к вам в прямой эфир. У меня есть идея практикума по интеграциям, а также эпизод подкаста, где я расскажу о самой популярной задаче на собеседованиях для системных аналитиков. Ну и, конечно, посты на время отпуска сами себя не напишут...
Поэтому в ближайшие две недели буду работать на мощности х4, чтобы успеть всё до 25 декабря.
На предстоящей неделе будут три важных анонса.
И я буду очень рада, если вы поддержите мой отпуск ❤️🔥🦄 под постом.
Берегите и цените себя.
Вы — самый важный человек в своей жизни.
Если чувствуете усталость и нуждаетесь в перезагрузке, позвольте себе отдохнуть. Это действительно важно.
Мы все хотим быть лучшей версией себя и успевать больше.
Но чтобы двигаться вперёд, иногда нужно остановиться и сделать паузу 🙌
Новый год жизни, новый год в календаре. Это всегда время подведения итогов и постановки новых целей.
Обычно я подвожу черту 31 декабря.
Это отдельная задача в плане:
- в полном одиночестве,
- 2-3 часа с ручкой и тетрадкой в руках,
- проверяю достижения по записанным в неё целям и пишу новые.
А вот в день рождения я почти всегда работаю.
Минимум 4 часа, а иногда и все 10.
Но в этом году я хочу сделать что-то иначе — устроить небольшой отпуск.
Не на 100%, но хотя бы его подобие.
Хочу отдохнуть и отпраздновать день рождения.
Хочу сначала набраться сил, а потом подводить итоги прошедшего года и ставить новые цели.
Мне нужна перезарядка. Я хочу войти в Новый год радостной и счастливой.
Только так я смогу сделать еще больше для себя и для вас.
Поэтому с 25 декабря по 8 января я в отпуске
Но... В этом году я всё же планирую выйти к вам в прямой эфир. У меня есть идея практикума по интеграциям, а также эпизод подкаста, где я расскажу о самой популярной задаче на собеседованиях для системных аналитиков. Ну и, конечно, посты на время отпуска сами себя не напишут...
Поэтому в ближайшие две недели буду работать на мощности х4, чтобы успеть всё до 25 декабря.
На предстоящей неделе будут три важных анонса.
И я буду очень рада, если вы поддержите мой отпуск ❤️🔥🦄 под постом.
Берегите и цените себя.
Вы — самый важный человек в своей жизни.
Если чувствуете усталость и нуждаетесь в перезагрузке, позвольте себе отдохнуть. Это действительно важно.
Мы все хотим быть лучшей версией себя и успевать больше.
Но чтобы двигаться вперёд, иногда нужно остановиться и сделать паузу 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤107🔥35🦄20👍3🎉3😁1👌1
GetAnalyst_Интеграции_мини_книга_для_БА_и_СА.pdf
10.7 MB
Интеграция — это процесс объединения разных систем и приложений, чтобы они могли работать вместе, обмениваться данными и выполнять задачи, как единая система.
Пример:
Если эти системы не связаны между собой, то сотрудники вынуждены вручную выполнять множество задач, связанных с общим учетом заказов и передачей их на кухню для приготовления.
В общем много ручной работы, в которой может быть очень много ошибок 🥲
Интеграция систем решает эту проблему, связывая их так, чтобы они автоматически обменивались информацией и выполняли общие задачи.
Основные способы интеграции:
▫️ API и Библиотеки
▫️ Очереди сообщений и брокеры
▫️ Файлы
▫️ Общая БД
📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.
Файл прикреплен к посту.
Загружайте и погружайтесь в тему глубже 🧩
#ИнтеграцииGA
Пример:
Представим ресторан, где работают несколько отдельных систем:
🔹 для обработки заказов кухней и управления данными об остатках продуктов в ресторане,
🔹 для приема заказов внутри ресторана и проведения оплаты за них,
🔹 для приема заказов на доставку.
Если эти системы не связаны между собой, то сотрудники вынуждены вручную выполнять множество задач, связанных с общим учетом заказов и передачей их на кухню для приготовления.
Получается, что без интеграций:
1. Официантам и администраторам приходится вручную передавать данные между системами, чтобы учесть все заказы и передать их на кухню для приготовления.
2. Заказы на доставку при ручном переносе могут путать с заказами в зале, из-за чего доставка задерживается или блюда уходят не тем клиентам.
3. При получении каждого готового заказа с кухни на доставку, надо вручную отмечать готовность заказа в системе доставки.
4. Тяжело оценивать загруженность кухни из-за отсутствия общих данных по заказам в зале и на доставку. Нет возможности сразу сообщить тем, кто заказывает доставку онлайн, что в "час-пик" время ожидания заказа будет увеличено.
В общем много ручной работы, в которой может быть очень много ошибок 🥲
Интеграция систем решает эту проблему, связывая их так, чтобы они автоматически обменивались информацией и выполняли общие задачи.
Основные способы интеграции:
▫️ API и Библиотеки
▫️ Очереди сообщений и брокеры
▫️ Файлы
▫️ Общая БД
📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.
Файл прикреплен к посту.
Загружайте и погружайтесь в тему глубже 🧩
#ИнтеграцииGA
❤25🔥14👍2
🥳 Новый проект #EventTasksGA: разбор интеграционной задачи для собеседований на СА 🥳
Интеграции - одна из самых актуальных и важных тем для системных аналитиков.
На собеседованиях этот навык проверяют по-разному: задают теоретические вопросы или дают практическую задачу, чтобы оценить глубину знаний и умение применять их на практике.
В этом месяце мы будем разбирать задачу, которая проверяет знания системного аналитика на все 100%: насколько он понимает интеграционные процессы и умеет работать с такими задачами.
🟢 Задача на Интеграцию:
Платформа для заказа организации мероприятий #EventTasksGA.
🟢 Процесс:
1. Клиент оформляет заказ.
2. Заказ, оформленный через сайт или мобильное приложение, обрабатывается менеджером в CRM-системе платформы.
3. Менеджер вручную создает проект в таск-трекере Todoist, где формируется стандартный набор задач в зависимости от тарифа и вида мероприятия.
4. После завершения мероприятия формируется акт выполненных работ.
🟢 Нужно автоматизировать:
1. При поступлении заказа автоматически создавать проект в Todoist и задачи по нему.
2. Автоматически назначать ответственного организатора за проект.
3. Передавать информацию о выполнении проекта в основную платформу, чтобы на ее основе формировался акт выполненных работ.
🟢 Задачи системного аналитика:
1. Спланировать работы по интеграции с системой Todoist.
2. Показать архитектуру решения.
3. Описать логику работы: автоматическое создание проекта и формирование акта выполненных работ.
4. Сформировать требования для REST API-методов, необходимых для интеграции.
🟢 Что дополнительно можно спросить у кандидата на собеседовании:
+ принципы проектирования БД,
+ понимание Backend и Frontend,
+ особенности использования различных API в проекте,
+ понимание принципов асинхронного взаимодействия.
Мы будем последовательно разбирать эту задачу в декабре!
Добро пожаловать в наш новый проект-собеседование!
Чтобы участвовать, достаточно быть подписанными на наш канал и ежедневно следить за обновлениями 😉
#ИнтеграцииGA
Интеграции - одна из самых актуальных и важных тем для системных аналитиков.
На собеседованиях этот навык проверяют по-разному: задают теоретические вопросы или дают практическую задачу, чтобы оценить глубину знаний и умение применять их на практике.
В этом месяце мы будем разбирать задачу, которая проверяет знания системного аналитика на все 100%: насколько он понимает интеграционные процессы и умеет работать с такими задачами.
🟢 Задача на Интеграцию:
Платформа для заказа организации мероприятий #EventTasksGA.
🟢 Процесс:
1. Клиент оформляет заказ.
2. Заказ, оформленный через сайт или мобильное приложение, обрабатывается менеджером в CRM-системе платформы.
3. Менеджер вручную создает проект в таск-трекере Todoist, где формируется стандартный набор задач в зависимости от тарифа и вида мероприятия.
4. После завершения мероприятия формируется акт выполненных работ.
🟢 Нужно автоматизировать:
1. При поступлении заказа автоматически создавать проект в Todoist и задачи по нему.
2. Автоматически назначать ответственного организатора за проект.
3. Передавать информацию о выполнении проекта в основную платформу, чтобы на ее основе формировался акт выполненных работ.
🟢 Задачи системного аналитика:
1. Спланировать работы по интеграции с системой Todoist.
2. Показать архитектуру решения.
3. Описать логику работы: автоматическое создание проекта и формирование акта выполненных работ.
4. Сформировать требования для REST API-методов, необходимых для интеграции.
🟢 Что дополнительно можно спросить у кандидата на собеседовании:
+ принципы проектирования БД,
+ понимание Backend и Frontend,
+ особенности использования различных API в проекте,
+ понимание принципов асинхронного взаимодействия.
Мы будем последовательно разбирать эту задачу в декабре!
Добро пожаловать в наш новый проект-собеседование!
Чтобы участвовать, достаточно быть подписанными на наш канал и ежедневно следить за обновлениями 😉
#ИнтеграцииGA
❤🔥41❤23🔥12👍10