НИС Дизайн систем 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 минут`. После этого следует показывать данные из конфига. 
   - (подсказка по защите) ожидаю, что в тексте по защите домашнего задания вы покажете логи/скриншоты итд, которые реализуют все эти сценарии

- конфиги

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

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