Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

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


✅ Когда лучше применять

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

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

Kanban
💩в проектах, где необходимо строго соблюдать сроки
💩в кросс-функциональных командах
💩когда требуется постоянная обратная связь от клиентов

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Больше подборок в закрытом канале

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

Что входит в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес, экономия 20%)

Оформить подписку можно через кнопки ниже.

OAuth 2.0 и OpenID Connect

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

👤 OpenID Connect — протокол аутентификации, который позволяет безопасно узнать сведения о пользователе, от имени которого совершается вход. OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO).

В чём отличие между OAuth 2.0 и OpenID Connect

Вся разница сводится к различию процессов аутентификации и авторизации.

Простыми словами:

💩Аутентификация — это когда мы проверяем, кто именно запрашивает доступ и является ли он тем, кем он себя представляет.

💩Авторизация — это когда мы проверяем, имеет ли конкретный клиент доступ к запрашиваемой информации.

OAuth 2.0 используется для авторизации, а OpenID Connect для аутентификации. А ещё OpenID Connect делает возможным использование SSO.

Токены

Оба протокола используют токены. Токен — это строка, которая содержит зашифрованную или подписанную информацию.

💩id_token — содержит информацию о клиенте, он выдается провайдером идентификации (IdP) в ответ на успешную аутентификацию пользователя. Может содержать, например, id пользователя, фамилию, имя, телефон и т.д.
💩access_token — это токен доступа, который используется для совершения действий от имени пользователя. Может быть ограничен скоупом — перечислением прав, которые может делать приложение с этим токеном от имени клиента. access_token имеет короткий срок жизни в целях безопасности.
💩refresh_token — это токен, который используется для получения нового access_token, когда старый истекает или отзывается. Имеет более длительный срок.

Все эти токены можно генерировать по-разному, но самый популярный формат — это JSON Web Token (JWT).

Структура JWT
💫Заголовок (header) — состоит из типа токена и алгоритма хэширования подписи
💫Полезная нагрузка (payload) — любые данные, которые вы хотите передать в токене. Payload не шифруется при использовании токена, поэтому не стоит передавать в нем чувствительные данные. Например, паспортные данные.
💫Подпись (signature) — заголовок и нагрузка формируются отдельно в формате JSON, кодируются в base64, а затем на их основе вычисляется подпись, которая также становится частью токена.

🔀 Процесс на примере использования VK API

1. Приложение генерирует параметры запроса и отправляет пользователя на сервер авторизации oauth.vk.com, добавив к ссылке параметры, включая запрашиваемый scope, например, friends
2. Пользователю открывается окно, где он проходит аутентификацию — вводит логин и пароль
3. После входа открывается окно с запросом прав доступа. Пользователь нажимает на кнопку "Разрешить". Тем самым он авторизует приложение на выполнение действий от его имени с запрашиваемым scope.
4. Сервер авторизации генерирует access_token и refresh_token и возвращает их приложению
5. Теперь приложение может управлять списком друзей пользователя

⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Версионирование REST API

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

⚙️ Как это работает

1️⃣ Под номером версии фиксируется существующий контракт API, который используется потребителями

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

3️⃣ Изменения публикуются в новой версии метода API, при этом старая версия остаётся рабочей до тех пор, пока у неё есть потребители

4️⃣ Потребители сами решают, в какой момент они будут готовы перейти на новую версию того или иного метода


✍️ Пример

Допустим, есть метод который позволяет опубликовать статью в блоге: POST /v1/articles
Метод принимает на вход в теле запроса следующие параметры, которые являются обязательными:

{
  "text": "string",
  "author": "string",
  "noscript": "string"
}

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

Поэтому создаём новую версию метода POST /v2/articles и все изменения реализуем там:

{
  "text": "string",
  "author": "string",
  "noscript": "string",
  "category": "string"
}

При этом старая версия метода (POST /v1/articles) продолжает работать.


Способы версионирования API

💫 Префикс URI
Пример: GET /v1/users
✔️ Способ простой в проектировании, реализации и документировании
✖️ Создает большое количество дубликатов URL и может снизить производительность приложения

💫 Параметр запроса
Пример: GET /users?version=v1
✔️ Способ рекомендуется, если важно HTTP-кеширование для повышения пропускной способности
✖️ Приводит к загрязнению URI, так как префиксы и суффиксы добавляются к основным строкам URI

💫 HTTP заголовок запроса
Пример: GET /users, а версию передаём в headers: version=v1
✔️ Не приводит к загрязнению URI, легко реализовать
✖️ Приводит к неправильному использованию заголовков, т.к они нужны для метаинформации

💫 Feature-версионирование
У клиента API есть набор фич. При отправке запроса, сервер проверяет его набор фич и на этой основе сам определяет нужную версию для каждого клиента
✔️ Можно использовать в качестве внутреннего API
✖️ Со временем фичи могут вступить в конфликт, если отвечают за одну и ту же часть бизнес-логики


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#api

TOGAF. Краткий обзор

TOGAF (The Open Group Architecture Framework) — архитектурный фреймворк, который используется для проектирования, реализации и управления архитектурой предприятия.

Главное, что нужно знать о TOGAF
➖самый распространённый фреймворк для корпоративной архитектуры
➖предлагает метод разработки архитектуры — Architecture Development Method (ADM)
➖имеет возможность расширения и адаптации исходной метамодели
➖включает набор рекомендаций, шаблонов и практик для проектирования АП
➖способствует эффективному управлению изменениями и реализации стратегии корпоративной архитектуры

TOGAF разделяет архитектуру предприятия на 4 домена (слоя):

💫бизнес-архитектура (Business Architecture): определяет стратегию бизнеса, управление, организацию и ключевые бизнес-процессы.
💫архитектура данных (Data Architecture): структура информационных ресурсов, включая логическую и физическую организацию данных, а также средства управления информацией
💫архитектура приложений (Application Architecture): описывает приложения, которые нужны для работы с данными и бизнес-функциями, структуру и свойства приложений, их взаимодействие между собой и с другими элементами архитектуры, соответствие целям и требованиям бизнеса.
💫технологическая архитектура (Technical Architecture): описывает аппаратную часть (железо), сети, промежуточное ПО

Структура стандарта TOGAF 10

Ссылки на каждую из частей фреймворка:
1. Fundamental Content
2. Series guides
3. TOGAF Library

1️⃣ Фундаментальный контент (Fundamental Content). Включает

*️⃣ Метод разработки архитектуры (Architecture Development Method (ADM) — центральный компонент TOGAF, который описывает последовательность фаз и шагов для разработки архитектуры предприятия. Каждая фаза содержит подробные руководства, входы, выходы, задачи и артефакты. ADM также поддерживает управление требованиями, архитектурными принципами, рисками, проблемами и изменениями, а также обеспечивает итеративный, циклический и непрерывный характер процесса разработки архитектуры.

*️⃣ Рекомендации к ADM (ADM Guidelines and Techniques)

*️⃣ Применения ADM (Applying the ADM)
Например, использование ADM в различных архитектурных стилях (например, Agile), применение итераций в ADM

*️⃣ Содержания архитектуры (Architecture Content)
Фреймворк , предоставляющий структурную модель для объектов-результатов, создаваемых архитекторами.
Позволяет их последовательно определять, структурировать и представлять.

*️⃣ Возможностей и управления АП (Enterprise Architecture Capability and Governance)
Руководство для создания оргструктур, процессов, ролей, обязанностей, навыков и т.д. Может реализовываться с помощью ADM.


2️⃣ Руководства серий (доменов) (Series guides).
Предлагают лучшие практики для применения корпоративной архитектуры


3️⃣ Библиотека (The Open Group Library) — дополнение к TOGAF. Содержит:
— справочные модели
— методические рекомендации
— общую практическую информацию
— руководство по созданию команды архитектуры предприятия


⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

🔉🗣Ищем соавтора в наш канал

В канал Системный аналитик (в том числе для VIP-канала) ищем автора. Нужно будет писать посты с подборками полезных материалов в стиле канала.

Про условия
💩Оплата за каждый пост отдельно (от 2500 ₽ за пост)
💩Темы постов можно предлагать свои или брать из бэклога
💩Минимум 1 пост в неделю
💩Можно писать больше одного поста в неделю, всё оплатим
💩График гибкий: можно написать за одну неделю 4 поста и потом ничего не делать 3 недели

Как стать автором
Заполнить анкету и выполнить тестовое задание по ссылке.

❗️ Дедлайн приёма анкет
Анкеты принимаем до 9 марта (суббота), 23:59 по МСК.

🍩 Плюшки участникам
Все, кто выполнит тестовое задание, получат доступ к VIP-каналу бесплатно и навсегда.

Остались вопросы? Пишите в комментарии 🔽

UPD: дедлайн продлили по многочисленным просьбам

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

Идемпотентная операция — это операция, которая при многократном вызове не меняет состояние ресурса. То есть, если мы повторно вызываем идемпотентный метод API, то не возникнет ошибок, связанных с дублированием одной и той же операции (например, двойных списаний баланса за один и тот же заказ).

По-хорошему, любой API должен быть идемпотентным.


Идемпотентность в REST API

HTTP-методы GET, PUT, DELETE формально считаются идемпотентными, тогда как POST и PATCH нет. Это не означает, что нельзя сделать GET неидемпотентным, а POST идемпотентным.

❗️ Важно: ответ идемпотентного метода может меняться. Например, при повторном вызове идемпотентного API создания заказа — заказ не будет создаваться ещё раз, но API может ответить как 200, так и 400. При обоих кодах ответа API будет идемпотентно с точки зрения состояния сервера (заказ один, с ним ничего не происходит), а с точки зрения клиента поведение существенно разное.


❗️ Проблемы неидемпотентных API

Проблема №1. Дублирование операций.
При сетевых задержках или ошибках одна и та же операция может быть выполнена несколько раз.

Пример с заказом такси:
1️⃣Пользователь вызывает такси в приложении
2️⃣Приложение отправляет запрос на создание заказа на сервер
3️⃣Возникает сбой, и приложение не получает успешный ответ по таймауту
4️⃣Приложение показывает сообщение «произошла ошибка» и делает кнопку заказа снова активной
5️⃣Пользователь снова нажимает кнопку
6️⃣К пользователю может приехать два такси вместо одного

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

Пример с заказом такси:
1️⃣Пользователь изменяет пункт назначения в активном заказе такси через приложение.
2️⃣Приложение отправляет запрос PATCH /v1/orders/{id} на сервер для обновления заказа
3️⃣Возникает сбой, и приложение не получает подтверждение об успешном обновлении
4️⃣Приложение показывает пользователю сообщение об ошибке и предлагает повторить попытку
5️⃣Пользователь решает изменить пункт назначения на новый и снова отправляет запрос
6️⃣Сервер обрабатывает оба запроса: сначала второй, затем первый. В системе возникает неконсистентность: водитель видит один пункт назначения, а пользователь ожидает, что будет доставлен в другое место.


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

Способы обеспечения идемпотентности методов создания (POST) и частичного изменения (PATCH):
1. Ключ идемпотентности в заголовке запросов
2. Версионирование состояния
3. Блокировка на основе правил

🗝 Ключ идемпотентности

Это уникальный идентификатор операции, который помогает защититься от повторного исполнения операции.

Как это работает:
1. Клиент генерирует уникальный ключ идемпотентности и отправляет его в заголовке запроса. Например, Idempotency-Key: <UUID>
2. Сервер проверяет, был ли уже обработан запрос с таким ключом. Если да, возвращает результат предыдущего запроса, не выполняя операцию повторно. Иначе просто выполняет операцию.


⬇️ Продолжение ниже⬇️

⬆️Начало выше⬆️

✅ Версионирование состояния

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

Как это работает на примере сервиса заказа такси:

Вводные
💩Каждый раз, когда в системе происходит изменение (создание, отмена, редактирование заказа), сервер увеличивает версию списка заказов. Эта версия отражает все изменения, произошедшие с заказами пользователя.
💩Перед созданием нового заказа приложение запрашивает у сервера текущую версию списка заказов через GET /v1/orders.

Процесс
1️⃣При создании заказа приложение включает в запрос заголовок If-Match с версией, которую оно знает.
2️⃣Сервер проверяет, соответствует ли версия в запросе текущему состоянию списка заказов. Если версия не совпадает, сервер отклоняет запрос, предотвращая создание дубликата.
3️⃣Если состояние заказов изменилось (например, заказ был отменен), сервер сообщает об этом приложению, отправляя ошибку с предложением перезагрузить информацию о заказах через GET /v1/orders.


❌Идемпотентность удаления

HTTP-метод удаления DELETE по своей природе идемпотентный, так как повторное удаление уже удаленного ресурса не изменяет состояние системы. После первого успешного все последующие запросы на удаление будут возвращать ошибку 404 (или другой код согласно логике сервера).

Более гибкий способ обеспечить идемпотентность удаления – использовать подход “Soft Delete”. Вместо физического удаления записи из базы данных, запись просто помечается как удаленная с помощью специального флага.

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

📎 Статьи

1. Стажёр Вася и его истории об идемпотентности API — очень рекомендуем
2. Кратко об идемпотентности от Yandex Cloud
3. Идемпотентность: больше, чем кажется
4. Идемпотентность при использовании API Mindbox

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


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

Способы обеспечения работы высоконагруженных систем


1️⃣ Инфраструктура

💩Вертикальное масштабирование — увеличение производительности серверов (увеличение RAM, добавление дисков, более мощных СPU и т.д.). Самый простой способ, однако он довольно быстро упирается в потолок
💩Горизонтальное масштабирование — добавление дополнительных серверов (или виртуальных копий сервиса — реплик) для распределения нагрузки между ними. Это работает примерно так же, как в реальной жизни: если один рабочий выкопает яму за 4 часа, то двое рабочих сделают это быстрее (но не факт, что в 2 раза)
💩Балансировка нагрузки — актуально при горизонтальном масштабировании, когда используется несколько серверов или реплик приложения. Балансировка помогает распределить загрузку между сервисами равномерно


2️⃣ Хранение и доступ к данным

💩Кэширование — сохранение часто запрашиваемых данных в памяти для быстрого доступа. Подробнее см. в этом посте
💩Индексы — дополнительная структура данных в реляционных БД для ускорения поиска и обработки записей. Это подобно алфавитному указателю в англо-русском словарике: не нужно листать весь словарь, достаточно лишь открыть страницы с нужным сочетанием букв. Подробнее в этом посте
💩Денормализация — введение избыточности в таблицах и представлениях, чтобы сократить число запросов к БД и тем самым минимизировать время обработки запросов. Вместо того, чтобы делать кучу джойнов с группировками и вычисляемыми полями, можно завести представление (вью), которая будет содержать все нужные данные, хотя она не будет соблюдать 3 нормальных формы
💩Репликация — копирование одних и тех же данных между разными серверами. При использовании такого метода выделяют два типа серверов: master и slave. Мастер используется для записи или изменения информации, слейвы — для копирования информации с мастера и её чтения. Эффект достигается за счёт повышения отзазоустойчивости и разделения операций чтения и записи
💩Партиционирование — разделение таблиц на несколько частей в рамках одного сервера. Позволяет увеличить производительность за счёт уменьшения объема данных, которые нужно обрабатывать при выполнении запросов. Подробнее в этом посте
💩Шардирование — техника масштабирования БД, когда данные разносятся по нескольким машинам. Разделение данных эффективно, когда для разных запросов требуются разные данные некогда единой таблицы. Подробнее в этом посте


3️⃣ Приложения

Проектирование архитектуры приложений
💩DDD (Domain-Driven Design) — подход к проектированию архитектуры, при котором приложение разделяется на функциональные домены на основе того, как работает реальный бизнес. DDD помогает создавать более устойчивые и масштабируемые системы. Подробнее в этом посте
💩CQRS (Command Query Responsibility Segregation) — подход, при котором система разделяется на две части: одна отвечает за обработку команд (изменения состояния), а другая — за запросы (чтение данных). Команды и запросы могут быть масштабированы независимо, что позволяет системе более эффективно обрабатывать большое количество RPC. Подробнее в этом посте
💩CDC (Change Data Capture) — техника, используемая для определения и отслеживания изменений в данных. Очень полезно, когда нужно в режиме реального времени реагировать на изменения в базе-источнике. Подробнее

Интеграции
💩Брокеры сообщений — помогают обрабатывать тысячи запросов с гарантией доставки сообщений. Подробнее тут.
💩Использование gRPC — более производительный стиль интеграции, который под капотом использует HTTP/2 для транспорта и Protocol Buffers для сериализации данных. В этом посте подробнее.
💩Веб-сокеты — вместо множества запросов для обновления данных, веб-сокеты позволяют поддерживать постоянное соединение, через которое данные могут передаваться в обе стороны в реальном времени. Подробнее здесь.

Оптимизация кода
💩Распараллеливание запросов
💩Минимизация сериализации данных
💩Оптимизация запросов к БД
💩Управление HTTP-сессиями и использование возможностей TCP

⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Масштабирование БД. Партиционирование, шардирование и репликация

⚡️Максимально кратко
💩Партиционирование — разделение БД на части в рамках одного сервера. Может быть вертикальным (по столбцам) и горизонтальным (по строкам)
💩Шардирование — разделение БД на части по разным серверам. Может быть только горизонтальным (по строкам)
💩Репликация — копирование одних и тех же данных между разными серверами


💩Партиционирование

Партиционирование — разделение большой таблицы на несколько частей. Все части хранятся на одном сервере. Бывает горизонтальным и вертикальным.

1⃣ Горизонтальное партиционирование: данные разбиваются на несколько отдельных таблиц по строкам. Каждая такая таблица содержит содержит одинаковые столбцы, но разные строки данных.
Преимущества:
➕уменьшение объема данных, которые нужно обрабатывать при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный диапазон строк
➕возможность распараллеливания запросов между подтаблицами
Пример: разделение таблицы заказов по дате заказа, так что каждая подтаблица содержит заказы за определенный месяц или год.

2⃣ Вертикальное партиционирование: данные разбиваются на несколько отдельных таблиц по столбцам. Каждая такая таблица содержит часть столбцов и все связанные с ними строки данных.
Преимущества:
➕уменьшение объема данных, которые нужно загружать в память при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный набор столбцов
➕возможность оптимизации хранения данных в зависимости от типа и частоты использования столбцов.
Пример: разделение таблицы пользователей на две подтаблицы, одна из которых содержит основную информацию о пользователях, а другая — доп. информацию


💩Шардирование — техника масштабирования БД, когда данные разносятся по нескольким машинам. Бывает только горизонтальным (по строкам). Шардирование позволяет распределить нагрузку на запись и чтение данных между различными серверами, за каждый из которых отвечает отдельная машина

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

Методы шардирования

1. Хешированное — данные разбиваются на шарды на основе хеш-функции, которая принимает входные данные и возвращает хеш-значение. Это значение определяет, в какой шард будет помещена каждая запись данных. Метод позволяет достичь высокой производительности и отсутствия единой точки отказа, однако усложняет поиск данных

2. Диапазонное — данные разбиваются на шарды на основе диапазона значений. Значения могут присваиваться с помощью ключей и других атрибутов. Метод прост в реализации и позволяет быстрее находить информацию, чем при хешировании, однако может привести к несбалансированности базы

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

4. Динамическое — позволяет автоматически масштабировать хранилище в зависимости от текущей производительности и объема данных. Нужна система мониторинга и балансировки нагрузки


💩Репликация
Репликация — копирование данных между несколькими серверами. При использовании такого метода выделяют два типа серверов: master и slave. Мастер используется для записи или изменения информации, слейвы — для копирования информации с мастера и её чтения. Чаще используется один мастер и несколько слейвов, т. к. обычно запросов на чтение больше, чем запросов на изменение
Преимущество: большое количество копий данных. Если мастер выходит из строя, любой другой сервер сможет его заменить
Недостатки: рассинхронизация и задержки при передаче данных. Репликация используется как средство обеспечения отказоустойчивости вместе с другими методами

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#бд