Просмотр исходного текста страницы НИС Дизайн систем II 4 курс 2024/2025 homework

== FR ==
Описаны в лекции.

* кратко -- реализовать 3 http/grpc/... handler (обработчика, "ручки")
* берите тот протокол, что лучше знаете -- смысл не в протоколе)
* нужно предусмотреть получение данных от источников данных
* должны быть тесты, (какая-то) БД для хранения итд
* подсмотреть самую простую реализацию (чтоб не придумывать) можно в репозитории

=== Источники данных ===
* Данные о заказе
* Данные о зоне заказа
* Данные об исполнителе
* Данные о конфигурационных настройках (см feature flags / feature toggles)
* Данные о платных дорогах (пока не описано)

== NFR ==
Тут подсмотреть негде :-) Но можно обсуждать в чате, в ЛС, ну или в вашей команде.

=== Требования по Maintainability ===
Система должна быть спроектирована с учетом высокой вероятности изменений как в количестве источников данных (могут появляться дополнительные),
так и в непосредственной логике формирования заказа (для простоты дано буквально 3 варианта бизнес-логики, но в реальности там тысячи строк кода).
Также, необходимо предусмотреть возможность выполнения дополнительных действий или после назначения заказа, или после его отмены.

=== Требования по Scalability ===
==== Оригинальная формулировка (общая для всех) ====
* Рассчитываем систему на X одновременно назначаемых заказов -- внешняя нагрузка. X измеряется в RPS
* Рассчитываем систему на Y исполнителей -- кол-во пользователей системы. Y измеряется в штуках
    * Каждый исполнитель раз в 1 минуту спрашивает про свой заказа
* Каждый заказ занимает Z кб
* Отмена каждого заказа происходит в среднем за 10 минут -- старый вариант
  * '''Обновление'''
  * Каждую секунду отменяется '''W''' (процент от рейта заказов) заказов
  * Если за секунду создается 100 заказов, то в эту же секунду отменяется 50 из них (ну вот такая неэффективная система назначения получается).
  * Отмененные заказы нельзя показывать исполнителю.
* Система должна линейно масштабироваться к нагрузке
Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability.

==== Возможный вариант домашнего задания ====
X == 100
Y == 10k
Z == 5 kb

Могут быть дополнительные требования по Scalability

=== Требования по Reliability ===
Разрабатываемая система зависит от 5 источников данных.
С теоретической точки зрения источники данных могут быть либо критичными, либо некритичными.
В этой задаче источник данных с заказами является критичным.
То есть никакие стратегии увеличения надежности для него реализовывать не нужно.

Все остальные источники данных будут разделены на 2 части примерно так:

==== Возможный вариант домашнего задания ====
**Критичными** источниками данных являются:
* данные об исполнителе

**Некритичными** источниками данных являются:
* данные по зоне заказа
    * Нам подойдет неактуальность данных их этого источника в течение `10 минут`. После этого следует показывать данные из конфига. 
    * (подсказка по защите) ожидаю, что в тексте по защите домашнего задания вы покажете логи/скриншоты итд, которые реализуют все эти сценарии
* конфиги
    * сервис должен на старте получать актуальные конфиги и не использовать походы в них при обработке запросов
    * при недоступности источника конфигов при старте сервис не должен запускаться
    * сервис может бесконечно долго использовать старые данные


*Должна быть предусмотрена идемпотентность выполняемых операций (может потребовать хранения дополнительных данных)


== Как сдавать домашнее задание ==
Из семинара:

* Нужно описать дизайн системы, отвечающей требованиям
  * Должен получиться ADR определенной/фиксированной структуры 
* Нужно реализовать систему, отвечающую требованиям 
  * Должен получиться сервис / несколько сервисов + БД для хранения
  * Детали реализации остаются на ваше усмотрение
* Нужно показать/продемонстрировать выполнение ключевых FR / NFR
  * Должен получиться текстовый отчет произвольной структуры 

=== Что должно входить в ADR (Architecture Design Record) ===
Для вдохновения можно почитать:
- https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman
- https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-of-the-madr-project

==== Расчет нагрузки ====
Должен входить расчет нагрузки, с пересчетом RPS на каждый endpoint/ручку
Должен входить расчет по читающим/пишущим запросам в БД (прям вот буквально -- ожидается 100 RPS на запись, 300 RPS на чтение)
Точно должен входить расчет хранения на БД -- нужно хранить ХХХ Гб

==== Схема системы ====
- Должны быть показаны пользователи системы (внешние потребители, внешние системы итд)
- Должны быть показаны микросервис/микросервисы
- Должны быть показаны БД
- Могут быть показаны L7-балансировщики
- Должны быть показаны схемы выполнения запросов, в случае нескольких микросервисов

==== Основные сущности ====
- Должны быть представлены сущности, которые будут храниться в БД. С описанием полей

=== Что должно входить в детали реализации ===
- Исходный код реализованных микросервисов (>=1 штуки)
- Схема выбранной БД на SQL/любом другом диалекте
- Обратите внимание на следование принципам SOLID, выполнение всех требований по надежности и других требований вашего варианта ДЗ

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

==== Например -- требование про "executer -- реализовать поход на фоллбэк-источник данных (service substitution)" ====
Вы должны показать корректную работу сервиса (через логи, графики итд) при работающем сервисе "executer"
Вы должны показать корректную работу сервиса (через логи, графики итд) при _неработающем_ сервисе "executer" -- должны быть запросы к другому источнику данных. Сервис должен продолжать корректно отвечать на запросы при этом и выдавать понятные сообщения в логи.

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