🔔🤖 Как эффективно использовать AI для проектирования БД и SQL-запросов [сегодня, в 19:00 Мск] 🤖🔔

Хотите научиться работать с AI без хаоса, с продуманной стратегией промптов? Этот онлайн-практикум для вас!


🤖 Использование AI для проектирования БД + SQL
🗓 17 ноября [пн]
🕘 19:00 - 21:30 МСК

🔗 Подробности и запись

Занятие проводится в рамках подписки на практикумы по БД и SQL. Участи платное - от 1390 руб.


✅ Запись будет доступна на следующий день после занятия.

🎁 Дополнительно получаете занятие в записи по SQL, с практикой в реальной БД через DBeaver 😎


👉План практикума:

⚪ Часть 1 - видео-уроки в платформе
1. Обзор нейросетей
2. Промпт-инжиниринг
3. Работа с AI: физическая модель для PostgreSQL, ER-диаграммы, создание реальной БД через SQL-скрипты

🟢 Часть 2 - онлайн-практика
1. Закрепление материала из видео-уроков и обсуждение вопросов
2. Разработка SQL-запросов с AI - практика
3. Особенности работы с AI


👉 В результате:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с БД.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.
✔️ Узнаете требования к соблюдению безопасности и особенности взаимодействия с AI.


По вопросам можно писать через сайт или @getanalyst 💬


До встречи в прямом эфире! 🙌

🔎 5 способов выделения микросервисов 🔎

Микросервисы (МС) — это способ разбить большую систему на независимые, слабо связанные компоненты, каждый из которых отвечает имеет свою функциональную зону ответственности и релизится/масштабируется отдельно.

Другими словами — это небольшие сервер-приложения с их собственными БД.


Ниже — 5 ключевых подходов к декомпозиции сложной системы на микросервисы на примере проекта по доставке еды из ресторанов #FoodDeliveryGA 👇

-----------

1️⃣ По группам функций
Каждый МС объединяет логически связанные функции.

🔹 Управление пользователями
Регистрация, управление профилем, настройка избранных адресов доставки, настройки уведомлений.

🔹 Ведение справочника ресторанов
Управление ресторанами, статусом “онлайн/офлайн”, графиком работы, зонами доставки.

🔹 Ведение меню
Управление блюдами, модификаторами (доп.сыр, острый соус и др), размерами порций, доступностью позиций.

🔹 Работа с заказами
Создание заказа, статусы (принят, готовится, в доставке, доставлен, отменён), история заказов.

🔹 Доставка заказа
Назначение курьера, статусы (свободен, едет в ресторан, везёт заказ), геолокация.

🔹 Оплата заказа
Онлайн-оплата, статусы транзакций, возвраты, фискальные чеки, отчётность.

🔹 Рассылка уведомлений
Push/SMS/email-уведомления пользователям, ресторанам и курьерам по ключевым событиям.

-----------

2️⃣ По доменам (DDD - Domain Driven Design)
Выделяем bounded contexts (ограниченные контексты) по предметным областям.

🔹 Домен “Заказы”
Формирование заказов, статусы, бизнес-правила (минимальная сумма, время закрытия кухни, ограничения по району).

🔹 Домен “Рестораны и меню”:
Справочник ресторанов, витрина меню, управление доступностью блюд.

🔹 Домен “Логистика”
Маршрутизация курьеров, расчёт времени доставки, распределение заказов между курьерскими службами.

🔹 Домен “Платежи”
Интеграции с платёжными провайдерами, авторизация/списание, возвраты, финансы и отчёты.

🔹 Домен “Пользователи”
Профили, адреса, история заказов, избранные рестораны и блюда.

🔹 Домен “Лояльность”
Управление скидками, акциями и промокодами.

-----------

3️⃣ По данным
Каждый МС управляет узким набором сущностей.

🔹 Пользователи:
телефоны/email, избранные адреса, предпочтения.

🔹 Заказы:
состав заказа (позиции + модификаторы), суммы, статусы, временные метки.

🔹 Платежи:
транзакции, статусы оплат, идентификаторы операций у платёжных провайдеров.

-----------

4️⃣ По пользовательским сценариям
МС обслуживает конкретный Use Case.

🔹 Оформление заказа
Поиск ресторана, выбор блюд и модификаторов, расчёт стоимости, применение промокодов, выбор способа оплаты.

🔹 Приём и обработка заказа рестораном
Подтверждение/отмена, учёт закрытой кухни, недоступности блюд, времени готовки.

🔹 Доставка
Назначение курьера, трекинг заказа на карте, смена статусов, уведомления пользователю.

🔹 Поддержка
Обработка обращений: заказ опоздал, блюдо не привезли, неверный чек и т.д.

-----------

5️⃣ По уровню нагрузки
Высоконагруженные и обычные части системы выделяются в отдельные сервисы со своими SLA и требованиями к масштабируемости.

🔹 Каталог ресторанов и меню
Массовые чтения (поиск, фильтры, рекомендации), особенно в пиковые часы (обед, вечер, пятница).

🔹 Создание и трекинг заказов
Постоянные изменения статусов, обновления на экране пользователя в реальном времени.

🔹 Логистика/геолокация
Много запросов на обновление координат курьеров и расчёт ETA.

🔹 Платежи
Пиковые нагрузки при акциях и распродажах, повышенные требования к отказоустойчивости.

-----------

Список микросервисов по каждой категории можно продолжить.

Как видно из примеров, разные подходы к декомпозиции могут приводить к похожему набору микросервисов. На практике их часто используют совместно.

👉 Сочетайте способы декомпозиции и фиксируйте принципы выделения новых микросервисов в архитектурной документации проекта.

Это поможет избежать неясностей и обеспечит гибкость при развитии проекта 🚀


#АрхитектураGA

✨ API Gateway и 10 его главных функций: практическое руководство для аналитиков и архитекторов ✨

🔗 Полный гайд по API Gateway

API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.

Обычно используется в микросервисной архитектуре.

👉 Его главная функция — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.


Как он работает:

1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.

2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.

3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.

4️⃣ Аутентификация и авторизация
Проверяет токены и другие учетные данные. Гарантирует, что у клиента есть необходимые разрешения для доступа к запрашиваемым ресурсам.

5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.

6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков, API-шлюз определяет, какому микросервису должен быть направлен запрос.

7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.

8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.

9️⃣ Возврат ответа клиенту

🔟 Логирование, мониторинг, обработка ошибок и кэширование


API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.

Про API Gateway с картинками и реальными примерами использования:
🔗 Полный гайд по API Gateway

#АрхитектураGA

👩‍💻 8 Шаблонов Проектирования Микросервисов 👩‍💻

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌


Исходник: png | svg (анимация)

#АрхитектураGA

⚙️📞 Camunda и BPMN в микросервисах: успешный кейс для оркестрации процессов техподдержки ⚙️📞

Если вы рассматриваете Camunda для внедрения на проект и пытаетесь понять, «а оно нам точно надо?», или хотите разобраться как работает оркестрация процессов в микросервисной архитектуре — этот эпизод для вас.

🔗 Статья к эпизоду
(внутри доп. материалы и ссылки по Camunda и BPMN)

Обсуждаем реальный опыт внедрения Camunda на действующем высоконагруженном проекте со старшим системным аналитиком.

Рассказываем, где Camunda реально помогает развивать и поддерживать систему, а где добавляет новые головные боли. Когда стоит выбирать Camunda, а когда лучше пойти другим путём.

Слушайте, делайте заметки и делитесь с коллегами!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


✅ Подписывайтесь на GetAnalyst — ваша база знаний в мире системного анализа и архитектуры!

🧩 Пример архитектуры микросервисов с API Gateway, где он - точка отказа 🚫

На этой неделе опубликовала подробный гайд по API Gateway.

Теперь показываю первую версию схемы архитектуры для проекта доставки еды #FoodDeliveryGA.

На ней вы можете увидеть, что все Frontend-приложения ходят к Backend через API Gateway, а уже за ним целый зоопарк микросервисов.

И вот тут начинают всплывать интересные вопросы...

Как реализовывать сложные процессы, в которых нужно несколько микросервисов?

🔎 Представим типичный сценарий - успешная оплата заказа

После того как платёж прошёл на сервисе платежей, система должна:
1. На Сервисе Заказов поменять статус заказа на «оплачен»
2. Отправить уведомление ресторану о новом заказе - сервис Уведомлений
3. Отправить уведомление пользователю, что заказ оплачен и ушёл в работу - сервис Уведомлений
4. На сервис курьеров отправить запрос на поиск курьера и завершить процесс обработки платежа, не дожидаясь нахождения курьера
5. После всех этих действий показываем пользователю экран "оплачено" на frontend


Если у нас есть только API Gateway:

👉 Либо все микросервисы начинают общаться между собой через него - точка отказа будет знатная

👉 Либо разрешаем микросервисам вызывать друг-друга напрямую
Звучит нормально… до первой диаграммы с прямыми интеграциями, когда появится паутина стрелок в дополнение к существующим 🕸️
Такую схему сложно не только читать, но и поддерживать в реальном проекте. Любое изменение бизнес-процесса = новая порция хаоса в связях между сервисами

👉 Либо мы можем добавить внутренний API Gateway Internal для взаимодействий между сервисами. Но в бизнес-процессах есть фоновые (асинхронные) задачи, параллельность, необходимость откатов и повторных попыток в случае ошибок. API Gateway не должен управлять логикой процессов, это не его функция


Поэтому в микросервисной архитектуре обычно сочетают подходы:
API Gateway + Хореография и/или Оркестрация

Их мы будем подробно разбирать на следующей неделе 🤝


#АрхитектураGA

🗓 [29.11 - 02.12] Хореография и оркестрация микросервисов: открытый урок 🗓

Когда на Backend не один большой монолит, а десятки микросервисов, главный риск прячется не внутри сервисов, а между ними. Стоит допустить ошибку во взаимодействиях — и запросы «теряются», рассинхронизируются данные, неожиданные сбои...

Мы готовим открытый урок для системных аналитиков, чтобы подробно погрузить вас в подходы к интеграции микросервисов:


💎 Хореография и оркестрация микросервисов: практика проектирования процессов

🗓 29 ноября - 2 декабря [сб-вт]
🕘 Время на обучение: ~4 часа

📚 Урок в записи, смотрете в удобное время

🔗 Зарегистрироваться


👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика


Это не просто демо-урок, где вы узнаете 5% от реального объема знаний, а полноформатное обучение, после которого вы получите реальные инструменты и знания, которые помогут значительно поднять планку вашей карьеры.


Прокачивайте своё понимание архитектуры систем! Регистрируйтесь и смотрите занятие в удобное время с 29 ноября по 2 декабря 🙌

-----
Урок проводится в качестве вводного занятия к практической программе "Проектирование архитектуры" для системных аналитиков.