🚩Кейс: Проектирование REST API для нового сервиса.

1️⃣ Если сервис не является владельцем сущности системы, а просто выполняет какую-то функцию, необходимо:
🔸 Реализовать синхронный метод для вызова функции сервиса;
🔸 Реализовать асинхронный метод для вызова функции сервиса;
🔸 При необходимости, реализовать методы для множественного вызова по списку объектов.

2️⃣ Сервис является владельцем сущности в системе:
🔸Реализовать методы на все CRUD-операции (могут быть множественными);
🔸Реализовать метод получения списка объектов;
🔸Не забыть про пагинацию, если она нужна;
🔸Не забыть про фильтрацию списка;
🔸Для сложной фильтрации стоит использовать метод POST для получения списка;
🔸При наличии дополнительной логики работы с объектами реализовать для нее методы.

3️⃣ Для всех сервисов:
🔸Авторизация штатными средствами вашей системы;
🔸Используйте формат данных, принятый для таких сервисов на проекте;
🔸Напомните разработчику про правильные коды ответов;
🔸Не забывайте о принципе единственной ответственности.

🚩Кейс: Передача большого объекта через брокер сообщений.

✅ Использовать отдельное хранилище, доступ к которому должен быть у всех сервисов, участвующих в работе с объектом.

1️⃣ Сервис producer сохраняет объект в хранилище и получает в ответ ссылку на него;

2️⃣ Сервис producer отправляет в брокер сообщение, которое содержит ссылку на объект в хранилище, а не сам объект;

3️⃣ Сервис consumer получает ссылку из брокера;

4️⃣ Сервис consumer обращается в хранилище для получения объекта.

Ниже приложу схему для наглядности👇

Системный анализ | Дмитрий Помаскин

‼️Если возникли проблемы с рассрочкой или промокодом.

Вижу, что многие заходят на бесплатный "Ознакомительный" тариф, поэтому повторно выкладываю инструкцию, как сменить тариф в рассрочку или с применением промокода:

1. Выйти из аккаунта;

2. Перейти на страницу курса, на которой вы регистрировались на "Ознакомительный" тариф;

3. Выбрать интересующий вас тариф и ввести промокод;

4. Указать почту, на которую вы уже зарегистрировались, и нажать "Перейти к оформлению";

5. У вас откроется окно входа в систему, так как данная почта уже используется;

6. Просто введите свои данные для входа, и у вас откроется окно оформления рассрочки.

P.S. О данном ограничении уже сообщил разработчикам платформы, обещали устранить.

P.P.S. Если у вас возникают какие-то вопросы или трудности, всегда можете написать мне в личные сообщения :) @system_analysis_dmitriy


Для наглядности прикладываю видеоинструкцию.

👋 Обращение к студентам курса "Основы архитектуры"

Проверял домашние работы и заметил, что в 1 модуле почти все допускают ошибку при описании мониторинга системы.
Обратите внимание, что вам нужно описать не только технические метрики, но и безнес-метрики.

P.S. Я об это говорю в модуле, специально сам пересмотрел:)

❔«Чем отличается GET от POST?»

Неполный ответ:
⚠️ GET - получает ресурс, POST - создает ресурс.

Обязательно не забывайте сравнивать их по свойствам:
✅ Наличие тела: GET - нет, POST - да;

✅ Кэшируемость: GET - да, POST - нет;

✅ Безопасность: GET - да, POST - нет;

✅ Идемпотентность: GET - да, POST - нет.

P.S. Метод POST - частично-кэшируемый метод, зависит от способа применения и заголовков.

🚀 Запускаю интересный сервис :)

Бесплатная оценка ваших навыков без примитивных тестов и телеграм-ботов.

Только хардкор и свободные(текстовые) ответы на вопросы 😎

Проверю всё самостоятельно и направлю вам подробную обратную связь в личные сообщения.

✅ Вас ждут 42 вопроса по хард скилам системного аналитика;

🕐 У вас будет 60 минут и только 1 попытка на прохождение, поэтому рассчитывайте своё время;

⛔️ Чтобы получить честную оценку, лучше не пользоваться поисковыми сервисами и нейросетями:)

Записаться можно здесь

P.S. Вопросы на абсолютно разные грейды, поэтому не переживайте, если вы чего-то не знаете :)

Системный анализ | Дмитрий Помаскин

🚩Кейс: формирование отчетов по данным вашей системы.

1️⃣ Разрабатываем отдельный сервис, который будет содержать логику формирования отчетов;

2️⃣ Под этим сервисом поднимаем отдельную БД для статистики и отчетов;

3️⃣ Реплицируем в эту БД часть данных, необходимую для формирования отчетов;

4️⃣ Строим отчеты без эффекта на критически важные модули системы.

Ниже приложу схему для наглядности👇

Системный анализ | Дмитрий Помаскин

🚩Кейс: Создание новой формы в интерфейсе.

1️⃣ Описывая требования к front-end, не забывайте про правила заполнения формы: обязательность полей, маска ввода и т.д.

2️⃣ Описывая требования к back-end, вам точно так же необходимо помнить про валидацию полученной в запросе информации. Сервис должен проверить правильность заполнения полей, необходимых для дальнейшего исполнения задачи.

❓Периодически буду с выкладывать вопросно-ответный пост (это он).

Если у вас возникают какие-то вопросы, касающиеся тематики канала, можете задавать их в комментариях.
Сложные кейсы, с которыми столкнулись в работе, теоретические вопросы, вопросы по курсам и т.д.

💬 Я отвечу на них в комментариях, а самые интересные разберу в видеоформате.

🚩Кейс: Проверка прав доступа у пользователя.

1️⃣ Описывая требования к front-end, вы закладываете ограничения на доступ к каким-то элементам интерфейса для определенных ролей пользователей.

2️⃣ Описывая требования к back-end, не забывайте, что ваши сервисы также должны проверять наличие роли у пользователя, отправившего запрос.

Системный анализ | Дмитрий Помаскин

🚩Кейс: Какой брокер выбрать? (RabbitMQ или Apache Kafka).

RabbitMQ:
✅ Простота администрирования;
✅ P2P взаимодействие (очереди задач, фоновая отправка уведомлений);
✅ До 40-45 тысяч сообщений в секунду (примерный ориентир для базовых конфигураций, все зависит от ресурсов);
✅ Не нужно хранить сообщения после получения консьюмером.

❌ Хуже работает с большим потоком данных;
❌ Нет хранения сообщений после их получения консьюмером.
❌ Только вертикальная масштабируемость (кластеризация сложная).

Apache Kafka:
✅ Миллионы сообщений в секунду (аналитика, аудит);
✅ Потребность отправлять одно сообщение множеству консьюмеров (проще fanout exchange);
✅ Хранение сообщений после их получения консьюмером;
✅ Горизонтальная масштабируемость (партиции);
✅ EDA;

❌ Нет сложной маршрутизации;
❌ Потребляет больше ресурсов, чем rabbitMQ;
❌ Избыточен для простых задач.

P.S. Если хотите научиться выбирать брокер под конкретные кейсы на практике, такие задачи мы решаем в курсах по основам архитектуры и системным интеграциям.

Системный анализ | Дмитрий Помаскин

⚠️ Обращение к тем, кто проходит обучение.

Для получения сертификата о прохождении курса Вам необходимо указать в профиле Вашу фамилию, имя и отчество.
Если вы уже указывали Ваши данные, пожалуйста, проверьте корректность введенной информации.

❔Что такое идентификация, аутентификация и авторизация?

1️⃣ Идентификация - процесс указания пользователем своей личности (например, логина или email).
🔸Пример: Вы вводите имя пользователя или почту при входе в систему.

2️⃣ Аутентификация - проверка подлинности пользователя (подтверждение, что он действительно тот, за кого себя выдаёт).
🔸Пример: Вы вводите пароль, используете биометрию, SMS-код или аппаратный ключ.

3️⃣ Авторизация - предоставление прав на доступ к ресурсам.
🔸Пример: После входа вы видите свои счета в приложении банка, но не видите счета других пользователей.

P.S. Понимание этих этапов поможет вам в правильном проектировании SSO (Single Sign-On) сервисов.

Системный анализ | Дмитрий Помаскин

🚩Кейс: Расчет необходимого количества партиций для нового топика кафки.

1️⃣ Количество партиций должно быть кратно числу подов его консьюмеров;

2️⃣ Пропускная способность одной партиции примерно 10 МБ/с (точное значение зависит от ресурсов и конфигурации);

3️⃣ Чем больше партиций, тем дольше ребалансировка.

⚠️ Помните: можно добавлять партиции, но нельзя их удалять.

Системный анализ | Дмитрий Помаскин

🚩Кейс: Расчет необходимого количества партиций для нового топика кафки с учетом HPA.

ℹ️ HPA (Horizontal Pod Autoscaler) — это механизм автоматического масштабирования подов (контейнеров) в Kubernetes на основе текущей нагрузки (CPU, RAM, пользовательских метрик и т.д.)

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

P.S. Для тех, кто пропустил первую часть, она тут.

Системный анализ | Дмитрий Помаскин

❓Очередной вопросно-ответный пост.

Если у вас возникают какие-то вопросы, касающиеся тематики канала, не стесняйтесь и задавайте их в комментариях.

Сложные кейсы, с которыми столкнулись в работе, теоретические вопросы, вопросы по курсам и т.д.

💬 Я отвечу на них в комментариях, а самые интересные разберу в видеоформате.

❔Что такое оркестрация и хореография в распределенных системах?

✅ Это два разных подхода к управлению взаимодействием между сервисами внутри системы.

Оркестрация - подход, в котором есть центральный компонент (оркестратор). Оркестратор управляет выполнением бизнес-процессов, координируя вызовы различных сервисов. Чаще всего предполагает синхронное взаимодействие.

Хореография - децентрализованный подход, где сервисы взаимодействуют через события без центрального управляющего компонента. Предполагает асинхронное взаимодействие, например через событийную модель.

Системный анализ | Дмитрий Помаскин

Немного юмора субботним вечером:)

Был в гостях на канале https://xn--r1a.website/easilyIT, где немного рассказал о кластерных БД .

Также там есть мини-интервью со мной, кому интересно, переходите по ссылке 😊