НИС Дизайн систем 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 минут
• Система должна линейно масштабироваться к нагрузке

Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability.

Возможный вариант домашнего задания

X == 100 Y == 10k Z == 5 kb

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

Требования по Reliability

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

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

Возможный вариант домашнего задания

• • Критичными** источниками данных являются:
• данные об исполнителе

• • Некритичными** источниками данных являются:
• данные по зоне заказа

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

• конфиги

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

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