This media is not supported in your browser
VIEW IN TELEGRAM
Быть честными - важно! Главное не переусердствовать! И без инцидентов с БД, пожалуйста 😄😉 #GAhahaha
😁60❤7🔥6
🍕 Project 3TEN: пицца, которая знает, что вы её закажете (про чудеса внедрения AI) 🍕
Знаете сеть доставки пиццы Domino’s Pizza?
У них есть своя IT-платформа. Во время учебы по AI нам рассказали про их крутой проект с применением искусственного интеллекта🤖
Не могу не поделиться!
Представьте, что вы только зашли в приложение Domino’s, чтобы выбрать пиццу. Листаете меню, думаете — «Пепперони или Маргарита?» — а на кухне в вашем районе печь уже нагревается🤯
Это не фантазия, а реальность проекта Domino’s Project 3TEN.
👉 Его цель — приготовить пиццу за 3 минуты и доставить за 10 после заказа.
В основе — алгоритмы машинного обучения, которые предсказывают, что вы выберете, ещё до того, как вы оформите заказ.
Domino’s собирает данные:
+ что вы заказывали раньше,
+ что популярно в вашем районе сегодня,
+ какая погода за окном
+ и даже насколько далеко курьеры.
Если модель уверена в прогнозе, кухня начинает готовить пиццу прямо во время вашего выбора.
Параллельно курьер получает сигнал: «Через пару минут будет заказ — будь рядом».
В результате, когда вы нажимаете «Заказать», пицца уже почти готова, а доставка занимает считанные минуты 🤩🚀
Техническая магия спрятана в связке AWS-сервисов, интеграции с POS-системой и обмене событиями в реальном времени между кухней и логистикой.
Но суть в другом:
Будущее уже рядом!
Компании, которые оперируют большими данными, будут первыми успешно внедрять AI в свой бизнес и оптимизировать процессы на 10000%!
А мы, как системные аналитики, можем начинать готовиться к новым видам задач и тесному сотрудничеству с аналитиками данных 🙌
Подробнее о проекте (англ)
Знаете сеть доставки пиццы Domino’s Pizza?
У них есть своя IT-платформа. Во время учебы по AI нам рассказали про их крутой проект с применением искусственного интеллекта
Не могу не поделиться!
Представьте, что вы только зашли в приложение Domino’s, чтобы выбрать пиццу. Листаете меню, думаете — «Пепперони или Маргарита?» — а на кухне в вашем районе печь уже нагревается
Это не фантазия, а реальность проекта Domino’s Project 3TEN.
👉 Его цель — приготовить пиццу за 3 минуты и доставить за 10 после заказа.
В основе — алгоритмы машинного обучения, которые предсказывают, что вы выберете, ещё до того, как вы оформите заказ.
Domino’s собирает данные:
+ что вы заказывали раньше,
+ что популярно в вашем районе сегодня,
+ какая погода за окном
+ и даже насколько далеко курьеры.
Если модель уверена в прогнозе, кухня начинает готовить пиццу прямо во время вашего выбора.
Параллельно курьер получает сигнал: «Через пару минут будет заказ — будь рядом».
В результате, когда вы нажимаете «Заказать», пицца уже почти готова, а доставка занимает считанные минуты 🤩
Техническая магия спрятана в связке AWS-сервисов, интеграции с POS-системой и обмене событиями в реальном времени между кухней и логистикой.
Но суть в другом:
AI перестал быть отдельным модулем — он стал частью нервной системы бизнеса, управляющей всем процессом от выбора в приложении до двери клиента.
Будущее уже рядом!
Компании, которые оперируют большими данными, будут первыми успешно внедрять AI в свой бизнес и оптимизировать процессы на 10000%!
А мы, как системные аналитики, можем начинать готовиться к новым видам задач и тесному сотрудничеству с аналитиками данных 🙌
Подробнее о проекте (англ)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤4👎4🤔3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
🔮 Микросервисная архитектура (МСА) — современный подход к разработке высоконагруженных приложений.
Ключевые компоненты, которые используются для его реализации:
✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).
✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.
✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.
Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.
✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.
Они взаимодействуют между собой с помощью легковесных протоколов, таких как HTTP (REST), gRPC или через асинхронные сообщения.
✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.
Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.
✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.
✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).
✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.
✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.
#АрхитектураGA
Ключевые компоненты, которые используются для его реализации:
✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).
✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.
✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.
Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.
✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.
Они взаимодействуют между собой с помощью легковесных протоколов, таких как HTTP (REST), gRPC или через асинхронные сообщения.
✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.
Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.
✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.
✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).
✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.
✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.
#АрхитектураGA
🔥27❤15👍2🤩2
GetAnalyst_Архитектура_ParkingGA_Микросервисы_Этап_1.png
433.7 KB
🅿️ DDD в деле: микросервисы для #ParkingGA 🅿️
В этом посте разберём, какие сервисы и микросервисы можно выделить для платформы управления парковками.
🔹 Аутентификация и авторизация
Отвечает за вход в систему и проверку прав.
🔹 Пользователи и автомобили
Управление профилем водителя и его машинами.
🔹 Каталог парковок
Справочник с адресами, схемами мест.
🔹 Парковочные сессии
Фиксирует факт въезда/выезда и длительность стоянки.
По сути это "заказ" парковки, если сравнивать с Интернет-магазином.
🔹 Биллинг и Тарифы
Хранит правила расчёта стоимости. Считает стоимость парковочной сессии.
🔹 Платежи
Интеграция с платёжной системой, обработка транзакций.
🔹 Виртуальные кошельки
Внутренняя учётная система для быстрых оплат.
🔹 Абонементы
Долгосрочные парковочные билеты.
🔹 Штрафы и нарушения
Фиксирует неоплаты, превышения времени, нарушения правил парковки.
🔹 Уведомления
Отправка сообщений пользователям: push, SMS, email.
Хранение и настройка шаблонов.
🔹 Лояльность
Система для проведения акций и выдачи скидок клиентам:
+ скидки,
+ акции,
+ бизнесы-партнеры,
+ промокоды.
🔹 Обращения тех. поддержки
Регистрация и обработка заявок от пользователей, переписка в рамках поддержки.
🔹 Администрирование
Управление сотрудниками, их правами и настройками.
🔹 Аналитика и отчетность
Формирует статистику для бизнеса. Агрегирует важные данные из всех ключевых сервисов системы.
🔹 Аудит
Хранит действия пользователей и администраторов.
🔹 API Gateway
Входная точка для всех запросов, маршрутизация и безопасность.
Не хранит бизнес-данных.
Сервисы выделены по доменным границам и принципу «один сервис — один владелец данных».
Такой подход позволяет:
✔️ держать чёткие зоны ответственности,
✔️ разделять нагрузки и соблюдать SLA,
✔️ обеспечивать безопасность,
✔️ развивать и масштабировать каждый сервис независимо.
Именно это делает архитектуру прозрачной и удобной для долгосрочной поддержки.
Ещё идеи по сервисам?
Пишите в комментариях 👍
#АрхитектураGA
В этом посте разберём, какие сервисы и микросервисы можно выделить для платформы управления парковками.
🔹 Аутентификация и авторизация
Отвечает за вход в систему и проверку прав.
🔹 Пользователи и автомобили
Управление профилем водителя и его машинами.
🔹 Каталог парковок
Справочник с адресами, схемами мест.
🔹 Парковочные сессии
Фиксирует факт въезда/выезда и длительность стоянки.
По сути это "заказ" парковки, если сравнивать с Интернет-магазином.
🔹 Биллинг и Тарифы
Хранит правила расчёта стоимости. Считает стоимость парковочной сессии.
🔹 Платежи
Интеграция с платёжной системой, обработка транзакций.
🔹 Виртуальные кошельки
Внутренняя учётная система для быстрых оплат.
🔹 Абонементы
Долгосрочные парковочные билеты.
🔹 Штрафы и нарушения
Фиксирует неоплаты, превышения времени, нарушения правил парковки.
🔹 Уведомления
Отправка сообщений пользователям: push, SMS, email.
Хранение и настройка шаблонов.
🔹 Лояльность
Система для проведения акций и выдачи скидок клиентам:
+ скидки,
+ акции,
+ бизнесы-партнеры,
+ промокоды.
🔹 Обращения тех. поддержки
Регистрация и обработка заявок от пользователей, переписка в рамках поддержки.
🔹 Администрирование
Управление сотрудниками, их правами и настройками.
🔹 Аналитика и отчетность
Формирует статистику для бизнеса. Агрегирует важные данные из всех ключевых сервисов системы.
🔹 Аудит
Хранит действия пользователей и администраторов.
🔹 API Gateway
Входная точка для всех запросов, маршрутизация и безопасность.
Не хранит бизнес-данных.
Сервисы выделены по доменным границам и принципу «один сервис — один владелец данных».
Такой подход позволяет:
✔️ держать чёткие зоны ответственности,
✔️ разделять нагрузки и соблюдать SLA,
✔️ обеспечивать безопасность,
✔️ развивать и масштабировать каждый сервис независимо.
Именно это делает архитектуру прозрачной и удобной для долгосрочной поддержки.
Ещё идеи по сервисам?
Пишите в комментариях 👍
#АрхитектураGA
👍19❤4🔥2
Когда система построена на микросервисах, критично не только то, как работает каждый сервис, а как они взаимодействуют между собой. Ошибки в этих связях приводят к хаосу: потерянные и рассинхронизированные данные, неожиданные сбои.
Мы готовим онлайн-практикум, чтобы глубже погрузиться в тему интеграций в микросервисной архитектуре:
👉 Зарегистрироваться
План встречи:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
Практические знания, которые вы получите на этом открытом уроке, помогут сделать шаг на новый уровень в системном анализе, и стать более востребованным специалистом на рынке
Готовы получить новый опыт?
Регистрируйтесь и присоединяйтесь к эфиру 26 августа в 19:00 Мск!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤29🔥7👍4🎉2
This media is not supported in your browser
VIEW IN TELEGRAM
⚙️ 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
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
❤34🔥16❤🔥3👍3
4 шага для выбора СУБД [GetAnalyst].pdf
1.8 MB
📚4 шага, чтобы выбрать СУБД для проекта 📚
Выбор СУБД — не галочка в чеклисте, а инженерное решение для проекта.
Да, для большинства случаев (~80%) разумно стартовать с PostgreSQL для всего, кроме кэша и файлов 😃
Но так бывает не всегда...
Что может заставить задуматься о подборе СУБД для проекта:
✔️ смешанные нагрузки,
✔️ жёсткие RPO/RTO,
✔️ вид хранимых данных,
✔️ необходимость полнотекстового поиска,
✔️ сложные запросы.
📚 В мини-книге для архитекторов и аналитиков, прикрепленной к посту, вы найдёте:
+ расшифровки сложных терминов, связанных с базами данных,
+ и пошаговый алгоритм, который поможет выбрать СУБД для вашего проекта, когда «дефолтный» вариант не подошёл.
#АрхитектураGA
Выбор СУБД — не галочка в чеклисте, а инженерное решение для проекта.
Да, для большинства случаев (~80%) разумно стартовать с PostgreSQL для всего, кроме кэша и файлов 😃
Но так бывает не всегда...
Что может заставить задуматься о подборе СУБД для проекта:
✔️ смешанные нагрузки,
✔️ жёсткие RPO/RTO,
✔️ вид хранимых данных,
✔️ необходимость полнотекстового поиска,
✔️ сложные запросы.
📚 В мини-книге для архитекторов и аналитиков, прикрепленной к посту, вы найдёте:
+ расшифровки сложных терминов, связанных с базами данных,
+ и пошаговый алгоритм, который поможет выбрать СУБД для вашего проекта, когда «дефолтный» вариант не подошёл.
#АрхитектураGA
🔥33❤5❤🔥3🦄1
🌐 API Gateway | Load Balancer | Reverse Proxy | Forward Proxy | Service Mesh 🌐
Когда системы обрабатывают миллиарды запросов в день, они не "падают" благодаря правильным сетевым компонентам.
Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:
🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.
🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.
🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.
🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.
🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.
📌 Знание этих инструментов помогает аналитику не путаться в сетевых терминах и понимать масштабируемые и безопасные системы.
#АрхитектураGA
Когда системы обрабатывают миллиарды запросов в день, они не "падают" благодаря правильным сетевым компонентам.
Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:
🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.
🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.
🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.
🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.
🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.
📌 Знание этих инструментов помогает аналитику не путаться в сетевых терминах и понимать масштабируемые и безопасные системы.
#АрхитектураGA
💯21❤🔥13🔥9❤3👍2
🟢 26.08 в 19Мск | онлайн-практикум по архитектуре для Системных Аналитиков 🟢
Готовитесь к собеседованию на Middle+ / Senior СА?
Хотите расширить экспертизу в архитектуре систем?
Или стремитесь работать в команде, где микросервисы — это реальность, а не теория?
Присоединяйтесь к нам на бесплатное практическое занятие!
💎 Хореография и оркестрация микросервисов
🗓 26 августа (вт), 19:00 Мск
👉 Зарегистрироваться
За один вечер:
✅ Разберётесь в принципах хореографии и оркестрации на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
✅ Подготовитесь к вопросам на интервью уровня Middle+ / Senior.
Этот практикум даст вам реальные инструменты и знания, которые помогут не просто пробить стеклянный потолок, а значительно поднять планку вашей карьеры.
Это вводное занятие к практической программе Проектирование архитектуры для системных аналитиков, которая стартует в сентябре (до онлайн-встречи действуют спец. условия по записи 🎁).
Хотите учиться на реальных задачах?
Регистрируйтесь и пробуйте 26 августа в 19:00 Мск! 😉
Готовитесь к собеседованию на Middle+ / Senior СА?
Хотите расширить экспертизу в архитектуре систем?
Или стремитесь работать в команде, где микросервисы — это реальность, а не теория?
Присоединяйтесь к нам на бесплатное практическое занятие!
👉 Зарегистрироваться
За один вечер:
✅ Разберётесь в принципах хореографии и оркестрации на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
✅ Подготовитесь к вопросам на интервью уровня Middle+ / Senior.
Этот практикум даст вам реальные инструменты и знания, которые помогут не просто пробить стеклянный потолок, а значительно поднять планку вашей карьеры.
Это вводное занятие к практической программе Проектирование архитектуры для системных аналитиков, которая стартует в сентябре (до онлайн-встречи действуют спец. условия по записи 🎁).
Хотите учиться на реальных задачах?
Регистрируйтесь и пробуйте 26 августа в 19:00 Мск! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤6😍3
🤨 Должна ли у микросервиса всегда быть своя БД? 🤨
Да! Нет.
Хороший вопрос с подвохом для собеседования.
👉 Начнём с того, что есть паттерн проектирования микросервисов — Database per Service.
Он утверждает:
«каждый сервис работает только со своей БД, чужие данные не трогаем».
Зачем это нужно:
+ уменьшает связанность,
+ даёт независимость сервисов,
+ при падении БД ломается только один сервис,
+ одно изменение в данных не «роняет» соседние сервисы.
Но в реальной жизни всё чуть сложнее...
1️⃣ Чистое соблюдение Database per Service
Так бывает.
У каждого микросервиса — своя СУБД или хотя бы свой кластер.
✅ Максимум изоляции.
❌ Но: больше инфраструктуры, мониторинга, бэкапов и миграций.
2️⃣ Несколько схем внутри одной СУБД
Распространённое решение.
Одна база (например, PostgreSQL), но для каждого сервиса отдельная схема.
✅ Разграничение доступа и независимость структур данных.
✅ Меньше операционных проблем.
❌ Всё равно сохраняется определённая связанность.
3️⃣ Одна база на несколько сервисов
Иногда команда разработки решает: «так удобнее».
Особенно если сервисы тесно связаны по данным, то разделение породит лишние транзакционные цепочки и задержки.
✅ Просто и эффективно.
❌ Формально это уже не «чистые» микросервисы.
👉 Итого
Database per Service — это паттерн, а не жёсткое правило.
Его цель — изоляция и независимость сервисов.
Но на практике уместны разные подходы: от «чистого» варианта до схем в одной БД или даже общей базы на несколько сервисов.
Задача аналитиков и архитекторов — найти баланс между изоляцией, удобством сопровождения и требованиями бизнеса 🙌
#АрхитектураGA
Хороший вопрос с подвохом для собеседования.
👉 Начнём с того, что есть паттерн проектирования микросервисов — Database per Service.
Он утверждает:
«каждый сервис работает только со своей БД, чужие данные не трогаем».
Зачем это нужно:
+ уменьшает связанность,
+ даёт независимость сервисов,
+ при падении БД ломается только один сервис,
+ одно изменение в данных не «роняет» соседние сервисы.
Но в реальной жизни всё чуть сложнее...
1️⃣ Чистое соблюдение Database per Service
Так бывает.
У каждого микросервиса — своя СУБД или хотя бы свой кластер.
✅ Максимум изоляции.
❌ Но: больше инфраструктуры, мониторинга, бэкапов и миграций.
2️⃣ Несколько схем внутри одной СУБД
Распространённое решение.
Одна база (например, PostgreSQL), но для каждого сервиса отдельная схема.
✅ Разграничение доступа и независимость структур данных.
✅ Меньше операционных проблем.
❌ Всё равно сохраняется определённая связанность.
3️⃣ Одна база на несколько сервисов
Иногда команда разработки решает: «так удобнее».
Особенно если сервисы тесно связаны по данным, то разделение породит лишние транзакционные цепочки и задержки.
✅ Просто и эффективно.
❌ Формально это уже не «чистые» микросервисы.
👉 Итого
Database per Service — это паттерн, а не жёсткое правило.
Его цель — изоляция и независимость сервисов.
Но на практике уместны разные подходы: от «чистого» варианта до схем в одной БД или даже общей базы на несколько сервисов.
Задача аналитиков и архитекторов — найти баланс между изоляцией, удобством сопровождения и требованиями бизнеса 🙌
#АрхитектураGA
👌27❤13👍7🔥4
🌞 Давно такого не было — и вот опять...
Лето, время отдыхать.
Но у моего подсознания на лето 2025 случились другие планы:
начала и завершаю в режиме тотальной продуктивности 🚀
Всё лето — учёба, встречи, новые проекты и идеи.
И сейчас, в последнюю неделю, я решила рвануть на максимум. Смотрю в календарь - шок 😃
📅 Коротко, если ничего нового не добавится (некуда):
Пн
+ 1:1 со студенткой GetAnalyst
+ учёба
+ еженедельное ревью проектов от студентов GA
+ тренировка по паделу 🎾 (не только же умное)
+ доделка презентации ко вт по Архитектуре
+ занятие по английскому
+ тренировка
Вт
+ открытый вебинар по архитектуре
+ разбор текущих задач по GA
+ встреча по проекту
+ нарезка задач после встречи
+ тренировка
+ дорога до Лос Анджелеса на конференцию
Ср
+ конференция по Generative AI на весь день
+ дорога домой
Чт
+ с утра пораньше на самолёт в другой штат
+ учёба
+ задачи по GetAnalyst
+ задачи по другим проектам
+ тренировка
Пт
+ рабочая встреча
+ задачи по проектам
+ подготовка демо клиентам на пн
+ учёба
+ тренировка
Сб
выходной 🙌
Вс
+ частично выходной
+ учеба
+ подготовка контента для GetAnalyst
+ планирование недели
+ тренировка
Пн
+ самолёт домой с утра пораньше
+ падел
+ митинги
+ учёба
+ ревью проектов от студентов GetAnalyst
+ английский
+ .....
P.S. Чтобы успевать жить: тренировки и хобби в расписании обязательны.
Вот так и живу.
Вроде не так уж и много, но много.
В эту неделю у меня ещё нет вебинаров для наших студентов. Обычно они есть всегда ❤️🔥
Все эти дела меня очень заряжают!
Учеба, встречи, путешествия!
Большой сдвиг в моём настрое и расписании произошёл с приходом учёбы 🙌
Мне казалось, что я не буду успевать ничего и сомневалась, но благодаря выстроенному расписанию всё отлично!
И самое главное - я вдохновленнее и продуктивнее благодаря учёбе! 😻
Работа делается быстрее!!
Да и вообще, рабочие дни стали разнообразнее. Это для меня как отдых)) И результаты уже есть!
Режим "делай максимум" включён.
Осенью продолжим 😎
Кто готов идти в продуктивную осень? 🔥
Лето, время отдыхать.
Но у моего подсознания на лето 2025 случились другие планы:
начала и завершаю в режиме тотальной продуктивности 🚀
Всё лето — учёба, встречи, новые проекты и идеи.
И сейчас, в последнюю неделю, я решила рвануть на максимум. Смотрю в календарь - шок 😃
📅 Коротко, если ничего нового не добавится (некуда):
Пн
+ 1:1 со студенткой GetAnalyst
+ учёба
+ еженедельное ревью проектов от студентов GA
+ тренировка по паделу 🎾 (не только же умное)
+ доделка презентации ко вт по Архитектуре
+ занятие по английскому
+ тренировка
Вт
+ открытый вебинар по архитектуре
+ разбор текущих задач по GA
+ встреча по проекту
+ нарезка задач после встречи
+ тренировка
+ дорога до Лос Анджелеса на конференцию
Ср
+ конференция по Generative AI на весь день
+ дорога домой
Чт
+ с утра пораньше на самолёт в другой штат
+ учёба
+ задачи по GetAnalyst
+ задачи по другим проектам
+ тренировка
Пт
+ рабочая встреча
+ задачи по проектам
+ подготовка демо клиентам на пн
+ учёба
+ тренировка
Сб
выходной 🙌
Вс
+ частично выходной
+ учеба
+ подготовка контента для GetAnalyst
+ планирование недели
+ тренировка
Пн
+ самолёт домой с утра пораньше
+ падел
+ митинги
+ учёба
+ ревью проектов от студентов GetAnalyst
+ английский
+ .....
P.S. Чтобы успевать жить: тренировки и хобби в расписании обязательны.
Вот так и живу.
Вроде не так уж и много, но много.
В эту неделю у меня ещё нет вебинаров для наших студентов. Обычно они есть всегда ❤️🔥
Все эти дела меня очень заряжают!
Учеба, встречи, путешествия!
Большой сдвиг в моём настрое и расписании произошёл с приходом учёбы 🙌
Мне казалось, что я не буду успевать ничего и сомневалась, но благодаря выстроенному расписанию всё отлично!
И самое главное - я вдохновленнее и продуктивнее благодаря учёбе! 😻
Работа делается быстрее!!
Да и вообще, рабочие дни стали разнообразнее. Это для меня как отдых)) И результаты уже есть!
Режим "делай максимум" включён.
Осенью продолжим 😎
Кто готов идти в продуктивную осень? 🔥
❤🔥36🔥14❤11🤔2👍1🍾1
⚙️ [Завтра в 19:00 Мск] Хореография и оркестрация микросервисов ⚙️
Завтра мы проведём практикум для Системных Аналитиков, чтобы глубже разобраться в интеграциях микросервисов и проектировать процессы без ошибок.
💎 Хореография и оркестрация микросервисов
🟢 Онлайн
🗓 26 августа (вт), 19:00 Мск
👉 Принять участие
План встречи:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
-----------
Это вводное занятие к практической программе Проектирование архитектуры для СА, которая стартует в сентябре.
🎁 Сегодня — последний день спецусловий на участие в программе.
-----------
Подключайтесь к эфиру, практикуйтесь, задавайте вопросы и получайте обратную связь.
До встречи на практике! 🤝
Завтра мы проведём практикум для Системных Аналитиков, чтобы глубже разобраться в интеграциях микросервисов и проектировать процессы без ошибок.
👉 Принять участие
План встречи:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
-----------
Это вводное занятие к практической программе Проектирование архитектуры для СА, которая стартует в сентябре.
🎁 Сегодня — последний день спецусловий на участие в программе.
-----------
Подключайтесь к эфиру, практикуйтесь, задавайте вопросы и получайте обратную связь.
До встречи на практике! 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥5
GetAnalyst Кэширование.pdf
2 MB
🚀 Кэш — двигатель производительности системы 🚀
Именно он спасает нас от медленных ответов и заставляет экраны приложений грузиться быстрее.
Кэш есть в процессорах, браузерах, БД, микросервисах.
Но просто положить данные в кэш недостаточно.
Важно понимать:
+ когда кэшировать,
+ что кэшировать,
+ как обновлять кэш.
С мини-книгой к посту вы сможете быстро разобраться в особенностях работы с кэшем.
🔹 Введение
🔹 Зачем кэшировать
🔹 Стратегии кэширования
🔹 Инвалидация кэша
🔹 Стратегии вытеснения кэша
🔹 Время жизни кэша (TTL)
🔹 Согласованность со временем
🔹 Холодный и горячий кэш
🔹 Standalone кэш
Мало работали с кэшем?
Загружайте мини-книгу и изучайте ключевые термины 📚
#АрхитектураGA
Именно он спасает нас от медленных ответов и заставляет экраны приложений грузиться быстрее.
Кэш есть в процессорах, браузерах, БД, микросервисах.
Но просто положить данные в кэш недостаточно.
Важно понимать:
+ когда кэшировать,
+ что кэшировать,
+ как обновлять кэш.
С мини-книгой к посту вы сможете быстро разобраться в особенностях работы с кэшем.
🔹 Введение
🔹 Зачем кэшировать
🔹 Стратегии кэширования
🔹 Инвалидация кэша
🔹 Стратегии вытеснения кэша
🔹 Время жизни кэша (TTL)
🔹 Согласованность со временем
🔹 Холодный и горячий кэш
🔹 Standalone кэш
Мало работали с кэшем?
Загружайте мини-книгу и изучайте ключевые термины 📚
#АрхитектураGA
❤41❤🔥12🔥6
This media is not supported in your browser
VIEW IN TELEGRAM
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 упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤45🔥11👍2
Прямой эфир с автором канала GetAnalyst - Екатериной Ананьевой.
👉 Принять участие
Ссылка с доступом придёт вам на почту.
❗️ Запись будет доступна только для зарегистрированных участников с 30.08 до 02.09
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥8👍8🔥5❤3
🤩😍 Что было вчера на онлайн-практике 😍🤩
Как и на любом прямом эфире сообщества GetAnalyst, вчера снова было ВАУ-ВАУ-ВАУ!
И этот эффект — только благодаря вам! ❤️
👉 Здесь собрались очень крутые специалисты, жадные до знаний! Спасибо вам за это!
Благодаря вашим действительно важным вопросам и активному участию.
Благодаря тому, что каждый хотел разобраться в деталях и докопаться до сути.
У нас получился невероятно полезный эфир!
Спасибо вам за ваше время и вовлечённость!
Спасибо, что выбираете своё развитие вместе со мной и сообществом GetAnalyst.
Это обязательно окупится в будущем!
И спасибо за тёплую обратную связь, которую я получила ❤️🔥
Что успели:
🔹 Разобрались в монолитной, SOA, MSA и EDA архитектурах на примерах
🔹 Увидели API Gateway в действии
🔹 Спроектировали процесс без хореографии и оркестрации
🔹 Познакомились с шаблоном микросервисов SAGA
🔹 Познакомились с основами по брокерам RabbitMQ и Kafka
🔹 Спроектировали процесс с использованием оркестрации и хореографии
И почти по каждому пункту смогли детально погрузиться в детали!
📌 Доступ к записи
Для тех, кому не удалось подключиться, остаться до конца, или хочется еще раз повторить всю практику, чтобы закрепить результат:
🟢 Хореография и оркестрация микросервисов
🗓 Доступ с 30.08 до 02.09 (сб-вт)
🔗 Получить доступ
❗️ ПОВТОРНО РЕГИСТРИРОВАТЬСЯ НЕ НАДО, если уже регистрировались на основной эфир!
Письмо с доступом придёт в СБ утром.
👉 Эта встреча была вводным занятием к практической программе Проектирование Архитектуры, которая стартует 2 сентября.
🎁 Сегодня последний день действия спец. условий с онлайн-встречи.
Если чувствуете, что сейчас — ваше время двигаться вперёд в карьере, буду рада видеть вас на программе 🙌
Спасибо вам за доверие!
Искренне ценю вашу вовлечённость и выбор расти в карьере вместе с GetAnalyst! ❤️🔥
С наилучшим пожеланиями,
Екатерина Ананьева
Как и на любом прямом эфире сообщества GetAnalyst, вчера снова было ВАУ-ВАУ-ВАУ!
И этот эффект — только благодаря вам! ❤️
👉 Здесь собрались очень крутые специалисты, жадные до знаний! Спасибо вам за это!
Благодаря вашим действительно важным вопросам и активному участию.
Благодаря тому, что каждый хотел разобраться в деталях и докопаться до сути.
У нас получился невероятно полезный эфир!
Спасибо вам за ваше время и вовлечённость!
Спасибо, что выбираете своё развитие вместе со мной и сообществом GetAnalyst.
Это обязательно окупится в будущем!
И спасибо за тёплую обратную связь, которую я получила ❤️🔥
Что успели:
🔹 Разобрались в монолитной, SOA, MSA и EDA архитектурах на примерах
🔹 Увидели API Gateway в действии
🔹 Спроектировали процесс без хореографии и оркестрации
🔹 Познакомились с шаблоном микросервисов SAGA
🔹 Познакомились с основами по брокерам RabbitMQ и Kafka
🔹 Спроектировали процесс с использованием оркестрации и хореографии
И почти по каждому пункту смогли детально погрузиться в детали!
📌 Доступ к записи
Для тех, кому не удалось подключиться, остаться до конца, или хочется еще раз повторить всю практику, чтобы закрепить результат:
🟢 Хореография и оркестрация микросервисов
❗️ ПОВТОРНО РЕГИСТРИРОВАТЬСЯ НЕ НАДО, если уже регистрировались на основной эфир!
Письмо с доступом придёт в СБ утром.
👉 Эта встреча была вводным занятием к практической программе Проектирование Архитектуры, которая стартует 2 сентября.
Если чувствуете, что сейчас — ваше время двигаться вперёд в карьере, буду рада видеть вас на программе 🙌
Спасибо вам за доверие!
Искренне ценю вашу вовлечённость и выбор расти в карьере вместе с GetAnalyst! ❤️🔥
С наилучшим пожеланиями,
Екатерина Ананьева
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28❤🔥17❤11👍1
This media is not supported in your browser
VIEW IN TELEGRAM
❌ API Gateway — центральная точка отказа в системе? ❌
Отличный вопрос, который могут задать на собеседовании.
Ответ:
Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится.
Пользователи не смогут достучаться до микросервисов, даже если сами микросервисы продолжают работать.
❌ Что будет, если API Gateway «упадёт»?
1. Внешние клиенты потеряют доступ к сервисам.
2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены.
3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable).
4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить 🥲
👉 Как это решается?
Чтобы API Gateway не стал "узким горлышком", применяют следующие решения:
🟢 Горизонтальное масштабирование
Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы.
🟢 Health-check и авто-рестарт
Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое.
🟢 Failover-механизмы
Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях.
🟢 Разделение входящего трафика
В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API)
Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены.
Т.е. данные не теряются, процессы продолжаются.
👉 Да
Но при нормальной инфраструктуре не должен быть ею. Мы разбираем это на программе по архитектуре. Это часть про стык Инфраструктуры и Архитектуры, который важно осознавать аналитикам.
#АрхитектураGA
Отличный вопрос, который могут задать на собеседовании.
Ответ:
Да — если он не масштабирован горизонтально.
Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится.
Пользователи не смогут достучаться до микросервисов, даже если сами микросервисы продолжают работать.
❌ Что будет, если API Gateway «упадёт»?
1. Внешние клиенты потеряют доступ к сервисам.
2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены.
3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable).
4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить 🥲
👉 Как это решается?
Чтобы API Gateway не стал "узким горлышком", применяют следующие решения:
🟢 Горизонтальное масштабирование
Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы.
🟢 Health-check и авто-рестарт
Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое.
🟢 Failover-механизмы
Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях.
🟢 Разделение входящего трафика
В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API)
Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены.
Т.е. данные не теряются, процессы продолжаются.
API Gateway - потенциальная точка отказа в системе?
👉 Да
Но при нормальной инфраструктуре не должен быть ею. Мы разбираем это на программе по архитектуре. Это часть про стык Инфраструктуры и Архитектуры, который важно осознавать аналитикам.
#АрхитектураGA
🔥25❤10❤🔥4