⌛ Gap-анализ

Gap-анализ — метод выявления расхождений между текущим состоянием системы (As-Is) и целевым состоянием (To-Be)
⚪️цель: определить, какие изменения нужны для достижения результата

Суть

Сравнение двух моделей (текущей и целевой) для выявления отличий, которые мешают достичь конечного состояния

Помогает ответить на вопросы:
⚪️где сейчас? (As-Is)
⚪️куда нужно прийти? (To-Be)
⚪️что мешает туда попасть? (Gap'ы)

Каждый найденный gap трансформируется в конкретные действия: изменения, доработки, внедрения


Зачем нужен

Помогает:
✨ обосновать изменения
✨ сформировать требования к будущей системе
✨ определить объем доработок, сроки, ресурсы
✨ оценить риски и приоритеты внедрения


Когда можно применять

⏺ на этапе пресейла или discovery-фазы
⏺ при внедрении коробочных решений (ERP, CRM)
⏺ при интеграции нескольких систем
⏺ при автоматизации процессов
⏺ при миграции со старой системы на новую


Примеры типов gap'ов

➖Функциональные — отсутствуют нужные функции
➖Процессные — отличаются шаги, роли, триггеры
➖Технические — несовместимость интерфейсов, API
➖Данные — разная структура, нехватка атрибутов
➖Ролевые — не хватает нужных ролей или прав


Пример как проводить

1️⃣Описать текущее состояние (As-Is)
✨Пример: в системе нет уведомлений клиенту.

2️⃣ Определить целевое состояние (To-Be)
Фиксируется желаемое поведение, функции, архитектура, UX
✨нужно автоматическое уведомление клиента через SMS и email

3️⃣ Выявить разрывы (gaps)
Сравниваются состояния по направлениям (функции, данные, процессы и т.п.).
✨Gap — нет интеграции с внешним SMS-шлюзом

4️⃣ Сформировать требования на закрытие gap'ов
✨добавить модуль уведомлений, реализовать логирование отправки

5️⃣ Оценить трудозатраты и приоритизировать изменения
Gap'ы группируются по сложности, влиянию и срочности


Примеры применения

Внедрение ERP
⚪️Gap-анализ выявляет, какие бизнес-процессы нужно адаптировать под коробку, а какие — доработать

Миграция на новую систему
⚪️сравниваются старые и новые функции, выявляются недостающие элементы

Соблюдение законодательства (например, 152-ФЗ)
⚪️позволяет проверить текущие процессы согласно новым требованиям к хранению и обработке персональных данных

Автоматизация ручной отчетности
⚪️Gap: отчеты формируются вручную
→ требуется автоматизация


Типичные ошибки

Поверхностное описание As-Is или To-Be
⏺пример: описание процесса без указания ролей и шагов
→ пропущенные gap'ы, неверные требования, ошибки в архитектуре

Нет детализации функций или данных
⏺не все поля указаны в текущем отчёте
→ неполный результат

Отсутствие вовлечения экспертов и пользователей
⏺анализ проведён только с IT-стороной, без операционного персонала
→ упущены потребности, сопротивление изменениям при внедрении

Смешивание «хотелок» с реальными бизнес-целями
⏺добавлены функции, которые «было бы хорошо», но они не влияют на результат
→ избыточные требования, увеличение сроков и бюджета


📎 Материалы

1. Использование GAP-анализа для выявления и согласования задач по проекту
2. Gap-анализ (анализ несоответствий) и модель развития элементов ит-архитектуры
3. Гэп технологий и бизнеса: стресс/расхождение плана с фактом/причина недостижения целей

#развитие #документация

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

➡ 2PC (двухфазная фиксация)

2PC (Two-Phase Commit) – паттерн для гарантии атомарности* распределенных транзакций
*атомарность – "всё или ничего": либо выполняются все операции транзакции, либо ни одна

🤩Цель: все участники либо фиксируют изменения, либо откатывают их как единое целое, даже при сбоях.
Это критично для согласованности данных в распределенных системах

🤩Принцип работы: протокол выполняется в две фазы под управлением центрального координатора
 

Роли участников

🤩 Координатор (Coordinator)
Управляет процессом, принимает решение
➖центральный управляющий компонент
➖инициирует протокол 2PC
➖принимает решение (Commit/Abort) на основе голосования ресурсов
➖отвечает за уведомление ресурсов о решении и управление восстановлением при сбоях

🤩Примеры
- транзакционные менеджеры
- СУБД-координатор
- оркестраторы

🤩 Ресурсы (участники)
Выполняют локальные операции, голосуют
➖системы или сервисы, управляющие данными (например, БД)
➖выполняют локальную работу транзакции ("до" коммита)
➖голосуют "Да" (готов к коммиту) или "Нет" (не готов) на фазе Prepare
➖выполняют финальную команду (commit/abort) от координатора

🤩Примеры
- БД
- Очереди сообщений
- Legacy-системы


Фазы

➡️Prepare (Подготовка)

🟡 Координатор ➡️ Ресурсы: координатор рассылает ресурсам команду prepare (запрос голосования)
🟡 Ресурсы:
- проверяют возможность коммита своей части транзакции (проверка ограничений, конфликтов, запись в локальный лог для восстановления)
- блокируют данные (локальные блокировки)
- проверяют возможность коммита
🟡 Голосование ресурсов (отправляют координатору):
- vote_commit (если готов)
- vote_abort (если не готов) и выполняют локальный откат

⬅️Commit (Фиксация) / Abort (Отмена)

Если все vote_commit:
🔘 Координатор  ➡️Ресурсы: рассылает команду commit
🔘 Ресурсы фиксируют изменения, разблокируют данные
- фиксируют изменения данных
- освобождают блокировки
- отправляют координатору ack (подтверждение)
🔘 Координатор, получив все ack, завершает транзакцию

Если хотя бы один vote_abort (или таймаут):
🔘 Координатор  ➡️ Ресурсы: abort (или rollback)
🔘Ресурсы откатывают изменения по журналу
- откатывают свою часть транзакции
- освобождают блокировки
- отправляют координатору ack
🔘 Координатор, получив все ack, завершает транзакцию (как отмененную)


Сценарии работы

🤩 Успешная Транзакция

1. клиент делает перевод 100 руб со счета А (ресурс 1) на счет Б (Ресурс 2)
2. координатор шлет prepare обоим банкам
3. банк А: проверяет наличие 100 руб, блокирует их, голосует "Да"
    банк Б: проверяет можно ли зачислить, голосует "Да"
4. координатор шлет commit
5. банк А: Списывает 100 руб, освобождает блокировку
    банк Б: Зачисляет 100 руб. Оба шлют ack
6. клиент получает подтверждение

🤩Отказ ресурса и восстановление

🟡 Сбой во время prepare: ресурс не ответил
Координатор трактует как vote_abort "Нет" → Откат всех

🟡Сбой ресурса после vote_commit: ресурс упал до получения commit
- при восстановлении ресурс смотрит в свой лог: prepare есть, а commit/abort нет
- ждёт команду координатора (состояние "in doubt")

🟡Сбой координатора после записи решения:
- после записи решения → при рестарте пересылает решение ресурсам
- до записи решения → ресурсы остаются заблокированными до ручного вмешательства


Примеры применения

🤩Legacy-системы: интеграция старых монолитных систем (особенно БД) через стандарт XA
🤩когда критична строгая согласованность в реальном времени на уровне отдельных транзакций между разными системами (счета, ленты транзакций, бухгалтерия)
🤩системы, где ресурсы (БД, очереди) поддерживают интерфейс XA для участия в транзакциях под управлением внешнего TM


📎 Материалы

1. Управление транзакциями в бд
2. Способы управления транзакциями в распределённых ИС. Механизм 2pc
3. 2pc в распределённых транзакциях
4. 2pc и будущее распределённых систем 
5. Распределённые транзакции в микросервисах: от SAGA до 2pc

📚 Распределенные системы. Паттерны проектирования – Брендан Бернс

#проектирование #архитектура


➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔼Классы доступности систем

Доступность системы (SA,Service Availability) — отношение времени, когда система работала, к общему времени

Availability (%) = (Время работы / Общее время) × 100

🔘Пример: если система работала 364 дня и 6 часов в году:
Availability = (364.25 / 365) × 100 ≈ 99.79%


Метрики доступности

💙 Uptime / Downtime

💙Uptime — сколько времени система работает
💙Downtime — сколько система была недоступна (по любым причинам: сбои, обновления, ошибки конфигурации)

Эти метрики логируются в большинстве APM/мониторинговых систем (например, Datadog, Pingdom, New Relic, Zabbix)

💙 MTBF (Mean Time Between Failures)

MTBF = Общее время работы / Кол-во сбоев

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

💙MTTR (Mean Time To Recovery)

MTTR = Общее время восстановления / Кол-во инцидентов

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

📌MTBF и MTTR рассчитываются на основе логов событий и инцидентов
🌸Для автоматизации этих расчетов можно использовать Prometheus + Grafana, Zabbix, Datadog


RTO и RPO

🤩RTO (Recovery Time Objective) — за сколько времени должна быть восстановлена система после сбоя

Пример: RTO = 15 мин → система должна заработать не позже чем через 15 мин после сбоя

🤩RPO (Recovery Point Objective) — максимальное допустимое время потери данных

Пример: RPO = 5 мин → допустимая потеря не более 5 мин данных (время с последнего бэкапа или репликации)

❗️Эти параметры обязательно обсуждаются при выборе архитектуры и процедур восстановления


Примеры под разные классы доступности

💙 Класс 99% (базовая надёжность)

💙один сервер, одно приложение, одна БД
💙резервные копии раз в сутки
💙мониторинг вручную или Zabbix/Prometheus без алертов
💙downtime в случае обновлений или перезапуска

💙 Класс 99.9% (высокая доступность)

💙балансировка нагрузки: NGINX / HAProxy
💙минимум два экземпляра приложения
💙репликация БД (например, master-slave PostgreSQL)
💙автоматический мониторинг и алерты (Prometheus + Alertmanager)
💙оркестрация: Docker Compose / простейший Kubernetes кластер

💙 Класс 99.99% (отказоустойчивость)

💙геораспределённость: приложения и БД в разных зонах доступности
💙Active-Passive конфигурация (один сервер работает, второй на подстраховке. При сбое первый отключается, второй включается)
или Active-Active (оба сервера работают одновременно. Нагрузка распределяется. Если один падает — второй продолжает без переключений)
💙автопереключение при сбое: Patroni для PostgreSQL (управляет кластерами PostgreSQL — автоматически назначает нового мастера)
💙CI/CD с canary/blue-green деплоем
💙RTO/RPO оговорены и тестируются

💙Класс 99.999% (непрерывная доступность)

💙многоуровневая геораспределённая архитектура
💙реальное Active-Active с кворумами (например, CockroachDB)
💙самовосстанавливающийся кластер (Kubernetes)
💙контейнерные образы зафиксированы по версии
💙тестирование отказов в проде (chaos engineering)


📎Материалы

1. Классификация критичности информационных систем
2. Типы информационных систем и их уровни защищённости
3. Доступность IT-систем: поругаться или договориться?
4. MTBF — откуда берется «миллион часов MTBF»
5. Разбираемся с метрикой «Среднее временя между сбоями» (MTBF)
6. RTO и RPO: что это и в чём отличия

📚 Site Reliability Engineering. Надежность и безотказность как в Google

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

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

✉️ Apache Kafka: типы доставки | защита от дублей | партиции и масштабирование

Типы доставки сообщений

©️At most once
Продюсер отправляет сообщение и не ждет подтверждения
При сбое данные могут потеряться

➡️ пример: отправка логов, где потеря одной записи некритична

✳️как работает: продюсер не ждёт подтверждения от брокера (acks=0), консьюмер сразу обновляет офсет

©️At least once
Продюсер отправляет сообщение, ждет подтверждения. При сбое может отправить повторно, появляются дубли

➡️ платёжная система, где потеря недопустима, но дубли можно обработать

✳️ продюсер ждёт подтверждения (acks=all), консьюмер обновляет офсет только после обработки

©️Exactly once
Идеальная гарантия: без потерь и дублей. Kafka поддерживает механизм Transactional Producer

Реализуется через:
🔸Идемпотентные продюсеры (Kafka 0.11+) – подавление дублей на стороне брокера
🔸 транзакции между продюсером и консьюмером
🔸 ограничения: работает только в рамках одного кластера Kafka

➡️ обработка заказов: заказ фиксируется в БД + отправляется событие в Kafka в одной транзакции

‼️ на практике exactly once сложно обеспечить
Если Kafka сохраняет сообщение один раз, потребитель может ошибиться (например, дважды обработать запись)

Кратко
🟠At most once → без подтверждения → возможны потери
🟠 At least once → с подтверждением → возможны дубли
🟠 Exactly once → транзакции + идемпотентность → нет потерь и дублей, но дорого и сложно


Защита от дублей

При использовании At least once возможны дубли, нужно предусматривать их обработку

🔸 Индекс уникальности

Можно настроить ключи сообщений так, чтобы консьюмер сохранял только уникальные значения

- продюсер генерирует message_id (UUID или хэш содержимого)
- брокер или БД консьюмера проверяет уникальность перед записью

➡️ пример: база заказов с уникальным индексом по order_id → повторная запись невозможна

🔸 Паттерн Outbox

- при обновлении данных сервис сохраняет событие в отдельную таблицу Outbox вместе с основной записью
- фоновый процесс читает события из Outbox и отправляет их в Kafka

➡️ пример: интернет-магазин записывает заказ в основную таблицу и событие "OrderCreated" в Outbox. Затем отдельный процесс отправляет событие в Kafka

🔸 Паттерн Inbox

Используется на стороне консьюмера
- все события сохраняются в отдельную таблицу Inbox перед обработкой
- при сбое необработанные события можно переобработать без риска дублирования

➡️ пример: сервис оплаты принимает событие "OrderPaid", сохраняет его в Inbox, затем подтверждает обработку

⏪Inbox и Outbox часто применяются вместе, для обеспечения надёжности и идемпотентности при взаимодействии между микросервисами через Kafka⏩


Партиции и масштабирование

Партиция — минимальная единица хранения и обработки сообщений в Kafka
Масштабирование Kafka-кластера напрямую зависит от числа партиций

Связь: партиции ➡️ консьюмеры ➡️ сервисы:
🔵 партиция может быть одновременно прочитана только одним консьюмером в группе
🔵 консьюмер — отдельный процесс или поток приложения, читающий данные из Kafka
🔵 сервис — приложение / микросервис, который внутри себя запускает одного или несколько консьюмеров
🔵каждый экземпляр сервиса (или процесс) фактически становится одним консьюмером Kafka

❗️Важно

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

Почему важно количество партиций

©️если партиций мало → масштабировать обработку за счёт увеличения количества сервисов не получится
©️если партиций много → можно масштабировать консьюмеров горизонтально (новые инстансы будут получать работу)


📎 Материалы

1. Гарантии доставки сообщений в Kafka
2. Синхронизация асинхронности: Dead Letter и Inbox для обработки зависимых сообщений
3. Как обработать миллион сообщений из kafka
4. Под капотом продюсера Kafka: UML-диаграмма публикации сообщений
5. Kafka за 20 минут. Ментальная модель и как с ней работать

📚 Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии

#интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔼🔽Согласованность данных

Согласованность (consistency) — состояние, когда все пользователи и процессы видят одни и те же данные при чтении
🤩согласованность не равна целостности (integrity)
🤩целостность описывает корректность данных внутри системы (например, наличие внешних ключей, ограничения на значения)

🤩согласованное состояние: после завершения операции или транзакции все узлы системы переходят в один и тот же видимый результат.
Иначе пользователи видят разные версии, что может привести к бизнес-ошибкам.


Виды

⚪️Строгая (strong consistency): после записи данные моментально видны всем
✨пример: традиционные реляционные БД с синхронными транзакциями

⚪️В конечном счёте (eventual): данные со временем сходятся, но на промежутке возможны расхождения (DynamoDB, Cassandra)

⚪️Последовательная (sequential): все операции видятся в одном порядке, но нет гарантии мгновенной видимости

⚪️Каузальная (causal): операции, имеющие причинно-следственную связь, видятся в правильном порядке

⚪️Слабая (weak): система не гарантирует моментальной или даже определённой очередности обновлений

При выборе вида согласованности:
✨учитывать нагрузку, ожидаемые задержки, требования к откатам и репликации
✨можно использовать матрицу реiений с параметрами: задержка, SLA по доступности, бизнес-ущерб при ошибке и тд

Примеры

⏺ Критичные данные (банковские счета, заказы, бронирования) ➡️ strong consistency
⏺Для аналитических / временных данных ➡️ eventual consistency или quorum-based решения


CAP-теорема, ACID, BASE и согласованность

🤩CAP-теорема утверждает: распределённая система может одновременно гарантировать только две из трёх свойств:
- согласованность
- доступность
- устойчивость к разделению
🤩Устойчивость к разделению обязательна для любой распределённой системы, выбор обычно стоит между согласованностью и доступностью.


🤩ACID (Atomicity, Consistency, Isolation, Durability) — свойства традиционных реляционных транзакций
🤩Гарантируют строгую согласованность и корректность данных, но плохо масштабируются


🤩BASE (Basically Available, Soft state, Eventually consistent) — подход, характерный для NoSQL-систем:
🤩BASE-системы жертвуют частью согласованности ради масштабируемости и отказоустойчивости


Методы обеспечения согласованности

✨Репликация

✨Синхронная: запись дожидается подтверждения всех реплик. Высокая надёжность, но медленнее
✨Асинхронная: запись подтверждается после обновления основной реплики, остальные догоняют позже. Быстрее, но риск рассинхронизации

✨Консенсус-протоколы

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

✨пример: алгоритмы Paxos и Raft широко используются внутри распределённых БД и сервисов. Для репликации и выбора лидера, чтобы все копии данных оставались согласованными

✨Конфликт-резолвинг

Подходы к устранению расхождений между копиями данных при eventual consistency

✨ CRDT (Conflict-free Replicated Data Types)

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

✨пример: распределённый счётчик, который можно увеличивать на любом узле, а потом безопасно объединять — каждая часть учтётся, независимо от порядка доставки

✨Last-write-wins (LWW)

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

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


📎 Материалы

1. Согласованность: что этои почему с ней все так сложно
2. Проблемы согласованности в микросервисах и их решение
3. Согласованность, Репликация и БД по CAP
4. Паттерны для высокой масштабируемости
5. Руководство по Эффективному Взаимодействию

#проектирование

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Материалы по визуализации работы Apache Kafka и Rabbit MQ

🤩Kafka Visualization
Наглядное представление взаимодействия продюсеров, брокеров, топиков и консьюмеров — в виде анимации или схемы
🤩Kafka Visualization Showcase (видео, англ)
🤩Симулятор брокера Apache Kafka: Kafka Visualization от компании SoftwareMill (обзор с пояснениями)


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

🔹  Kafka vs RabbitMQ: сравнение по пунктам


➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

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

Микросервисная архитектура (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


📎 Материалы

1. Микросервисная архитектура в разработке приложений: преимущества и недостатки
2. Микросервисная архитектура
3. Аутентификация и авторизация в проекте с микросервисной архитектурой: стратегии, практический пример
4. Микросервисная архитектура, ее паттерны проектирования и особенности
5. Микросервисы: плюсы, минусы, когда и зачем внедрять


📚 Книги
1. Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
2. Сэм Ньюмен. Создание микросервисов
3. Микросервисы. От архитектуры до релиза(Ронни Митра, Иракли Надареишвили)
4. Изучаем OpenTelemetry: современный мониторинг систем (2025) - Паркер Остин, Янг Тед

#микросервисы #архитектура

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

⬇️ Ретраи

Ретраи (retries) в проектировании систем — механизм авто-повторения неудачных операций при временных сбоях (сетевых ошибках, перегрузке сервисов и тд)

В распределенных системах временные сбои— норма
Вызов "повторить при ошибке" может усугубить проблему


Виды ошибок

Не все ошибки равны: ретраить можно только временные сбои.
Постоянные ошибки повторять бесполезно и вредно для ретраев

🔼 Повторяемые ошибки

Временные сбои, которые могут исчезнуть при повторной попытке

Типичные кейсы повторяемых ошибок:

◾️Сетевые сбои
Таймауты TCP, Connection Reset
➡️ проблемы балансировщика, кратковременная недоступность сети

◾️Ограничения ресурсов
HTTP 429 (Too Many Requests)
➡️ превышение лимитов API (Rate Limiting)
пример: пльзователь массово экспортирует данные → API временно ограничивает запросы

◾️Ошибки серверов
HTTP 5xx (503, 504)
➡️ перегрузка сервера, деградация БД
пример: (HTTP 503) сервис перегружен в час пик

◾️Конфликты данных
Дедлоки БД, оптимистичные блокировки
➡️ конкурентные транзакции
пример: деадлоки БД - два клиента одновременно редактируют один заказ

⤵️ Постоянные ошибки

🔹HTTP 400 (Bad Request)
Клиент отправил невалидные данные (например, буквы в поле "Цена"). Повторы бесполезны

🔹HTTP 404 (Not Found)
Ресурс удален (например, несуществующий ID товара). Повторы создают нагрузку

🔹HTTP 403 (Forbidden)
Постоянное отсутствие прав (например, просмотр чужих заказов)


Стратегии повторов

🤩Экспоненциальная задержка (Exponential Backoff)

Растущая задержка: 1с → 2с → 4с → 8с
Для снижение нагрузки на сбойный ресурс, дает ему время на восстановление

✨пример: пользователь оплачивает заказ → платежный шлюз временно недоступен → система повторяет через 0.5с, 1с, 2с → 95% платежей проходят со 2-3 попытки

🤩Джиттер (Jitter)

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

Фактическая задержка = Базовая задержка + random(0, 30% от задержки)
Для предотвращение синхронизации запросов

✨пример: 10 000 корзин ожидают оплаты
Без джиттера: повтор всех 10к запросов одновременно → Коллапс платежной системы
С джиттером: запросы распределяются равномерно

🤩Комбинированные подходы

a) Retry-After + Backoff
Использование заголовка HTTP Retry-After для точного определения задержки

HTTP/1.1 429 Too Many Requests
Retry-After: 15 ← Ждать ровно 15 секунд

✨ когда использовать: при интеграции с внешними API

b) Адаптивные ретраи
Динамический расчет задержки на основе:
- истории ответов сервиса
- текущей нагрузки
- SLA системы и тд

✨пример: система логирования увеличивает задержку с 1с до 10с при 1000 ошибок/мин.

🤩Ограничение попыток

Максимальное число ретраев (напр. 3-5).
Это предотвращает бесконечные циклы.

После исчерпания попыток— фиксируется ошибка
✨например:
- асинхронная обработка (отправка в очередь)
- уведомление мониторинга


Circuit Breaker ("предохранитель" системы)

Это "автомат", который временно блокирует вызовы сбойного сервиса

🌸 принцип: после N ошибок за период T, все последующие вызовы завершаются ошибкой без реального вызова ресурса.
Периодически проверяет "полуоткрытое" состояние.

💡 Следует определить пороги срабатывания (N, T), время восстановления
Связать с SLA и поведением системы при отказе.

Состояния брейкера:
🔵Closed: вызовы проходят
Система работает нормально
🔵Open: вызовы блокируются (ошибка без реального запроса)
После 5 ошибок за 1 мин
🔵Half-Open: Пропускает часть трафика для проверки восстановления

➡️кейс: сервис отправки SMS падает → Circuit Breaker блокирует вызовы на 2 мин → предотвращает:
- потерю денег за SMS
- перегрузку очереди сообщений
- каскадные сбои


📎 Материалы

1. Хороший ретрай, плохой ретрай, или История одного падения
2. Отложенные ретраи силами RabbitMQ
3. Как работать над перфомансом веб-приложения: опыт Авто.ру|
4. Лучшие практики создания отказоустойчивых систем

🔹 Производительность API: краткий обзор способов

📚 Паттерны проектирования API - Джей Гивакс (Часть IV. Безопасность)

#проектирование #api

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ Идемпотентность в распределённых системах

Идемпотентность — свойство операции, гарантирует, что повторное выполнение одной и той же операции приведёт к такому же результату, как и первое выполнение
Т.е. если отправить один и тот же запрос 10 раз, результат должен быть таким же, как если отправить его один раз

🟢пример: если повторное списание денег с карты не приводит к новому списанию, а возвращает результат первого списания — операция идемпотентна
Если же деньги спишутся дважды — нарушение идемпотентности

В распределённых системах сетевая ненадёжность, таймауты и ретраи делают это свойство критически важным

Примеры проблем обеспечения идемпотентности

🔘повторные сетевые запросы: клиент не получил ответ вовремя (из-за таймаута, сетевого сбоя) и отправил запрос повторно. Сервер успешно обработал первый запрос
🔘дубли сообщений в брокерах: гарантируют доставку как минимум одни раз (at-least-once). При сбое потребителя сообщение может быть доставлено повторно
🔘неопределённость состояния при сбоях: cервис обработал запрос, но упал до того, как отправил подтверждение. Оркестратор (н-р, Kubernetes) перезапустит контейнер, и обработка перезапустится

Примеры последствий отсутствия идемпотентности

➖фин потери (двойные списания)
➖нарушение консистентности данных (два одинаковых пользователя в БД)
➖времязатратные отладки и исправления данных


Подходы к реализации идемпотентности

Уникальный id запроса (Request ID)

Клиент генерирует уникальный ID (UUID) для каждой бизнес-операции и передаёт в каждом запросе (например, в HTTP-заголовке Idempotency-Key)
Сервер, получив запрос, проверяет, не обрабатывался ли уже запрос с таким ID
🟣Если нет — выполняет операцию и сохраняет результат в быстрое хранилище (н-р, Redis) с ключом = ID
🟣Если да — возвращает сохранённый ранее ответ, не выполняя операцию повторно

✅ Плюсы: относительно просто, универсальность (подходит для REST, gRPC, Webhooks)
✖️ Минусы: требует наличия быстрого хранилища состояния для всех инстансов сервиса. Необходимо определять TTL для ключей

Подходит для идемпотентных POST-запросов в API (н-р, создание платежа, заказа)

Журналирование и Outbox-паттерн

Паттерн для надежной отправки сообщений в брокер в контексте транзакции с БД
🔘сервис не отправляет сообщение в брокер напрямую
🔘он в рамках одной транзакции записывает сообщение в специальную таблицу в БД (outbox)
🔘отдельный процесс (CDC) считывает новые записи из outbox и публикует их в брокер
🔘после успешной публикации запись из outbox удаляется

✔️ гарантирует отправку сообщения в брокер только тогда, когда бизнес-транзакция commit'ится. Решает проблему дублей на стороне отправителя
✖️ архитектурная сложность, необходимость настройки и поддержки CDC-процесса

Микросервисные асинхронные интеграции, где критична гарантия доставки события после записи в БД

Exactly-Once на уровне брокеров

Брокеры предлагают встроенные механизмы для обеспечения семантики "точно один раз"
🟣Для продюсеров: использование transactional id и подтверждений от всех партиций (acks=all) гарантирует, что сообщение не будет потеряно и не будет записано дублем
🟣Для консьюмеров: чтение сообщения и commit offset'а происходят атомарно. Консьюмер не получит одно и то же сообщение дважды после успешной обработки и коммита

✔️ высокая надёжность "из коробки"
✖️ сложность конфигурации, расходы на производительность, привязка к конкретной технологии

В проектах на Kafka, где требования к надёжности обработки потоков данных крайне высоки


📎 Материалы
1. Идемпотентность: что это, примеры и применение в API
2. Как сделать хорошую интеграцию? Часть 2. Идемпотентные операции – основа устойчивой интеграции
3. История одного идемпотентного метода
4. Идемпотентность в такси-приложении: кейс из практики
5. Стажёр Вася и его истории об идемпотентности API
6. Важность идемпотентности в распределенных системах

🔹 Обеспечение идемпотентности API

📚 Книги
1. Высоконагруженные приложения - Мартин Клеппман (Глава 11)
2. Создание микросервисов - Сэм Ньюмен (Глава 12)

#проектирование

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Масштабируемые данные.
Лучшие шаблоны высоконагруженных архитектур.

✍️ Автор: Питхейн Стренгхольт
🗓 Год издания: 2022
🔤 Язык: русский
📚 Объём: 368 стр

Посвящена современному управлению данными и масштабируемым архитектурам, необходимым для работы с большими объемами информации.

В ней рассматриваются:
💙основы управления данными – что это такое, почему оно важно и как развивается в эпоху цифровой трансформации.
💙ключевые архитектурные подходы – хранилища данных (только для чтения), API, потоковая обработка и их интеграция в единую систему.
💙сложности работы с данными – проблемы интеграции, устаревание классических хранилищ, управление метаданными и безопасность.
💙практические шаблоны и решения – как выбирать подходящие модели распределения данных, масштабировать их потребление и обеспечивать целостность.
💙влияние новых технологий – гибридные облака, распределенные сети и их роль в архитектуре данных.

Книга сочетает теорию и практику, подойдет для архитекторов, аналитиков, специалистов по соблюдению требований и управлению

Обзор книги на Хабр

#проектирование

⚙️ Apache Kafka: экосистема

Apache Kafka - платформа для потоковых данных
Включает:
⚫️Kafka Connect
⚫️ksqlDB
⚫️Kafka Streams

Kafka Streams

Библиотека для обработки потоков событий с возможностью:
🤩 Агрегации: подсчет количества событий за период для каждого ключа
➡️ количества кликов по рекламе для каждого пользователя за последний час
🤩Обогащении: дополнение событий данными из внешних систем или других топиков
➡️ добавление информации о профиле пользователя к событиям покупок
🤩Фильтрации: отбор нужных событий
🤩Трансформации: изменение формата/структуры сообщения
➡️ конвертация из бинарного формата Avro в JSON
🤩Объединения: данные из нескольких топиков
➡️ объединение данных о заказах и платежах

Архитектурная идея: микросервисный подход к потоковой обработке
Kafka Streams инкапсулирует логику обработки в независимое приложение, оно масштабируется вместе с кластером Kafka
🤩Обадает отказоустойчивостью
🤩Не требует развертывания отдельной инфраструктуры

Хранение данных между обработками

Для этого используется:
✨State Store — локальное хранилище внутри Kafka Streams, где находятся текущие вычисления
✨Changelog Topic — специальный топик в Kafka, куда записываются изменения в State Store
Если приложение перезапускается, то загружает данные из этого топика и продолжает работу с того же места
По умолчанию Kafka Streams хранит состояние локально, но обработанные данные можно записывать во внешние БД или облачные хранилища

Примеры использования

🤩Обработка транзакций с добавлением информации о пользователе из внешней БД
🤩 обогащение данных о платеже информацией о возрастной группе и истории покупок пользователя для системы фрод-мониторинга.

🤩Трансформация данных из формата Avro в JSON с валидацией и фильтрацией некорректных записей
🤩 очистка и преобразование данных логов веб-сервера перед загрузкой в аналитическое хранилище


Kafka Connect

Фреймворк для масштабируемого ввода/вывода данных между Kafka и внешними системами
Решает задачи интеграции с различными источниками

⏩ Пример: синхронизация данных между PostgreSQL и Elasticsearch
Источник (JDBC Connector) читает изменения из БД с помощью механизма изменения данных Debezium, а приемник (Elasticsearch Connector) загружает данные в поисковый индекс для быстрого поиска

Особенности
⏺готовые коннекторы для популярных систем
⏺автоматическое управление смещениями: отслеживание позиции обработки для каждого коннектора
⏺масштабирование через распределенный режим работы в кластере
⏺поддержка преобразований данных: встроенные онлайн преобразования форматов данных


ksqlDB

СУБД для потоковой обработки
➖позволяет выполнять SQL-запросы к данным в топиках Kafka
➖применяется для быстрого прототипирования и простых ETL-задач без кода на Java

🤩Пример: мониторинг аномальной активности пользователей в реальном времени.
Например, обнаружение пользователей, выполняющих более 100 действий в минуту, с отправкой уведомлений в систему безопасности

Особенности
🤩SQL-синтаксис для потоковой обработки
🤩поддержка оконных агрегаций и joins - возможность объединения потоков данных и агрегации по временным окнам
🤩REST API для управления потоковыми запросами

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


📎 Материалы
1. Kafka Streams (official site)
2. Экосистема Apache Kafka: Kafka Streams, Kafka Connect
3. Потоковая обработка данных с помощью Kafka Streams: архитектура и ключевые концепции
4. Под капотом Kafka Connect: источники, приемники и коннекторы
5. ksqlDB
6. ksqlDb или SQL как инструмент обработки потоков данных

📚 Книги
1. Kafka Streams и ksqlDB: данные в реальном времени - Сеймур Митч
2. Kafka в действии - Дилан Скотт, Виктор Гамов и Дейв Клейн (Глава 12)

#интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔽Debezium

Debezium - распределенная платформа с открытым исходным кодом, которая превращает существующие БД в стриминговые источники событий

⏬«Подписывается» на журналы СУБД и захватывает каждое изменение на уровне строки и отправляет его в Apache Kafka в виде структурированных событий

Оптимален когда нужна
🔵обработка изменений в реальном времени
🔵поддержка сложных преобразований данных
🔵интеграция с экосистемой Kafka
🔵требования к кастомизации и контролю


Архитектура и компоненты

Работает как набор коннекторов для Apache Kafka Connect
Каждый коннектор специализируется на конкретной СУБД и реализует протокол репликации этой базы

Основные компоненты

✨коннекторы — отдельные для PostgreSQL, MySQL, SQL Server, Oracle, MongoDB и Db2
✨транзакционные журналы БД, откуда Debezium читает
✨схема сообщений — каждое событие содержит данные до/после изменения, метаданные операции и информацию об источнике
✨Kafka Connect Framework

💚Debezium можно интегрировать не только с Kafka
С помощью Debezium Engine события можно получать напрямую в приложение или транслировать в другие брокеры: RabbitMQ, Pulsar, Redpanda


Принцип работы

💙 Поток данных кратко
БД → журнал транзакций → Debezium connector → Kafka Connect → Kafka topic → потребитель (микросервис, аналитическая система, хранилище)

Процесс обработки изменений от журнала до топика Kafka

💙Подключение к БД
Коннектор подключается к БД с правами репликации

💙 Создание снимка (snapshot)
При первом запуске коннектор создает снимок данных
Последовательно читает таблицы и генерирует события создания для каждой строки
Этот процесс гарантирует, что все существующие данные попадут в поток событий

💙Непрерывное чтение журнала транзакций
После завершения снимка коннектор переключается на чтение транзакционного журнала. Отслеживает позицию последнего обработанного события и продолжает чтение с этой точки при рестарте

💙 Преобразование изменений
Каждая запись в журнале парсится и преобразуется в событие JSON / Avro
Debezium обрабатывает различные типы данных СУБД, включая XML и пользовательские типы.

💙Отправка в Kafka
События отправляются в топики Kafka. Коннектор использует семантику at-least-once, что требует идемпотентной обработки на стороне потребителей.


Примеры использования

💚Интеграция Legacy-БД с микросервисами: старое монолитное приложение пишет в общую базу, Debezium транслирует изменения в события для микросервисов.
💚Event Sourcing / CQRS. Debezium можно использовать как источник событий, превращая БД в event log.
💚Репликация в DWH или Data Lake
💚Аудит изменений. Логировать все операции по таблицам, не меняя код приложений.
💚Синхронизация с индексами и кешами. Например, изменения в PostgreSQL сразу обновляют Elasticsearch или Redis


Проблемы и риски

💙нагрузка на СУБД: при первом снэпшоте Debezium сканирует таблицы. Это может перегрузить продакшн.
💙обработка DDL: добавление или удаление колонок не всегда корректно обрабатывается.
💙exactly-once: Debezium гарантирует at-least-once. Exactly-once зависит от конфигурации Kafka и потребителей.
💙сбои: при падении соединения коннектор должен корректно продолжить чтение с последнего offset. Иногда возможны дубликаты.
💙версионные миграции: новые версии коннекторов могут менять формат событий.


📎 Материалы

1. Официальный сайт
2. CDC в Yandex Data Transfer: гид по технологии с примерами
3. Что такое Debezium и для чего используется
4. Знакомство с Debezium — CDC для Apache Kafka
5. Что такое Debezium: подробная инструкция по применению
6. Debezium Architecture

#интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ gRPC: подробнее

❤️gRPC: краткий обзор❤️

gRPC реализует парадигму удаленного вызова процедур (RPC), где клиент вызывает методы на сервере так, будто они находятся в одном процессе


Protocol Buffers

Процесс разработки с gRPC начинается с проектирования контракта в proto-файлах

Контракт (.proto файл) — единая точка, в которой описываются:
🟢структуры данных (сообщения)
🟢методы сервисов
🟢входные / выходные параметры

На основе proto-файлов автоматически генерируется клиентский и серверный код для разных языков ➡️ снижает риски несовместимости

🟢Protobuf — наиболее часто используемый IDL для gRPC
Здесь хранятся данные и функциональные контракты в виде proto-файла


gRPC Interceptors

Interceptor ("перехватчик") — компонент, который позволяет внедрять пользовательскую логику в обработку вызовов gRPC на стороне клиента / сервера
Предоставляет механизм для изменения запросов и ответов, а также для выполнения доп действий

Интерсепторы оперируют:
🔴именами сервисов и методов
🔴метаданными вызовов
🔴статусами выполнения
🔴таймингами и ошибками

Protocol Buffers определяют ЧТО передается
Интерсепторы - КАК обрабатываются вызовы

Сценарии использования

🟢проверка токенов, валидация прав доступа к методам, добавление учетных данных в метаданные
🟢сбор статистики по времени выполнения, количеству вызовов, ошибкам. Интеграция с системами мониторинга
🟢логирование входящих и исходящих вызовов, трассировка запросов в распределенных системах
🟢Retry-логика, таймауты, circuit breakers, балансировка нагрузки на клиентской стороне
🟢проверка корректности запросов, преобразование данных, кэширование ответов


gRPC и Kafka

♥️gRPC — про синхронные вызовы
♥️Kafka — про асинхронный обмен событиями. Обычно дополняют друг друга:

gRPC обрабатывает пользовательский запрос «здесь и сейчас»
Kafka распространяет событие дальше

🟢Пример: система заказов

Клиент → gRPC → Сервис А → Kafka → Сервис Б, Сервис В

1. Клиент через gRPC создает заказ
2. Сервис заказов обрабатывает команду "создать заказ"
3. Публикует событие "OrderCreated" в Kafka
4. Сервисы уведомлений и аналитики получают событие из Кафка


Примеры архитектуры с gRPC

✅банковская система: gRPC связывает микросервисы обработки платежей, управления счетами и проверки безопасности

✅приложение для доставки: gRPC-streaming для получения обновлений о местоположении курьера в реальном времени

✅стриминговый сервис: gRPC управляет коммуникацией между сервисами рекомендаций, биллинга и контент-доставки
Двунаправленные стримы - для управления видеопотоками


Безопасность в gRPC

gRPC изначально ориентирован на защищённые каналы:

🟢TLS по умолчанию — все соединения зашифрованы
🟢mTLS — взаимная аутентификация сервисов (не только клиент проверяет сервер, но и сервер проверяет клиента)
🟢метаданные — передача токенов (JWT, OAuth2, API-ключи)
🟢интерсепторы — проверка прав доступа , логирование, метрики
🟢короткоживущие токены и регулярное обновление сертификатов


📎 Материалы
1. Введение в gRPC: Основы, применение, плюсы и минусы
2. Что такое gRPC и Protobuf?
3. Способ организации gRPC контрактов и их автоматизация для микросервисов
4. Protocol Buffers: самая эффективная бинарная альтернатива текстовому формату
5. gRPC Interceptors (документация)
6. Перехватчики gRPC в .NET

📚 Изучаем OpenTelemetry: современный мониторинг систем (2025) - Паркер Остин, Янг Тед

#интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔗 Подборка материалов по архитектуре

🔘Бесплатные курсы

⏯ Youtube
➖Курс по архитектуре приложений. Путь архитектора решений (53 видео)
➖Архитектура ПО (13 видео)
➖Проектирование программного обеспечения (14 видео)

⚫️ Stepik
➖Архитектура информационных систем (для новичков)
➖ИТ-инфраструктура предприятия: вводный курс


🔹 Посты из канала
➖Архитектурные паттерны (MV(X)
➖Распределенные системы: архитектурные паттерны и стили
➖Антипаттерны проектирования ПО
➖Паттерны проектирования и архитектурные паттерны
➖TOGAF. Краткий обзор
➖SOA vs MSA

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

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше статей по этой теме в базе знаний по системному анализу

⌛ Жизненный цикл API

💙 Проектирование

Сбор требований от всех стейкхолдеров (бизнес-заказчики, фронтенд-разработчики, мобильные разработчики и тд) и трансформировать их в контракт

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

Ключевые элементы:
💙анализ требований: стейкхолдеров и потребителей (что должно делать API, для кого и зачем)
💙Design First подход: — создание спецификации до написания кода (например, в формате OpenAPI (Swagger)
💙прототипирование: на основе спецификации можно сгенерировать "заглушку" API (mock-сервер)
💙стандартизация: форматов ошибок, пагинации, структур данных и тд


💙 Разработка: от спецификации к коду

Реализовать логику API по спецификации

Процесс включает:
💙итеративную разработку по спецификации
💙интеграцию с БД и внешними сервисами
💙регулярный код-ревью и статический анализ
💙написание модульных тестов параллельно с разработкой


💙 Тестирование

Комплексная проверка надежности, безопасности и производительности API
Основа для тестирования: тестовые сценарии и данные

Виды тестирования:
💙функциональное — проверка соответствия спецификации
💙нагрузочное — тестирование производительности
💙контрактное — соответствия реализации спецификации
💙безопасности — проверка на уязвимости


💙 Публикация и CI/CD

Обеспечить быструю, безопасную и предсказуемую публикацию изменений в API

Ключевые процессы:
💙интеграция спецификации в CI/CD: спецификация OpenAPI хранится в репозитории вместе с кодом.
💙авто-проверки при создании Pull Request
💙авто-сборка, тесты и деплой при мерже в основную ветку
💙соблюдение семантики версионирования:
💙обратно-совместимое изменение — v1.0.0 → v1.1.0
💙ломающее изменение — v1.1.0 → v2.0.0


💙 Управление

Централизованное управление трафиком, безопасностью и версиями API через API-шлюз

Основные функции:
💙настройка политик в API Gateway: настройка лимитов запросов (rate limiting)
💙управление аутентификацией и авторизацией (API-ключи, OAuth токены)
💙кеширование ответов
💙мониторинг трафика и выявление аномалий


💙 Ввод в эксплуатацию

Гарантия отказоустойчивости и производительности API в проде

Основные функции:
💙определение SLO/SLA, настройка мониторинга метрик производительности
💙настройка автомасштабирования под нагрузку
💙создание механизмов резервного копирования и процедуры обработки инцидентов


💙 Анализ и мониторинг

Сбор и анализ метрик

Примеры метрик:
💙количество вызовов и уникальных потребителей
💙время ответа и процент ошибок
💙география запросов


💙 Продвижение и💙Монетизация

Эти этапы в большей степени относятся к продуктологам и бизнес-аналитикам

Примеры метрик для оценки эффективности продвижения API:
1. Активные пользователи (Active Users)
2. Новые регистрации (New User Registrations)
3. Количество API-вызовов (API Calls)
4. Метрики производительности
5. Бизнес-метрики

Для монетизации необходимо спроектировать систему тарификации и метрики для нее, заложить логику в систему аналитики и биллинга.


💙💙 Вывод из эксплуатации

Минимизировать ущерб для потребителей при выводе устаревшей версии API.

Процесс вывода:
💙планирование (например, "Версия v1 будет объявлена устаревшей 1 января, а полностью отключится 1 июля")
💙уведомление всех потребителей через документацию
💙создание миграционных гидов и архивное хранение


📎 Материалы
1. Жизненный цикл API. Статистика и нюансы
2. Жизненный цикл API
3. 15 важнейших рекомендаций по проектированию REST API
4. Дизайн API и как его спроектировать
5. Лучшие практики разработки REST API: 20 советов

📚 Книги
1. API - Сергей Константинов
2. Паттерны проектирования API - Джей Гивакс
3. Тестирование веб-API - Марк Винтерингем
4. Проектирование веб-API - Арно Лоре

#api

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

⬇️ Обратная совместимость интеграций

Обратная совместимость — когда система может работать с более старыми клиентами или потребителями после внесения изменений в интерфейс или формат данных

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

▫️ Принцип: поставщик данных эволюционирует без требования изменений от потребителей


Виды совместимостей

⚪️Backward compatibility (обратная) — новые версии совместимы со старыми клиентами
⚪️Forward compatibility (прямая) — старая версия может работать с будущими данными
⚪️Full compatibility (полная) — поддерживаются оба направления

⭐️ Для интеграций чаще всего важна обратная совместимость: не ломать то, что уже работает


Примеры обеспечения обратной совместимости

⚪️Версионирование: явное указание версии контракта через URI, заголовки или параметры

⚪️Добавление новых функций без изменения существующих

⚪️Deprecated-стратегия:
💚сначала поле/метод помечается как устаревший - "deprecated", но остается доступным.
💚через несколько релизов удаляется, после уведомления потребителей

⚪️Контрактное тестирование (Consumer-Driven Contracts): подход к тестированию интеграций, при котором контракт (API, сообщение, схема) формируется не со стороны провайдера, а со стороны потребителя

⚪️Feature flags и поэтапное внедрение:
💚дается потребителям время перейти на новую схему
💚одновременно поддерживаются старый и новый формат


⏩ Обратная совместимость в REST API

Практики:

*️⃣поля в JSON только добавлять, не удалять. Обязательные поля не удалять, а помечать deprecated
*️⃣новые поля делать необязательными (nullable).
*️⃣переименование заменять на добавление нового поля + "депрекейт" старого.
*️⃣версионирование через заголовок "Accept", не нарушает структуру URI.
*️⃣сохранять семантики HTTP-кодов и методов для существующих эндпоинтов


⏩ В gRPC

gRPC использует Protocol Buffers (protobuf)
Он изначально учитывает обратную совместимость

Практики:

➕добавлять новые поля с уникальными номерами тегов
➕делать поля optional
➕не удалять старые поля, помечать их deprecated
➕никогда не менять значения tag-ID
➕при необходимости переименования — объявлять новое поле с новым tag.
➕версионировать proto-файлы (package v1, v2).


⏩ В GraphQL

GraphQL более гибкий, чем REST, так как клиент сам выбирает нужные поля. Но есть риски.

Практики:

⏺использовать директиву @deprecated вместо удаления. Клиенты будут видеть предупреждение.
⏺избегать изменений типов существующих полей
⏺поддерживать старые поля до тех пор, пока все клиенты не перейдут.
⏺для больших изменений — новая схема (например, /graphql/v2).


⏩ В Apache Kafka

Kafka — шина событий. Здесь контракт — формат сообщения.
Если продюсер изменил структуру, все консумеры должны понимать новый формат

Практики:

✨использование Schema Registry для управления схемами
✨применение политик совместимости:
➖backward — новые сообщения читают старые консумеры
➖forward — новые консумеры читают старые сообщения
➖full— поддерживаются оба направления
✨возможность перечитывания исторических данных
✨не менять типы полей
✨не удалять поля без "депрекейта"
✨для критичных изменений — новый топик (orders.v2)


📎 Материалы
1. Обеспечение обратной совместимости gRPC API с помощью protolock в GitHub Actions
2. Постановка проблемы обратной совместимости
3. Интеграции глазами аналитика: 5 типичных ошибок, которые ломают систему
4. Как правильно разрабатывать API с поддержкой обратной совместимости
5. GraphQL: от восторга до разочарования

📚 Книги
API - Сергей Константинов (Раздел III. Обратная совместимость)
🐗 Высоконагруженные приложения. Программирование, масштабирование, поддержка - Мартин Клеппман

#интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

📃 Основы проектирования БД

Рассмотрим нисходящий подход проектирования БД

Процесс проектирования по шагам

🔹концептуальное проектирование — анализ и описание бизнес-сущностей без привязки к технологиям
🔹логическое — преобразование бизнес-модели в структуру таблиц, ключей и связей
🔹физическое — реализация модели в конкретной СУБД с учетом особенностей хранения, типов данных, индексов и оптимизации

Между этими этапами используется ER-диаграмма — инструмент визуализации


1️⃣ Концептуальная модель

Задача: понять и описать какие данные нужны системе и как они связаны между собой
❌ не решается, в какой СУБД будет хранить информацию и как будут называться таблицы

Основные шаги

🔘определить сущности: ключевые объекты, информацию о которых будет храниться (например, «Пользователь», «Заказ», «Товар»)
🔘описать связи между сущностями, т.е как сущности взаимодействуют друг с другом (например, «Пользователь оформляет Заказ»).
🔘выделить атрибуты сущностей: характеристики, которые описывают каждую сущность (например, «ФИО» у пользователя, «цена» у товара)
🔘зафиксировать правила предметной области (например, заказ всегда связан хотя бы с одним товаром).


2️⃣ Логическая

Создание реляционной схемы. ER-модель преобразуется в формальную схему, готовую для реализации в реляционной СУБД (распространенный тип БД).

Основные шаги

◾️cоздать таблицы по сущностям
Например, сущность «Пользователь» превращается в таблицу users.
◾️определить атрибуты как столбцы таблиц
У «Пользователя» будут поля: id, name, email.
◾️ задать ключи:
- первичный ключ (id) для уникальной идентификации строки
- внешние ключи для связи между таблицами
◾️нормализовать таблицы
- убрать повторы и избыточные данные
- проверить соответствие нормальным формам (1НФ, 2НФ, 3НФ)
Например, если в таблицу «Заказ» включить название товара, это приведет к дублированию

Решение: выделить отдельную таблицу «Товар» и связать через «Заказ–Товар»
◾️определить индексы


3️⃣ Физическая

Модель адаптируется под конкретную СУБД:

🔹выбираются типы данных (VARCHAR, INTEGER, DATE)
🔹настраиваются индексы, триггеры, процедуры
🔹проектируется стратегия хранения больших данных (шардинг, партиционирование)
🔹учитываются ограничения конкретной СУБД (PostgreSQL, MySQL, Oracle и т. д.)


📎 Материалы

1. Как работают базы данных в IT: разбор на примерах
2. Базы данных для системного аналитика. Краткий обзор на практике
3. Основы правил проектирования базы данных
4. Основы проектирования баз данных
5. Проектирование реляционных баз данных: основные принципы

📚 Книги
1. Основы баз данных (учебное пособие) - Кузнецов С. Д.
2. Путеводитель по базам данных - Владимир Комаров
3. Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити
4. Проектирование и реализация систем управления базами данных - Эдвард Сьоре
5. Основы технологий баз данных: учебное пособие - Новиков Б. А. и др

#проектирование #бд

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ SDLC: Жизненный цикл ПО

Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) — структурированный процесс создания систем
Путь идеи от концепции до рабочего продукта


Фазы жизненного цикла ПО

1️⃣Инициация (Планирование)

Определяется цель проекта, его границы и заинтересованные стороны
Оценивается бизнес-ценность, риски и целесообразность разработки
Результат фазы — бизнес-кейс, дорожная карта проекта, первичные требования и оценка ресурсов

2️⃣ Сбор и анализ требований

Вывляются:
🔸проблемы бизнеса, которые нужно решить
🔸функциональные требования (что система должна делать)
🔸нефункциональные требования (какими качествами обладать: производительность, безопасность, надежность)

Выходные артефакты: ТЗ или спецификация требований к ПО (SRS), модели процессов, диаграммы прецедентов

3️⃣ Проектирование

Решается как система будет удовлетворять требованиям

〰️архитектура системы: Выбираются технологии, определяются основные компоненты и их взаимодействие (микросервисы, монолит)
〰️проектирование данных: разрабатывается модель БД
〰️проектирование интерфейсов: как система будет взаимодействовать с пользователями (UI) и другими системами (API)

Результат — набор архитектурных и дизайнерских документов

4️⃣ Разработка (реализация)

Пишется код в соответствии с архитектурой и требованиями
Ревью кода, сборка и автоматизация сборочного процесса через CI/CD

На выходе — рабочие модули и инкременты системы

5️⃣ Тестирование

Проверяется соответствие продукта требованиям

Примеры тестирования:
⚫️модульное (проверка отдельных компонентов)
⚫️интеграционное (проверка взаимодействия компонентов)
⚫️системное (проверка системы в сборе по всем требованиям)
⚫️приемочное (финальная проверка с заказчиком)

6️⃣ Внедрение

Продукт разворачивается в целевой среде

〰️развертывание на production-серверах
〰️перенос данных из старых систем
〰️обучение пользователей
〰️подготовка документации

Завершается релизом и переходом системы в эксплуатацию

7️⃣ Эксплуатация и сопровождение

После запуска система требует поддержки:
🟣исправление ошибок
🟣адаптация к изменениям в окружении (например, обновление ОС)
🟣новые функциий и улучшения
🟣тех поддержка пользователей

Фаза продолжается до момента окончательного вывода системы из эксплуатации


Модели жизненного цикла ПО

Подход к организации фаз SDLC определяется моделью: как эти фазы взаимодействуют друг с другом, их последовательность

🔵 Последовательные (плановые)

🔹Каскадная (Waterfall)

Фазы выполняются строго последовательно: от анализа до сопровождения
Переход на следующую стадию возможен только после завершения предыдущей

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

🔹 V-модель (Verification & Validation)

Идея каскада с добавлением акцент на тестирование
Каждая стадия разработки имеет свой этап проверки и валидации

🟢 Инкрементальные

Продукт создаётся поэтапно, небольшими инкрементами. Каждый релиз добавляет часть функционала
Каждый инкремент проходит полный цикл SDLC (анализ, проектирование, кодирование, тестирование)

В результате пользователь постепенно получает готовые части системы

🟡 Итерационные (адаптивные)

🔸Спиральная

Комбинирует идеи каскадной и прототипной моделей
Каждая итерация проходит все фазы SDLC, но с акцентом на анализ рисков

Применяется для крупных и исследовательских проектов

🔴 Гибкие (Agile)

🔸 Scrum

Разработка короткими итерациями — спринтами (1–4 недели). Команда поставляет работающий инкремент продукта к концу каждого спринта.

🔸 Kanban

Ориентирован на непрерывный поток задач и визуализацию процессов
Основной инструмент — канбан-доска, где задачи перемещаются по статусам


📎 Материалы
1. Этапы жизненного цикла разработки ПО или что такое SDLC?
2. SDLC
3. База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
4. Про семь основных методологий разработки
5. Модели жизненного цикла ПО

📚 Книги
Управление проектным бизнесом от Алексея Васильева

#инфраструктура

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

📌 Event Storming

Event Storming — техника коллективного моделирования бизнес-процессов

Строится вокруг событий (domain events), которые отражают значимые изменения состояния системы (заказ создан», платёж подтверждён, товар доставлен)

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


Примеры приименения

➡️ запуск новой системы
➡️ проектирование микросервисной архитектуры
➡️ анализ существующего (legacy) решения перед рефакторингом
➡️ уточнение сложных или неявных процессов между подразделениями

Основные принципы

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


Типы Event Storming-сессий

✳️ Big Picture
Используется для получения общего представления о домене
Позволяет увидеть ключевые процессы и зависимости между ними

➡️ пример: визуализация полной цепочки "Заказ → оплата → доставка → возврат"

✳️ Process Level
Детализирует конкретный бизнес-процесс
Помогает определить события, команды и участников внутри него

➡️ разбор процесса "возврат товара" — от запроса покупателя до перевода средств

✳️ Design Level
Уточняет модель до уровня архитектуры и bounded contexts
Используется при проектировании микросервисов и взаимодействий между ними

➡️ разбиение домена e-commerce на контексты — заказы, платежи, доставка, уведомления


Ключевые «строительные блоки»

🔵 Domain Event (событие предметной области): главный элемент
Факт, который уже произошел в системе.
➡️ заказ размещён, платёж подтверждён, товар отправлен клиенту

🔵 Command (команда): действие, которое инициирует выполнение операции и приводит к событию
Часто является реакцией на предыдущее событие
➡️ разместить заказ, подтвердить платёж, отправить товар

🔵 Actor (Актор): пользователь или внешняя система, которая вызывает команду
➡️ покупатель, платёжный шлюз

🔵 Aggregate (агрегат): понятие из DDD
Это "кластер" из связанных сущностей (например, заказ с его позициями), который обрабатывает команды и порождает события

🔵 Policy (политика / бизнес-правило): автоматическая реакция на событие
Формулируется как "Когда событие X, тогда команда Y"

➡️ когда "Платёж подтверждён", тогда "Отправить товар"

🔵 Read Model (модель чтения): данные, которые видит пользователь, чтобы принять решение и выполнить команду
➡️ Страница со списком товаров в корзине


Пример как проходит Event Storming

1. Определить границы процесса
➡️ от момента оформления заказа до его доставки

2. Зафиксировать доменные события в прошедшем времени
➡️ заказ создан, платёж подтверждён, уведомление отправлено

3. Добавить команды, которые инициируют события:
➡️ создать заказ, подтвердить платёж

4. Указать акторов
➡️ кто выполняет действие (пользователь, внешний сервис)

5. Добавить агрегаты и сущности
➡️ они изменяют состояние при выполнении команд

6. Зафиксировать политики и правила
➡️ после подтверждения платежа — отправить заказ

7. Сгруппировать события по смыслу
➡️ формируются bounded contexts — логические границы между частями системы

8. Проверяются связи, исключения, альтернативные сценарии

9. Результат: карта событий, отражающая процессы и зависимости


📎 Материалы
1. Event storming
2. Моделирование микросервисов с помощью Event storming
3. Event Storming: как построить модель вокруг событий
4. Введение в Event Modeling
5. 10 аналогов Miro от российских и иностранных разработчиков

📚 Книги
Предметно-ориентированное проектирование: паттерны, принципы и методы - Скотт Миллетт, Ник Тью

#управление_проектами

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Грокаем безопасность веб-приложений

✍️ Автор: Макдональд Малькольм
🗓 Год издания: 2025
🔤 Язык: русский
📚 Объём: 336 стр.


Практическое руководство по безопасности для веб-приложений.
◾️Раскрываются основные принципы защиты
◾️Подробно разбираются наиболее распространенные уязвимости веб-приложений — от браузера до сервера.

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

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


#безопасность