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

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

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

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

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

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

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

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

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

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

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

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

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


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