Идемпотентность

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

Годная статья от Яндекса, где на живых примерах разбирают, как повторные запросы могут ломать бизнес-логику, приводить к дублям и странным багам и что с этим делать на уровне API и архитектуры.

Читать

Статья для тех, кому интересны не только фичи, но и как может быть устроена продуктовая разработка

В статье разбирают доменную структуру, зоны ответственности команд и то, как бизнес и IT взаимодействуют на масштабе большой компании.

Читать

Предлагаю вам небольшую подборку статей по интеграции систем для аналитиков:

👉 Общие принципы интеграций систем. SA для самых маленьких
👉 Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков
👉 Как аналитику работать с задачами на интеграции — пошаговая инструкция
👉 Интеграции бояться — в аналитики не идти
👉 7 главных требований к интеграции ИС, чтобы определить решение
👉 5 техник описания интеграции между системами и взаимодействия микросервисов

Они с Марса, а мы с Венеры: как научить заказчика говорить на одном с аналитиками языке

Ольга Рябая, системный аналитик в компании "DNS Технологии", поделилась конкретным планом действий, который поможет сократить время анализа требований и улучшить коммуникацию в команде. План был составлен на основе опыта проведения 8 мастер-классов для 60 коллег по основам написания ТЗ, декомпозиции требований и описанию ошибок. Для обучения использовался цикл Колба

🔗 Статья
🔗 Запись выступления

Системный анализ: что не так с рынком — и что с этим делать начинающим и опытным аналитикам

Если с 2022 по 2024 год рынок проходил момент пика количества вакансий при нехватке специалистов, то сейчас ситуация обратная. Кандидатов много, но предложений меньше, а требования к системным аналитикам выше. Кроме того, рынок сложный и для работодателей — некоторые вакансии не закрываются месяцами.

Перейти к статье

Говорят ли LLM на языке BPMN? Оценка их возможностей моделирования процессов на основе качественных метрик

Время чтения: 29 мин

Перевод статьи, которая описывает оценку пяти инструментов генерации BPMN на базе LLM, автоматически преобразующих текстовые описания процессов в BPMN-модели. Оценка качества этих моделей ИИ производилась по следующим параметрам: ясность/читаемость, корректность и полнота, охватывающим как точность, так и понятность диаграммы.

🔗 Перевод статьи

🔗🔗Оригинал статьи

Цикл статей: Kafka для начинающих

Автор - Никита Дымко
Java Backend Developer

1. Откуда такой спрос и зачем нужна эта технология

2. Работа с брокером сообщений на практике

3. Гарантии доставки на практике и настройка идемпотентности

4. Работа с оффсетами на практике

5. Работа с Kafka транзакциями на практике — когда они нужны, а когда только вредят?

Подборка статей по слоистой архитектуре

Слоистая архитектура — подход, при котором система разделяется на логические слои


Материалы:
1. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя
2. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика
3. Слоистая архитектура
4. Архитектура приложения: что это, какие есть виды и как проектировать

Сбор требований — фундамент, на котором держится весь проект. Неверный сбор требований может стоить проекту много денег и времени.

Вот подход, который спасает от бесконечных правок и «я не это имел в виду».

Шаг 0: Подготовка и погружение (Самое важное!)

Прежде чем задать первый вопрос:

1. Пойми контекст.
Что за бизнес? Какая его боль? Не «хотим чат в приложении», а «клиенты теряются на этапе выбора услуги, хотят мгновенной консультации».

2. Найди всех, кто «в теме».
Ключевые стейкхолдеры (заинтересованные лица): бизнес-заказчик, будущие пользователи, технические специалисты, поддержка, юристы. У каждого — своя правда.

3. Выучи язык бизнеса.
Говори с финансистами о KPI и ROI, с поддержкой — о нагрузке, с пользователем — о простоте.

Какие бывают требования?

1. Бизнес-требования (Зачем?) — Цели верхнего уровня.
Пример: «Увеличить долю повторных продаж на 15% в следующем квартале».

2. Пользовательские требования (Что?) — Что должны делать пользователи в системе.
Пример: «Возможность оформить возврат товара в личном кабинете за 3 клика».

3. Функциональные требования (Как?) — Конкретные функции системы.
Пример: «Система должна отправлять email-подтверждение при создании возврата».

4. Нефункциональные требования (Каким образом?) — Свойства системы: скорость, безопасность, надёжность.
Пример: «95% страниц кабинета должны загружаться менее чем за 2 секунды при 1000 одновременных пользователей». Часто про них забывают, а потом система «падает».

Как собирать? Инструментарий аналитика

Нет одного волшебного метода. Использую комбинацию:

- Интервью (основа) — Готовь вопросы заранее, но будь готов/а уйти вглубь. Спрашивай «почему?» до тех пор, пока не докопаешься до истинной потребности.

- Воркшопы (мозговые штурмы) — Когда нужно собрать разных людей и быстро набросать процессы или идеи. Идеально использовать доску (Miro, Mural и др).

- Анализ существующих данных и документов — Что уже есть? Старые системы, отчёты в Excel, письма поддержки, документация — кладезь информации.

📝 Правила фиксации: чтобы поняли все и не было двоякого толкования

- Пиши просто и однозначно. Не «Система должна быстро работать», а «Операция поиска клиента по номеру телефона должна выполняться ≤ 1 секунды».

- Используй стандартные шаблоны (User Stories, Use Cases, диаграммы процессов BPMN). Это как общий язык для команды.

Плохие сигналы (того, что всё пошло не так)

- «Это и так очевидно» (ничего не очевидно).

- Заказчик говорит только в абстракциях («дружелюбный интерфейс») и не может привести пример.

- Требования начинают меняться ежедневно без приоритизации (нужен срочный контроль изменений).

- Техническая команда не задаёт уточняющих вопросов (значит, они что-то додумывают сами).

Итог: Идеальных требований не бывает

Задача аналитика — не записать каждую мелочь под диктовку, а выявить истинные потребности, договориться о приоритетах и зафиксировать договорённости так, чтобы и бизнес, и разработка поняли друг друга.

Ваш успех — это не когда вы сдали «в точности как в ТЗ», а когда решили бизнес-задачу и пользователи стали работать эффективнее.

Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов

Сложность: ★★☆ | Время чтения: 11 мин

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

🔗 Читать статью

Чек-лист: 30 API-терминов, которые спрашивают на собеседовании на позицию системного аналитика

1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование
13. OAuth
14. JWT Token
15. API Gateway
16. API Keys
17. Basic Authentication
18. Bearer Tokens
19. CORS
20. Webhooks
21. OpenAPI
22. API Versioning (Версионирование API)
23. Content Negotiation
24. Query Parameters
25. Path Parameters
26. API Documentation
27. API Monitoring
28. Throttling
29. Circuit Breaker
30. Idempotency (Идемпотентность)

Сегодня у нас подборка материалов по сбору требований

- Определение требований: что это такое и как его применять?
- Требования к ПО на пальцах

- Бизнес-требования. Назначение
- Документ бизнес-требований: Что это такое и как его составить [+5 шаблонов]
- Сбор и формирование бизнес-требований для сайта интернет-магазина
- Бизнес-функциональные требования (БФТ): особенности работы и реализации

- Как писать функциональные требования
- Алгоритм описания функциональных требований к системе в формате Use Case

- Нефункциональные требования к программному обеспечению.

Недостатки микросервисной архитектуры

Микросервисная архитектура (MSA) — подход, когда система разбивается на небольшие независимые сервисы.
У MSA есть недостатки, которые важно учитывать при проектировании.

1️⃣ Сложность управления распределёнными транзакциями

В монолите транзакции управляются на уровне БД (ACID). В MSA данные распределены, и обеспечение согласованности требует сложных решений.

➡️ Пример:
заказ оформлен, платёж прошёл, но товар не списался — пользователь заплатил за несуществующий товар.

Практики:
🔹 Saga-паттерны: реализуют оркестрацию или хореографию транзакций с локальными шагами и компенсациями
🔹 Outbox-паттерн: позволяет гарантировать отправку событий в шину сообщений после успешной локальной транзакции

2️⃣ Задержки из-за сетевых вызовов

Межсервисные вызовы (HTTP, gRPC и тд) добавляют сетевые задержки, что может привести к ухудшению UX.

➡️ Пример:
открытие страницы профиля пользователя требует вызовов к 10 сервисам — итого 1+ секунда задержки.

Практики:
🔹Кеширование на уровне API Gateway или Edge Cache
🔹 Асинхронная обработка через сообщения и очереди

3️⃣ Оверхеды мониторинга и трассировки

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

➡️ Пример:
пользователь видит ошибку при оформлении заказа — неизвестно, виноват Cart, Orders или Payments.

Практики:
🔹 Distributed Tracing (Jaeger, Zipkin, OpenTelemetry)
🔹 Централизованные логи (ELK Stack, Loki)
🔹 Метрики и алерты (Prometheus + Grafana)

4️⃣ Сложность тестирования и развёртывания

Каждый сервис может иметь свою БД, конфигурацию и зависимости. Интеграционное тестирование всей системы требует поднятия множества сервисов.

➡️ Пример:
тест Cart Service требует запуска Users, Products и Discounts — иначе тесты падают.

Практики:
🔹Контракты (Contract Testing): Pact, Spring Cloud Contract
🔹 Mock-сервисы и виртуализация (WireMock, Hoverfly)
🔹 Изолированные сценарии на уровне эндпоинтов

5️⃣ Дублирование данных и согласованность

Каждый сервис хранит свою копию данных → возможны расхождения.

➡️ Пример:
пользователь обновил email, но в Order History отображается старый адрес.

Практики:
🔹Event Sourcing и CQRS: разделяют чтение и запись и обеспечивают последовательность событий
🔹 Change Data Capture (CDC): синхронизирует данные между БД через Kafka Connect или Debezium

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

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

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

Сохраняйте, чтобы не потерять!