Загальна схема архітектури засобу інформатизації для системи АТ "Прозорро.Продажі"
1. Загальний опис архітектури
Система АТ "Прозорро.Продажі" є розподіленою інформаційною системою, яка забезпечує проведення електронних аукціонів у форматі відкритих торгів. Архітектура побудована за принципом мікросервісного підходу, що дозволяє забезпечити гнучкість, масштабованість і високу доступність.
Всі компоненти розгорнуті в хмарному середовищі (AWS, GCP або Azure).
Взаємодія між компонентами здійснюється через REST API та GraphQL.
Забезпечується авторизація та аутентифікація через OAuth 2.0.
Всі аукціонні процеси логуються для контролю прозорості та аналітики.
2. Логічна архітектура
Система складається з декількох рівнів:
| Рівень | Компоненти | Опис |
|---|---|---|
| Користувацький рівень | Веб-платформа (React.js), мобільний застосунок (Flutter) | Інтерфейс для користувачів аукціону (учасники, адміністратори, майданчики) |
| Шлюз API | GraphQL API Gateway | Єдина точка входу для клієнтів та зовнішніх систем |
| Мікросервіси | - Сервіс управління аукціонами - Сервіс обробки ставок - Аналітичний модуль - Модуль сповіщень | Кожен сервіс відповідає за окремий функціонал |
| База даних | PostgreSQL, Redis (кешування) | Зберігання всіх даних аукціонів, користувачів, ставок |
| Зовнішні інтеграції | Державні реєстри, банківські системи, платіжні шлюзи | Інтеграція для перевірки учасників, платежів, майнових даних |
3. Фізична архітектура
Система розгорнута у хмарному середовищі та використовує наступні технології:
Контейнери (Docker, Kubernetes) – для розгортання та управління сервісами.
Балансувальник навантаження (NGINX, AWS ALB) – рівномірний розподіл запитів.
Системи логування та моніторингу (Elasticsearch, Kibana, Prometheus, Grafana) – для відстеження роботи системи.
Автоматичне масштабування (Kubernetes HPA) – підвищення продуктивності під час пікових навантажень.
📌 Приклад потоку запиту:
Користувач заходить на сайт prozorro.sale.
Запит надходить до API Gateway, який перенаправляє його до відповідного сервісу.
Якщо це запит на перегляд аукціонів, викликається аналітичний модуль.
Якщо це участь в аукціоні, запит проходить через сервіс обробки ставок.
Дані кешуються у Redis для швидкого доступу.
4. Взаємодія компонентів
Всі сервіси обмінюються даними через захищений API (REST, GraphQL).
Використовується шифрування трафіку через TLS 1.3.
Для взаємодії з банками та держреєстрами використовується ESB-шина (Apache Kafka, RabbitMQ).
📌 Приклад взаємодії:
Користувач подає заявку на участь в аукціоні.
Дані перевіряються через інтеграцію з держреєстрами.
Якщо все гаразд – користувач отримує доступ до аукціону.
Всі події логуються в централізовану систему моніторингу.
5. Вимоги до продуктивності та масштабованості
Час обробки запиту – не більше 500 мс.
Кількість одночасних користувачів – до 100 000.
Горизонтальне масштабування дозволяє автоматично додавати нові сервери.
Приклад
✅ Архітектура мікросервісна, гнучка та масштабована.
✅ Всі сервіси працюють у хмарному середовищі з балансуванням навантаження.
✅ Інтеграція з держреєстрами та платіжними системами через API.
✅ Прозорість забезпечується логуванням та моніторингом всіх дій у системі.