Використання вільно розповсюджуваного програмного забезпечення. Рівень відкритості програмного забезпечення, що використовується, має бути сумісним з ліцензією Apache 2.0
Незалежність рішення від пропрієтарних сервісів, в тому числі сервісів хостинг-провайдерів
Мають використовуватись технології, для яких час закінчення життєвого циклу на момент прийняття рішення про використання не визначено або складає більше одного року
Усі оточення мають працювати на базі контейнеризації (та оркестрації контейнерів)
Має бути уникнено використання компонент, втрата одного з інстансів яких призводить до суттєвої втрати даних або функціональності
Механізми синхронізації даних між екземплярами сховищ та механізми паралельної обробки інформації різними екземплярами сервісів мають гарантувати відсутність конфліктів при зберіганні та обробці даних
Наявність механізмів повторних спроб (та/або використання проміжних черг між окремими компонентами)
Фокус на використання асинхронної комунікації між компонентами
Можливість “гарячого” додавання інстансів будь-яких компонент
Покриття коду юніт-тестами має складати ≥85%
Покриття автоматизованими тестами має сукупно забезпечувати перевірку роботи всіх критичних бізнес-процесів
Має бути розроблений пакет максимально універсалізованих автотестів, які б давали можливість перевірити роботу клієнта (майданчика) з АРІ
Має бути виконано навантажувальне тестування, за результатами якого був би складений профайл конфігурації відповідно до очікуваної кількості одночасних та історичних артефактів в системі (кількість аукціонів, кількість учасників на аукціон, кількість процедур, кількість змін статусів, очікувані затримки під навантаженням, уповільнення відповідно до росту об’єму даних тощо)
Управління через конфігурацію (без потреби змінювати код та перевстановлювати сервіси) всіма змінними, що присутні в бізнес-логіці: набір періодів, тривалість періодів, набори даних процедури тощо
Зберігання усіх текстів, що відображаються в модулі аукціонів або на інших сторінках, у конфігураційних файлах
Можливість відновлення з бекапів бази в цілому, документів окремої процедури, окремих дій (репроцесинг черги/логів)
Наявність автоматизованої збірки контейнерів
Наявність автоматизованого деплойменту на різні оточення
Максимально глибоке розділення елементів, доступом до яких можна керувати для окремих клієнтів (майданчиків). Включаючи, та не обмежуючись доступом до закритих арі взагалі, доступом до окремих типів процедур окремо на читання, створення та подання пропозицій
Унеможливлення дій адміністратора, пов’язаних з бізнес-логікою (вичитка або зміна даних, втручання в роботу не інфраструктурних сервісів) без збереження детальних логів дій, що виконувались
Унеможливлення читання адміністратором ставок (лот + розмір ставки) до початку запланованих аукціонів
Керування доступом майданчика через мережеві обмеження (білий список ІР) та з використанням ключів доступу
Можливість швидкого внесення змін в доступи майданчиків
Доступ до компонент, що не передбачають зовнішньої комунікації (тобто всіх, окрім публічних АРІ та АРІ для майданчиків) має бути заборонений на рівні мережі та доречним механізмом авторизації
Доступ безпосередньо до елементів інфраструктури має здійснюватись через єдиний шлюз
АРІ, відкриті узовні, мають надавати ті і тільки ті можливості, що прямо передбачені узгодженою документацією
Повсемісно має використовуватись безпечне (шифроване) з’єднання
Управління доступом до елементів ЕТС на основі рольової моделі
Логування всіх дій по зміні станів та проміжних станів даних по кожній процедурі
Лог дій майданчиків з бізнес-даними (керування процедурами та ставками) та на технічному рівні (лог викликів арі)
Логування дій користувачів модуля аукціону. За можливості повна інформація про помилку фронтенду, що отримав користувач, має потрапляти в технічний лог модуля аукціону
Можливість відслідкувати усі пов’язані дії для однієї логічної транзакції, що виконувались різними сервісами (trackID)
Технічний лог поведінки оркестратора, контейнерів, операційних систем, інфраструктурних сервісів тощо в об’ємі достатньому для продуктивного супроводження системи
Наявність автоматичної ротації технічних логів.
Усі елементи, що мають фронтенд, мають коректно відображатись в актуальних версіях популярних десктопних та мобільних браузерів (Chrome, Firefox, Safari, Edge, IE)
В інтерфейсах має бути використаний дизайн, що автоматично адаптується під розміри екрану та тип пристрою користувача
Усі помилки, що бачить користувач, мають відповідати фактичній ситуації, що виникла, і надавати користувачу інформацію щодо необхідних дій по уникненню помилки
Передача готового рішення у вигляді
Репозиторію з кодом
Автоматизованих сценаріїв збірки та деплойменту, що дозволяють конфігурування
Автотестів для центральних компонент
Автотестів для майданчиків
Результатів навантажувального тестування
Документації (архітектура, структура даних, інструкції відновлення, інструкції підтримки, арі-документація)
Розгорнутих середовищ стейджингу, сендбоксу та продуктиву