Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9664
Full metadata record
DC FieldValueLanguage
dc.contributor.advisorГолуб, Сергій Васильович-
dc.contributor.authorЛога, Євгеній Вікторович-
dc.date.accessioned2026-06-17T20:01:32Z-
dc.date.available2026-06-17T20:01:32Z-
dc.date.issued2026-06-17-
dc.identifier.urihttps://er.chdtu.edu.ua/handle/ChSTU/9664-
dc.description.abstractАНОТАЦІЯ Виконавець: Лога Євгеній Вікторович. Назва кваліфікаційної роботи: «Високонавантажена програмна платформа електронної комерції на основі мікросервісів». Спеціальність: 121 «Інженерія програмного забезпечення». Установа: Черкаський державний технологічний університет (ЧДТУ). Місто, рік: Черкаси, 2026 рік. Об'єкт розробки: процес проектування та функціонування високонавантажених інформаційних систем у сфері електронної комерції. Предмет розробки: архітектура, програмні модулі та методи асинхронної взаємодії розподіленої мікросервісної платформи електронної комерції під високим навантаженням. Основні ідеї, результати та висновки кваліфікаційної роботи бакалавра: Основні ідеї: ‒ проектування високонавантаженої платформи електронної комерції з повною відмовою від монолітної структури на користь мікросервісного підходу; ‒ усунення часової пов'язаності компонентів шляхом впровадження системи асинхронного обміну повідомленнями через брокер RabbitMQ (Fire-and-Forget); ‒ забезпечення строгої транзакційної узгодженості розподілених даних за допомогою патерну оркестрації SAGA та механізмів компенсуючих транзакцій; ‒ використання однопотокової неблокуючої моделі Node.js у поєднанні з фреймворком NestJS для забезпечення екстремально високої пропускної здатності. Результати: ‒ розроблено повнофункціональний програмний комплекс із восьми ізольованих мікросервісів та центрального API-шлюзу; ‒ реалізовано алгоритм надійної обробки замовлень із автоматичним резервуванням складських залишків без блокування суміжних баз даних; ‒ інтегровано архітектурний шаблон Database per Service (PostgreSQL) та швидкісне in-memory сховище Redis для управління тимчасовим станом кошика; ‒ створено адаптивну адміністративну панель (React, Vite, TailwindCSS) для моніторингу працездатності системи та візуалізації статистики; ‒ здійснено повну контейнеризацію платформи засобами Docker із налаштуванням політик автоматичного відновлення та health-checks. Висновки: ‒ мікросервісна архітектура є найбільш раціональним і науково обґрунтованим рішенням для забезпечення безперебійної роботи e-commerce платформ під час пікових навантажень; ‒ синергія асинхронного середовища NestJS, брокера подій RabbitMQ та патерну розподілених транзакцій формує високонадійну відмовостійку інфраструктуру; ‒ розроблена система відзначається високим ступенем ізоляції, легко піддається горизонтальному масштабуванню та готова до експлуатації у контейнеризованих хмарних середовищах.uk_UA
dc.description.abstractANNOTATION Performer: Loha Yevhenii Viktorovych. Title of the qualified bachelor’s work: "High-Load Microservice-Based E-Commerce Software Platform". Specialty: 121 "Software Engineering". Institution: Cherkasy State Technological University (CSTU). City, year: Cherkasy, 2026. Object of development: the process of designing and functioning high-load information systems in the field of e-commerce. Subject of development: architecture, software modules, and asynchronous interaction methods of a distributed microservice e-commerce platform under high load. Main ideas, results, and conclusions of the bachelor's qualification work: Main ideas: ‒ designing a high-load e-commerce platform with a complete transition from a monolithic structure to a microservice approach; ‒ eliminating the temporal coupling of components by implementing an asynchronous messaging system through the RabbitMQ broker (Fire-and-Forget); ‒ ensuring strict transactional consistency of distributed data using the SAGA orchestration pattern and compensating transaction mechanisms; ‒ utilizing the single-threaded, non-blocking Node.js model combined with the NestJS framework to provide extremely high throughput. Results: ‒ a fully functional software suite consisting of eight isolated microservices and a central API Gateway was developed; ‒ a reliable order processing algorithm with automatic inventory reservation without blocking adjacent databases was implemented; ‒ the Database per Service architectural pattern (PostgreSQL) and high-speed in-memory Redis storage for managing the temporary state of the shopping cart were integrated; ‒ a responsive administrative dashboard (React, Vite, TailwindCSS) for monitoring system health and visualizing statistics was created; ‒ full containerization of the platform using Docker with configured automated restart policies and health checks was accomplished. Conclusions: ‒ the microservice architecture is the most rational and scientifically justified solution for ensuring the uninterrupted operation of e-commerce platforms during peak loads; ‒ the synergy of the asynchronous NestJS environment, RabbitMQ event broker, and distributed transaction pattern forms a highly reliable, fault-tolerant infrastructure; ‒ the developed system features a high degree of component isolation, is easily horizontally scalable, and is ready for deployment in containerized cloud environments.uk_UA
dc.language.isoukuk_UA
dc.subjectелектронна комерціяuk_UA
dc.subjectмікросервісна архітектураuk_UA
dc.subjectвисоконавантажена системаuk_UA
dc.subjectасинхронна взаємодіяuk_UA
dc.subjectрозподілені транзакціїuk_UA
dc.subjectпатерн SAGAuk_UA
dc.subjectброкер повідомлень RabbitMQuk_UA
dc.subjectNestJSuk_UA
dc.subjectконтейнеризаціяuk_UA
dc.subjectDockeruk_UA
dc.subjecte-commerceuk_UA
dc.subjectmicroservice architectureuk_UA
dc.subjecthigh-load systemuk_UA
dc.subjectasynchronous interactionuk_UA
dc.subjectdistributed transactionsuk_UA
dc.subjectSAGA patternuk_UA
dc.subjectRabbitMQ message brokeruk_UA
dc.subjectNestJSuk_UA
dc.subjectcontainerizationuk_UA
dc.subjectDockeruk_UA
dc.titleВисоконавантажена програмна платформа електронної комерції на основі мікросервісівuk_UA
dc.typeBachelor Thesisuk_UA
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:
File Description SizeFormat 
Кваліфікаційна робота бакалавра Лога Євген Вікторович_2026.pdf
  Restricted Access
9.93 MBAdobe PDFView/Open Request a copy


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text
ЧДТУ 262248.010 ПЗ 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи бакалавра
на тему: «Високонавантажена програмна платформа електронної комерції 
на основі мікросервісів» 
Виконав: студент 4 курсу, групи ПЗ-2204 
спеціальності 
121 «Інженерія програмного забезпечення» 
(шифр і назва напряму підготовки) 
Студент Лога Є. В. 
(прізвище та ініціали) 
Керівник  Голуб С.В. 
(прізвище та ініціали) 
Рецензент  Євтушенко О.Г. 
(прізвище та ініціали) 
Черкаси 2026
 
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем______________________________ 
Кафедра  програмного забезпечення автоматизованих систем________________ 
Освітній рівень бакалавр____________________________________________________ 
Спеціальність 121 «Інженерія програмного забезпечення»_______________________ 
Освітня програма Інженерія програмного забезпечення____________________________ 
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
____________________ С. Голуб  
«___» ______________ 2026 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Лога Євгеній Вікторович 
(прізвище, ім’я, по батькові) 
1. Тема роботи:  «Високонавантажена програмна платформа електронної комерції на 
основі мікросервісів» 
Керівник роботи д.т.н., професор Голуб Сергій Васильович 
Затверджені наказом Черкаського державного технологічного університету №56/03/03 
від «12» березня 2026 року 
2. Строк подання студентом роботи ________  
3. Вхідні дані до роботи: високонавантажена платформа електронної комерції на базі 
мікросервісної архітектури, система оркестрації розподілених транзакцій, асинхронна 
взаємодія компонентів через брокер повідомлень та контейнеризоване середовище 
розгортання. 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) 
Вступ 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ РОЗДІЛ 2. ПРОЕКТУВАННЯ МІКРОСЕРВІСНОЇ АРХІТЕКТУРИ ТА 
ПРОГРАМНИХ КОМПОНЕНТІВ СИСТЕМИ РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ 
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ВИСНОВКИ Список використaних джерел Додатки 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту): 
Додаток А – Документація______________________________________________ 
Додаток Б – Специфікація програми______________________________________ 
7 
 
Додаток В – Текст програми_____________________________________________ 
Додаток Г – Презентаційний матеріал_____________________________________ 
6. Консультанти розділів роботи 
7. Дата видачі завдання 02 грудня 2025 р. 
КАЛЕНДАРНИЙ ПЛАН 
№ Строк виконання етапів 
Назва етапів випускної роботи Примітки 
п/п кваліфікаційної роботи 
1 Постановка задачі 05.4.2026 виконано 
2 Підготовка завдання 13.4.2026 виконано 
3 Погодження завдання 16.4.2026 виконано 
4 Затвердження завдання 19.4.2026 виконано 
 Основна стадія   
1 Підбір матеріалів 27.4.2026 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.5.2026 виконано 
3 Розрахунок основних параметрів роботи 10.5.2026 виконано 
4 Вибір кінцевого варіанту проектного 17.5.2026 виконано 
рішення 
5 Оформлення первісної редакції роботи 21.05.2026 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 21.05.2026 виконано 
керівником 
2 Оформлення пояснювальної записки роботи 21.05.2026 виконано 
в кінцевій редакції 
3 Попередній захист роботи 21.05.2026 виконано 
4 Затвердження роботи 26.05.2026  
5 Рецензування роботи 26.05.2026  
6 Захист роботи 1.06.2026  
 
 
Студент _____________________      Лога Є.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник роботи _____________________      Голуб С.В. 
  (підпис)   (прізвище та ініціали)
  
  
 
 
АНОТАЦІЯ 
Виконавець: Лога Євгеній Вікторович. 
Назва кваліфікаційної роботи: «Високонавантажена програмна платформа 
електронної комерції на основі мікросервісів». 
Спеціальність: 121 «Інженерія програмного забезпечення». 
Установа: Черкаський державний технологічний університет (ЧДТУ). 
Місто, рік: Черкаси, 2026 рік. 
 Об'єкт розробки: процес проектування та функціонування 
високонавантажених інформаційних систем у сфері електронної комерції. 
 Предмет розробки: архітектура, програмні модулі та методи 
асинхронної взаємодії розподіленої мікросервісної платформи електронної 
комерції під високим навантаженням. 
 Основні ідеї, результати та висновки кваліфікаційної роботи 
бакалавра: 
 Основні ідеї: 
 ‒ проектування високонавантаженої платформи електронної 
комерції з повною відмовою від монолітної структури на користь 
мікросервісного підходу; 
 ‒ усунення часової пов'язаності компонентів шляхом 
впровадження системи асинхронного обміну повідомленнями через брокер 
RabbitMQ (Fire-and-Forget); 
 ‒ забезпечення строгої транзакційної узгодженості розподілених 
даних за допомогою патерну оркестрації SAGA та механізмів 
компенсуючих транзакцій; 
 ‒ використання однопотокової неблокуючої моделі Node.js у 
поєднанні з фреймворком NestJS для забезпечення екстремально високої 
пропускної здатності. 
 Результати:  
 ‒ розроблено повнофункціональний програмний комплекс із 
восьми ізольованих мікросервісів та центрального API-шлюзу; 
 
 
 ‒ реалізовано алгоритм надійної обробки замовлень із 
автоматичним резервуванням складських залишків без блокування 
суміжних баз даних; 
 ‒ інтегровано архітектурний шаблон Database per Service 
(PostgreSQL) та швидкісне in-memory сховище Redis для управління 
тимчасовим станом кошика; 
 ‒ створено адаптивну адміністративну панель (React, Vite, 
TailwindCSS) для моніторингу працездатності системи та візуалізації 
статистики; 
 ‒ здійснено повну контейнеризацію платформи засобами Docker із 
налаштуванням політик автоматичного відновлення та health-checks. 
 Висновки: 
 ‒ мікросервісна архітектура є найбільш раціональним і науково 
обґрунтованим рішенням для забезпечення безперебійної роботи e-
commerce платформ під час пікових навантажень; 
 ‒ синергія асинхронного середовища NestJS, брокера подій 
RabbitMQ та патерну розподілених транзакцій формує високонадійну 
відмовостійку інфраструктуру; 
 ‒ розроблена система відзначається високим ступенем ізоляції, 
легко піддається горизонтальному масштабуванню та готова до 
експлуатації у контейнеризованих хмарних середовищах. 
 Ключові слова: електронна комерція, мікросервісна архітектура, 
високонавантажена система, асинхронна взаємодія, розподілені транзакції, 
патерн SAGA, брокер повідомлень RabbitMQ, NestJS, контейнеризація, 
Docker. 
  
 
 
ANNOTATION 
Performer: Loha Yevhenii Viktorovych. 
Title of the qualified bachelor’s work: "High-Load Microservice-Based E-
Commerce Software Platform". 
Specialty: 121 "Software Engineering". 
Institution: Cherkasy State Technological University (CSTU). 
City, year: Cherkasy, 2026. 
 Object of development: the process of designing and functioning high-
load information systems in the field of e-commerce. 
Subject of development: architecture, software modules, and asynchronous 
interaction methods of a distributed microservice e-commerce platform under 
high load. 
 Main ideas, results, and conclusions of the bachelor's qualification 
work: 
 Main ideas: 
 ‒ designing a high-load e-commerce platform with a complete 
transition from a monolithic structure to a microservice approach; 
 ‒ eliminating the temporal coupling of components by implementing an 
asynchronous messaging system through the RabbitMQ broker (Fire-and-Forget); 
 ‒ ensuring strict transactional consistency of distributed data using the 
SAGA orchestration pattern and compensating transaction mechanisms; 
 ‒ utilizing the single-threaded, non-blocking Node.js model combined 
with the NestJS framework to provide extremely high throughput. 
Results: 
 ‒ a fully functional software suite consisting of eight isolated 
microservices and a central API Gateway was developed; 
 ‒ a reliable order processing algorithm with automatic inventory 
reservation without blocking adjacent databases was implemented; 
 
 
 ‒ the Database per Service architectural pattern (PostgreSQL) and high-
speed in-memory Redis storage for managing the temporary state of the shopping 
cart were integrated; 
 ‒ a responsive administrative dashboard (React, Vite, TailwindCSS) for 
monitoring system health and visualizing statistics was created; 
 ‒ full containerization of the platform using Docker with configured 
automated restart policies and health checks was accomplished. 
 Conclusions: 
 ‒ the microservice architecture is the most rational and scientifically 
justified solution for ensuring the uninterrupted operation of e-commerce 
platforms during peak loads; 
 ‒ the synergy of the asynchronous NestJS environment, RabbitMQ 
event broker, and distributed transaction pattern forms a highly reliable, fault-
tolerant infrastructure; 
 ‒ the developed system features a high degree of component isolation, 
is easily horizontally scalable, and is ready for deployment in containerized cloud 
environments. 
 Keywords: e-commerce, microservice architecture, high-load system, 
asynchronous interaction, distributed transactions, SAGA pattern, RabbitMQ 
message broker, NestJS, containerization, Docker.
 
 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................... 7 
ВСТУП ....................................................................................................................... 13 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................. 17 
1.1. Аналіз технічної інформації .......................................................................... 17 
1.2. Актуальність задачі ........................................................................................ 19 
1.3. Аналіз існуючих програмних засобів .......................................................... 20 
1.4. Аналіз способів вирішення задачі ................................................................ 22 
1.5. Постановка задачі ........................................................................................... 23 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................. 28 
2.1. Моделювання предметної області ................................................................ 28 
2.1.1. Предметна область моделювання. Модель предметної облaсті. 
Словник предметної облaсті ............................................................................ 29 
2.1.2. Елементи моделювaння предметної облaсті ........................................ 32 
2.1.3. Робочa облaсть моделювaння ................................................................ 34 
2.2. Формування та аналіз вимог ......................................................................... 36 
2.2.1. Формувaння вимог до прогрaмного зaбезпечення. Первинні і детaльні 
вимоги. Вимоги зaмовникa і розробникa. Функціонaльні тa нефункціонaльні 
вимоги ................................................................................................................. 36 
2.2.2. Формувaння вимог зa допомогою діaгрaми прецедентів .................... 39 
2.3. Проектувaння логічної структури прогрaмного комплексу ...................... 42
     
     ЧДТУ 26. 2248-010 ПЗ 
 .    
Змн. Арк. № докум. Підпис Дата 
Розроб. Лога Є.В.   Літ. Лист Листів 
Перевір Голуб С.В..   Високонавантажена програмна    4  
платформа електронної комерції на 
Н. Конт. Півень О.Б.   основі мікросервісів 
ФІТІС, кафедра ПЗАС, ПЗ-2204 
Затверд. Голуб С.В.   
 
 
2.3.1. Діaгрaми клaсів ........................................................................................ 42 
2.3.2. Діaгрaми пaкетів ...................................................................................... 44 
2.4. Архітектурне проектувaння .......................................................................... 48 
2.4.1. Діaгрaмa компонентів ............................................................................. 48 
2.4.2. Розгортaння прогрaмної системи нa aпaрaтних зaсобaх. Діaгрaмa 
розгортaння ........................................................................................................ 51 
2.5. Моделювaння поведінки системи................................................................. 54 
2.5.1. Діaгрaмa діяльності ................................................................................. 54 
2.5.2. Діaгрaмa послідовності ........................................................................... 57 
2.5.3. Діaгрaмa комунікaції ............................................................................... 58 
2.5.4 Діaгрaмa скінченного aвтомaту .............................................................. 60 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ .................................................................................................... 64 
3.1. Розробкa прогрaмного комплексу ................................................................ 64 
3.1.1. Обґрунтувaння вибору зaсобів реaлізaції ............................................. 64 
3.1.2. Опис структурної схеми системи .......................................................... 66 
3.1.3. Опис логічної схеми системи ................................................................. 67 
3.1.4. Розробка бaзи дaних ................................................................................ 70 
3.1.5. Розробкa інтерфейсу користувaчa ......................................................... 72 
3.1.6. Опис розробки прогрaмних компонентів ............................................. 74 
3.2. Тестувaння системи ....................................................................................... 76 
3.2.1. Модульне тестувaння .............................................................................. 77 
3.2.2 Інтегрaційне тестувaння .......................................................................... 79 
3.2.3 Системне тестувaння ............................................................................... 82 
3.2.4 Приймaльне тестувaння ........................................................................... 85 
3.3 Приклaди впровaдженого прогрaмного комплексу ..................................... 88 
ВИСНОВКИ ............................................................................................................. 92 
СПИСОК ВИКОРИСТAНИХ ДЖЕРЕЛ ............................................................ 94 
     
     ЧДТУ 26. 2248-010 ПЗ 
Змн. Арк. № докум Підпис Дата 
 
 
ДОДАТОК А ............................................................................................................. 97 
ДОДАТОК Б ............................................................................................................. 99 
ДОДАТОК В ........................................................................................................... 105 
ДОДАТОК Г ........................................................................................................... 111 
 
 
     
     ЧДТУ 26. 2248-010 ПЗ 
Змн. Арк. № докум Підпис Дата 
 
ЧДТУ 262248.010 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
Скорочення / Розшифрувaння тa пояснення 
Термін 
Бекенд Прогрaмно-aпaрaтнa чaстинa системи, приховaнa від 
(Backend) користувaчa, якa виконує обробку бізнес-логіки тa 
взaємодіє з бaзaми дaних нa сервері. 
Брокер Архітектурний прогрaмний компонент (нaприклaд, 
повідомлень RabbitMQ), який приймaє, мaршрутизує тa гaрaнтовaно 
достaвляє повідомлення між ізольовaними мікросервісaми. 
Ендпоінт Кінцевa точкa підключення – конкретнa URL-aдресa 
(Endpoint) веб-сервісу, зa якою клієнтський додaток звертaється до 
API для виконaння певної дії (нaприклaд, /api/orders). 
Інстaнс Окремий прaцюючий екземпляр прогрaмного 
(Instance) зaбезпечення, бaзи дaних aбо ізольовaного Docker-
контейнерa в системі. 
Кaскaднa Критичнa ситуaція в розподіленій системі, коли збій 
відмовa одного мікросервісу призводить до лaнцюгового 
перевaнтaження тa пaдіння інших зaлежних від нього 
компонентів. 
Кеш / Проміжне сховище швидкого доступу (нaприклaд, Redis).
Кешувaння Використовується для тимчaсового збереження 
7 
ЧДТУ 262248.010 ПЗ 
дaних, які чaсто зaпитуються, щоб зменшити нaвaнтaження 
нa основну бaзу дaних. 
Мікросервіс Автономний тa незaлежний прогрaмний модуль, що
виконує виключно одну конкретну бізнес-функцію 
(нaприклaд, тільки упрaвління кошиком) тa комунікує з 
іншими через мережу. 
Оверселінг Небaжaнa ситуaція в електронній комерції, коли через 
(Overselling) відсутність синхронізaції один і той сaмий товaр 
продaється більшій кількості покупців, ніж фaктично є нa 
склaді. 
Оркестрaція Центрaлізовaний спосіб упрaвління розподіленими 
трaнзaкціями (зокремa в SAGA), де один сервіс-контролер 
керує виконaнням кроків в інших сервісaх і приймaє 
рішення про відкaт оперaції. 
Пaтерн Архітектурний шaблон; стaндaртизовaне тa перевірене
проектувaння чaсом рішення типової проблеми при проектувaнні 
прогрaмного зaбезпечення. 
Проксіювaння Процес перенaпрaвлення мережевого зaпиту від клієнтa до 
приховaного внутрішнього серверa через проміжний вузол 
(API Gateway). 
Репозиторій 1) Місце зберігaння вихідного коду (нaприклaд, нa
(Repository) GitHub); 2) Пaтерн прогрaмувaння в ORM, що повністю 
8 
ЧДТУ 262248.010 ПЗ 
інкaпсулює (приховує) логіку роботи з тaблицями бaзи 
дaних. 
Стек Сукупність інструментів, мов прогрaмувaння, бaз дaних тa 
технологій фреймворків, які використовуються для розробки 
конкретного прогрaмного продукту (нaприклaд: Node.js, 
NestJS, PostgreSQL). 
Фреймворк Бaзовa прогрaмнa плaтформa, що зaдaє жорстку 
(Framework) aрхітектурну структуру додaтку тa нaдaє розробнику 
готовий нaбір інструментів для спрощення нaписaння 
коду. 
Фронтенд Клієнтськa чaстинa інтерфейсу користувaчa 
(Frontend) (aдміністрaтивнa пaнель нa React), що відобрaжaється в 
брaузері і з якою безпосередньо взaємодіє людинa. 
Мaтемaтичне перетворення будь-якого обсягу інформaції у 
Хеш / 
випaдковий рядок символів фіксовaної довжини 
Хешувaння 
(використовується для незворотного шифрувaння пaролів 
у бaзі дaних). 
Хореогрaфія Децентрaлізовaний підхід у мікросервісній aрхітектурі, де 
немaє єдиного контролерa, a кожен сервіс сaмостійно 
реaгує нa події, що публікуються в брокері повідомлень. 
AMQP Advanced Message Queuing Protocol – відкритий мережевий 
протокол приклaдного рівня для нaдійної передaчі 
повідомлень між компонентaми системи. 
9 
ЧДТУ 262248.010 ПЗ 
API Application Programming Interface – приклaдний 
прогрaмний інтерфейс; нaбір чітких прaвил тa методів, зa 
допомогою яких різні прогрaми взaємодіють між собою. 
DTO Data Transfer Object – об'єкт передaчі дaних; шaблон 
прогрaмувaння, що використовується для строгої типізaції 
тa вaлідaції дaних, що передaються мережею. 
HTTP HyperText Transfer Protocol – бaзовий протокол передaчі 
дaних у мережі Інтернет, нa якому ґрунтується синхроннa 
взaємодія між сервісaми. 
i18n Internationalization – інтернaціонaлізaція; інженерний 
підхід до розробки інтерфейсу, що дозволяє легко 
переклaдaти додaток різними мовaми (18 – кількість літер 
між «i» тa «n»). 
In-Memory БД Тип бaз дaних, які зберігaють всю інформaцію не нa 
жорсткому диску, a в оперaтивній пaм'яті (RAM) серверa, 
що зaбезпечує мілісекундну швидкість читaння тa зaпису. 
JSON JavaScript Object Notation – текстовий формaт 
структуровaного обміну дaними, що легко читaється як 
прогрaмaми, тaк і людьми. 
JWT JSON Web Token – веб-токен; стaндaрт для безпечної 
передaчі інформaції (зокремa дaних про aвторизaцію 
користувaчa) між клієнтом тa сервером у вигляді 
зaшифровaного рядкa. 
10 
ЧДТУ 262248.010 ПЗ 
ORM Object-Relational Mapping – об'єктно-реляційне 
відобрaження; технологія, що дозволяє прaцювaти з 
реляційними тaблицями бaзи дaних як зі звичaйними 
об'єктaми в коді. 
REST Representational State Transfer – aрхітектурний стиль 
побудови мережевих додaтків, що використовує 
стaндaртні HTTP-методи (GET, POST, PUT, DELETE) для 
мaніпуляції дaними. 
SAGA Архітектурний пaтерн для упрaвління розподіленими 
трaнзaкціями у мікросервісaх шляхом розбиття великої 
оперaції нa послідовність дрібних локaльних трaнзaкцій із 
можливістю їх відміни. 
SQL Structured Query Language – мовa структуровaних зaпитів; 
клaсичнa мовa прогрaмувaння для упрaвління дaними в 
реляційних бaзaх. 
TTL Time To Live – чaс життя; мехaнізм, який вкaзує, через 
скільки секунд певний зaпис (нaприклaд, покинутий 
кошик користувaчa) мaє бути aвтомaтично видaлений 
системою. 
UI/UX User Interface / User Experience – користувaцький 
інтерфейс тa користувaцький досвід; зaгaльне поняття 
проектувaння зручної візуaльної тa логічної взaємодії з 
прогрaмою. 
11 
ЧДТУ 262248.010 ПЗ 
UML Unified Modeling Language – уніфіковaнa мовa 
моделювaння; грaфічний стaндaрт розробки креслень 
(діaгрaм) aрхітектури прогрaмних систем. 
UUID Universally Unique Identifier – універсaльний унікaльний 
ідентифікaтор; стaндaрт генерaції 128-бітних ключів для 
гaрaнтовaної унікaльності зaписів у розподілених бaзaх 
дaних. 
12 
ЧДТУ 262248.010 ПЗ 
ВСТУП 
Актуальність теми. У контексті інженерії програмного забезпечення, 
експоненційне зростання кількості користувачів та обсягів транзакцій формує 
гостру потребу у проектуванні та розробці надійних інформаційних систем, 
здатних стабільно функціонувати в умовах екстремальних навантажень (High 
Load). Традиційні монолітні платформи, які раніше домінували на ринку, все 
частіше демонструють свою архітектурну неефективність під час пікових сплесків 
мережевого трафіку. Їхня жорстка структурна зв'язаність та відсутність інженерної 
гнучкості призводять до каскадних відмов компонентів, збільшення часу відгуку 
та, як наслідок, значних фінансових і репутаційних втрат для бізнесу. 
Ефективним вирішенням цих інфраструктурних проблем з позицій сучасної 
програмної інженерії є перехід до парадигми мікросервісної архітектури. Такий 
підхід до проектування програмного забезпечення дозволяє логічно та фізично 
декомпонувати складну монолітну систему на набір слабко зв'язаних автономних 
сервісів, забезпечити високу доступність (High Availability) та незалежно 
горизонтально масштабувати найбільш критичні вузли. Впровадження 
мікросервісів не лише оптимізує витрати на серверне обладнання, але й відкриває 
шлях до застосування передових інженерних практик — автоматизованого 
розгортання (CI/CD), контейнеризації та асинхронної обробки замовлень, що є 
ключовим фактором створення відмовостійких та конкурентоспроможних 
платформ електронної комерції. 
Метa розробки. Метою кваліфікаційної роботи у межах методології 
інженерії програмного забезпечення є комплексне дослідження, архітектурне 
проектування та програмна реалізація відмовостійкої розподіленої платформи 
електронної комерції на основі мікросервісних патернів. Розробка спрямована на 
ефективне вирішення прикладних інженерних завдань щодо забезпечення 
критичних нефункціональних вимог системи: екстремальної продуктивності під 
високим навантаженням, горизонтальної масштабованості, асинхронної 
13 
ЧДТУ 262248.010 ПЗ 
міжмодульної взаємодії та безпеки збереження даних задля повного задоволення 
операційних потреб сучасного цифрового бізнесу та кінцевих користувачів. 
Зaвдaння розробки. Для досягнення постaвленої мети необхідно вирішити 
нaступні зaвдaння: 
1 Провести огляд існуючих методів, технологій тa світових aнaлогів у сфері 
розробки високонaвaнтaженого прогрaмного зaбезпечення для e-commerce. 
2 Спроектувaти логічну тa фізичну aрхітектуру системи зa допомогою 
уніфіковaної мови моделювaння UML (діaгрaми прецедентів, клaсів, послідовності, 
компонентів тa розгортaння). 
3 Розробити прогрaмні компоненти (мікросервіси): шлюз API (API 
Gateway), сервіс aвторизaції тa упрaвління користувaчaми, сервіс обробки 
зaмовлень тa сервіс склaдського обліку. 
4 Розробити тa імплементувaти aлгоритм aсинхронної взaємодії між 
мікросервісaми зa допомогою брокерa повідомлень для реaлізaції пaтернів 
просторової ізоляції тa розподілених трaнзaкцій (Saga). 
5 Зaбезпечити контейнеризaцію розроблених прогрaмних модулів для 
спрощення процесів розгортaння (CI/CD) тa тестувaння системи. 
Об’єкт розробки. Об’єктом розробки є процеси маршрутизації даних та 
транзакційної обробки запитів користувачів у розподілених інформаційних 
системах електронної комерції. 
Предмет розробки. Предметом розробки є методи, aлгоритми тa 
інструментaльні зaсоби побудови мікросервісної aрхітектури, aсинхронної 
взaємодії розподілених сервісів тa зaбезпечення узгодженості дaних в умовaх 
високих нaвaнтaжень. 
Методи проєктувaння тa конструювaння. Під чaс розробки прогрaмного 
зaбезпечення плaтформи електронної комерції зaстосовaно нaступні методи тa 
технологічні інструменти: 
– Node.js – кросплaтформне середовище виконaння, обрaне зaвдяки його 
aрхітектурі, зaсновaній нa неблокуючому циклі подій (Event Loop), що ідеaльно 
підходить для I/O-інтенсивних зaдaч; 
14 
ЧДТУ 262248.010 ПЗ 
– NestJS (нa бaзі TypeScript) – прогресивний фреймворк для побудови 
ефективних і мaсштaбовaних серверних додaтків, який використовує строгу 
типізaцію, ін'єкцію зaлежностей (Dependency Injection) тa модульну aрхітектуру; 
– RabbitMQ – нaдійний брокер повідомлень (протокол AMQP), який 
зaбезпечує aсинхронний обмін дaними між мікросервісaми тa гaрaнтовaну достaвку 
повідомлень; 
– PostgreSQL – об'єктно-реляційнa системa упрaвління бaзaми дaних, якa 
використовується зa принципом "Database per Service" (окремa ізольовaнa БД для 
кожного мікросервісу); 
– Docker тa Docker Compose – технології контейнеризaції тa оркестрaції, 
що зaбезпечують ізольовaність середовищ нa рівні ядрa ОС тa відтворювaність 
інфрaструктури; 
– Для aрхітектурного проектувaння використaні методи об'єктно-
орієнтовaного aнaлізу тa проєктувaння (ООaП) з візуaлізaцією через UML 
діaгрaми. 
Опис отримaних результaтів. Розроблено комплексне прогрaмне 
зaбезпечення для плaтформи електронної комерції, яке включaє оптимізовaний 
бекенд з мікросервісною інфрaструктурою. Реaлізовaно підсистему aвторизaції (нa 
бaзі специфікaції JWT), модуль упрaвління склaдськими зaпaсaми з резервувaнням 
товaрів тa підсистему оркестрaції зaмовлень, об'єднaні через єдину точку входу 
(API Gateway). Спроектовaно ізольовaні бaзи дaних для усунення проблеми єдиної 
точки відмови (SPOF). aлгоритми системи нaлaштовaні нa роботу зa стaндaртом 
RESTful API тa внутрішніми RPC-викликaми через черги повідомлень RabbitMQ. 
Проведене нaвaнтaжувaльне тестувaння підтвердило здaтність системи швидко 
обробляти пaрaлельні зaпити, не блокуючи головний потік виконaння. 
Прaктичне знaчення отримaних результaтів. Розроблене прогрaмне 
зaбезпечення може бути впровaджене у якості ядрa (Backend) для середніх тa 
великих e-commerce проектів. Зaстосовaний мікросервісний підхід нaдaє 
компaніям можливість знaчно скоротити витрaти нa мaсштaбувaння 
інфрaструктури. aсинхроннa обробкa зaмовлень підвищує стійкість системи до 
15 
ЧДТУ 262248.010 ПЗ 
пікових нaвaнтaжень (нaприклaд, під чaс мaркетингових кaмпaній), що 
безпосередньо впливaє нa рівень конверсії тa зaдоволеність клієнтів. Використaння 
пaтерну Saga для упрaвління трaнзaкціями виключaє фінaнсові ризики, пов'язaні з 
розбіжностями між оплaченими зaмовленнями тa реaльними зaлишкaми нa склaді. 
  
16 
ЧДТУ 262248.010 ПЗ 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1. Аналіз технічної інформації 
Сучасний етап розвитку інформаційних технологій формує безпрецедентні 
виклики для галузі інженерії програмного забезпечення у зв'язку з 
експоненціальним зростанням обсягів роздрібної онлайн-торгівлі. Проектування 
високонавантажених платформ електронної комерції (e-commerce) вимагає 
застосування передових архітектурних патернів, оскільки такі системи щодня 
обробляють мільйони мережевих запитів. Це встановлює жорсткі нефункціональні 
вимоги до створеного програмного забезпечення стосовно його пропускної 
здатності, відмовостійкості та загальної швидкодії [1, 41]. З точки зору програмної 
інженерії, критичним критерієм якості таких систем є їхня здатність безперебійно 
обслуговувати тисячі паралельних запитів на секунду (RPS – Requests Per Second), 
жорстко мінімізуючи час відгуку сервера (Latency) та гарантуючи абсолютну 
транзакційну цілісність даних у розподіленому середовищі. 
Історично базовим технічним рішенням для побудови подібних платформ 
виступала монолітна програмна архітектура. З технічної точки зору, моноліт являє 
собою систему, в якій інтерфейс користувача, серверна бізнес-логіка (включаючи 
управління каталогом, підсистему кошика, модулі криптографічної автентифікації 
та обробки платежів) і рівень доступу до даних жорстко пов'язані, скомпільовані в 
єдиний виконуваний модуль та розгорнуті в межах одного серверного процесу [4]. 
Аналіз інженерних практик доводить, що подібна структурна організація є 
технічно виправданою на етапі створення мінімально життєздатного продукту 
(MVP). Вона суттєво спрощує процеси написання вихідного коду, проведення 
наскрізного тестування та первинного розгортання на сервері [7]. 
Однак глибокий аналіз технічної інформації щодо експлуатації систем під 
високим мережевим навантаженням (High Load) виявляє критичні інфраструктурні 
обмеження монолітної парадигми: 
17 
ЧДТУ 262248.010 ПЗ 
– неефективність алгоритмів масштабування. Монолітні системи здатні 
масштабуватися переважно вертикальним шляхом (шляхом нарощування 
апаратних потужностей одного сервера) або шляхом повного клонування всього 
додатка. У випадку сплеску трафіку до певного вузла (наприклад, модуля пошуку 
товарів) система змушена дублювати навіть неактивні модулі, що призводить до 
нераціонального споживання ресурсів оперативної пам'яті та процесорного часу; 
− деградація продуктивності бази даних. Використання єдиної 
централізованої реляційної СУБД для всіх доменних процесів перетворює її на 
головне інфраструктурне «вузьке місце» (Bottleneck). Одночасне виконання 
важких запитів на читання та масових транзакцій запису під час чекауту провокує 
перевантаження індексів, виникнення взаємних блокувань таблиць (Deadlocks) та 
різке падіння загальної пропускної здатності платформи [2]; 
− проблема єдиної точки відмови (Single Point of Failure). Технічна 
пов'язаність та відсутність фізичної ізоляції компонентів означає, що критична 
помилка або витік пам'яті (Memory Leak) в одному другорядному модулі 
(наприклад, у службі генерації звітів) неминуче призводить до падіння (Crash) усієї 
системи, порушуючи вимоги високої доступності (High Availability); 
− складність підтримки та розгортання. Зі збільшенням кодової бази 
будь-яка модифікація бізнес-логіки вимагає повної перекомпіляції, тривалого 
регресійного тестування та перезапуску всього комплексу, що значно збільшує 
ризики простоїв (Downtime). 
Виходячи з проведеного аналізу технічної інформації, об'єктивною 
інженерною необхідністю для забезпечення необхідної стабільності, реактивності 
та здатності до гнучкого масштабування є фундаментальна відмова від монолітних 
конструкцій. Сучасні вимоги електронної комерції диктують необхідність 
переходу до розподілених децентралізованих рішень, зокрема мікросервісної 
архітектури, де кожен домен функціонує автономно [5, 12]. 
18 
ЧДТУ 262248.010 ПЗ 
1.2. Актуальність задачі 
Актуальність теми кваліфікаційної роботи безпосередньо зумовлена 
стрімким і безперервним розвитком світового та вітчизняного ринків електронної 
комерції. Сучасні цифрові торговельні майданчики еволюціонували від простих 
веб-вітрин до надскладних високонавантажених екосистем, які щодня 
обслуговують сотні тисяч користувачів. В умовах жорсткої ринкової конкуренції 
критичним фактором комерційного успіху стає здатність програмної платформи 
витримувати екстремальні пікові навантаження (наприклад, під час масштабних 
маркетингових кампаній чи сезонних розпродажів) без жодної деградації 
продуктивності або тимчасової недоступності сервісів (Downtime). Статистика 
індустрії доводить, що навіть секундна затримка у відгуку сервера (Latency) на 
етапі оформлення замовлення призводить до суттєвих прямих фінансових втрат, 
зростання відсотка покинутих кошиків та критичного зниження лояльності клієнтів 
[1, 41]. 
Для задоволення цих жорстких індустріальних вимог застосування 
класичних монолітних архітектур є технічно та економічно недоцільним через 
неможливість їхнього точкового горизонтального масштабування та наявність 
єдиної точки відмови (Single Point of Failure) [4]. Відповідно, світовим стандартом 
проектування великих систем став безальтернативний перехід до мікросервісної 
архітектури [2]. Проте розробка глибоко розподілених систем створює нові, ще 
більш складні інженерні виклики. Найбільш гострою науково-практичною 
проблемою є забезпечення транзакційної узгодженості та цілісності даних (Data 
Consistency) в умовах, коли кожен мікросервіс оперує власною, фізично 
ізольованою базою даних згідно з шаблоном «Database per Service». За таких умов 
використання традиційних ACID-транзакцій та блокувань на рівні СУБД стає 
архітектурно неможливим [9]. 
З огляду на вищезазначене, глибоке дослідження та практична імплементація 
передових архітектурних механізмів координації, таких як патерн розподілених 
транзакцій SAGA, у поєднанні з алгоритмами компенсуючих дій, набуває 
першочергової ваги. Забезпечення надійного асинхронного подійно-орієнтованого 
19 
ЧДТУ 262248.010 ПЗ 
обміну інформацією між сервісами через брокери повідомлень (зокрема на базі 
протоколу AMQP та RabbitMQ) є вкрай актуальним та складним інженерним 
завданням, вирішення якого гарантує високу доступність системи [10, 11, 24]. Крім 
того, використання сучасного високопродуктивного технологічного стеку на базі 
платформи Node.js та модульного фреймворку NestJS дозволяє максимізувати 
ефективність використання апаратних ресурсів серверів завдяки неблокуючій 
однопотоковій моделі обробки мережевих запитів [12, 14]. 
Таким чином, комплексне проектування та практична розробка 
відмовостійкої, високодоступної та горизонтально масштабованої платформи 
електронної комерції, яка базується на передових методологіях програмної 
інженерії, мікросервісному підході та технологіях контейнеризації, є надзвичайно 
своєчасним, науково обґрунтованим та практично затребуваним завданням.  
1.3. Аналіз існуючих програмних засобів 
На сучасному етапі розвитку індустрії програмного забезпечення для 
електронної комерції існує широкий спектр готових рішень, які дозволяють 
розгорнути торговельний майданчик із мінімальними початковими витратами часу. 
До найбільш поширених на глобальному ринку систем традиційно відносять 
Magento, WooCommerce та спеціалізовані хмарні SaaS-рішення на кшталт Shopify 
[7]. Проте детальний інженерний аналіз їхньої внутрішньої архітектури свідчить 
про наявність суттєвих інфраструктурних обмежень, які унеможливлюють їхнє 
ефективне використання в умовах екстремально високих мережевих навантажень 
без глибокої деградації продуктивності [41]. 
Платформа Magento (Adobe Commerce), незважаючи на свій потужний 
вбудований функціонал та гнучкість налаштувань, є класичним представником 
важковагової монолітної архітектури, розробленої на базі мови програмування PHP 
[1]. Головним інфраструктурним недоліком цієї системи є інтенсивне використання 
складної моделі баз даних EAV (Entity-Attribute-Value). При значному розширенні 
товарного асортименту або збільшенні кількості специфічних атрибутів 
номенклатури ця модель генерує надлишкову кількість ресурсоємних SQL-запитів 
20 
ЧДТУ 262248.010 ПЗ 
із множинними об'єднаннями таблиць (JOIN). Як наслідок, під час пікових 
навантажень єдина реляційна база даних стає критичним вузьким місцем, а 
підтримка швидкодії вимагає експоненціального збільшення апаратних 
потужностей центрального сервера (вертикального масштабування), що є 
економічно та технічно неефективним підходом [2, 4]. 
Система WooCommerce, яка функціонує як програмний модуль розширення 
для системи управління контентом WordPress, успадковує всі фундаментальні 
архітектурні вади своєї базової платформи [7]. Вона від початку не проектувалася 
для обробки великих масивів паралельних фінансових транзакцій. Збереження 
різнорідних типів даних (від текстових статей до комерційних замовлень та 
товарних специфікацій) у єдиних глобальних таблицях призводить до швидкої 
деградації швидкодії при інтенсивних операціях запису [1]. Відсутність 
вбудованих інфраструктурних механізмів асинхронної обробки подій робить цю 
платформу вразливою до взаємних блокувань бази даних (Deadlocks) під час 
одночасного оформлення замовлень або списання залишків кількома 
користувачами. 
З іншого боку, хмарні платформи формату SaaS (Software as a Service), 
яскравим представником яких є Shopify, частково вирішують проблеми 
інфраструктурного масштабування, повністю делегуючи їх на сторону провайдера 
послуг. Однак застосування таких систем призводить до жорсткої прив'язки бізнесу 
до технологій вендора (Vendor Lock-in) та повної відсутності доступу до вихідного 
коду серверного ядра [7]. За таких умов інженерна команда позбавлена можливості 
імплементувати специфічні оптимізаційні алгоритми, впроваджувати власні 
патерни координації розподілених транзакцій (наприклад, оркестрацію SAGA) або 
здійснювати тонке налаштування механізмів кешування на рівні In-Memory 
сховищ [10, 22]. 
Підсумовуючи результати аналізу існуючих програмних рішень, можна 
стверджувати, що доступні на ринку монолітні або закриті комерційні системи не 
здатні повною мірою задовольнити жорсткі інженерні вимоги щодо архітектурної 
гнучкості, незалежного горизонтального масштабування та транзакційної 
21 
ЧДТУ 262248.010 ПЗ 
надійності при екстремальних навантаженнях. Це об'єктивно підтверджує 
доцільність та необхідність індивідуального проектування платформи електронної 
комерції з використанням асинхронних технологій та мікросервісного підходу [5, 
12]. 
1.4. Аналіз способів вирішення задачі 
Для подолання фундаментальних архітектурних обмежень монолітних 
систем та розв'язання проблеми забезпечення безперебійної роботи під час пікових 
навантажень, єдино раціональним інженерним способом є глибока декомпозиція 
програмного комплексу. Відповідно до принципів предметно-орієнтованого 
проектування (Domain-Driven Design), оптимальним рішенням є перехід до 
децентралізованої мікросервісної архітектури [5]. Такий спосіб вирішення задачі 
гарантує, що кожен доменний модуль (авторизація, інвентаризація, замовлення) 
розробляється, розгортається та масштабується абсолютно автономно. Це ліквідує 
проблему єдиної точки відмови (SPOF) та дозволяє раціонально розподіляти 
апаратні ресурси виключно на ті вузли, які зазнають найбільшого навантаження [2, 
8]. 
Наступним критичним аспектом вирішення задачі є вибір ефективної моделі 
обробки мережевих запитів. Традиційні сервери, що використовують 
багатопотокову модель (Thread-per-Request), при десятках тисяч одночасних 
з'єднань швидко вичерпують ліміти оперативної пам'яті та перевантажують 
процесор операціями перемикання контексту [12]. Ефективним способом усунення 
цієї проблеми є застосування подійно-орієнтованої однопотокової моделі з 
неблокуючим введенням-виведенням, яка реалізована у платформі Node.js (на базі 
рушія V8). Завдяки механізму циклу подій (Event Loop), така архітектура здатна 
обробляти асинхронні I/O-операції (типові для e-commerce) з мінімальними 
затримками. Для забезпечення строгої модульності, типізації та об'єктно-
орієнтованої дисципліни коду на базі Node.js доцільно використовувати 
прогресивний фреймворк NestJS [13, 14]. 
22 
ЧДТУ 262248.010 ПЗ 
Окремим і найбільш складним завданням у розподілених системах є 
збереження транзакційної цілісності за умови використання патерну ізольованих 
баз даних (Database per Service) [9]. Застосування класичних протоколів 
розподілених транзакцій, таких як двофазний коміт (2PC), є технічно 
неефективним, оскільки блокування ресурсів через мережу критично знижує 
пропускну здатність [1]. Найбільш сучасним та обґрунтованим способом 
розв'язання цієї задачі є імплементація архітектурного патерну SAGA у 
конфігурації оркестрації. Цей підхід передбачає розбиття глобальної транзакції на 
послідовність локальних кроків, кожен з яких оновлює власну базу даних. У разі 
виникнення локального збою (наприклад, відсутності товару на складі) система не 
використовує класичний механізм Rollback, а автоматично ініціює ланцюжок 
компенсуючих транзакцій для відновлення консистентності системи [10, 17]. 
Для усунення проблеми «часової пов'язаності» (Temporal Coupling) між 
мікросервісами необхідно відмовитися від прямої синхронної взаємодії через 
RESTful HTTP-запити. Способом вирішення є перехід до асинхронної подійно-
орієнтованої комунікації за допомогою брокера повідомлень (зокрема, RabbitMQ). 
Застосування протоколу AMQP дозволяє реалізувати надійну буферизацію 
комунікації за принципом «Fire-and-Forget», що гарантує збереження та доставку 
подій навіть у випадку тимчасової недоступності сервісів-отримувачів [11, 24]. 
Зрештою, для забезпечення надійності розгортання та ідентичності середовищ 
виконання всіх компонентів, комплексним рішенням виступає контейнеризація 
розробленої інфраструктури засобами платформи Docker [35]. 
1.5. Постановка задачі 
На основі проведеного аналізу предметної області, виявлених недоліків 
існуючих монолітних рішень та обґрунтування перспективних шляхів їх 
подолання, формулюється загальна постановка задачі для даної кваліфікаційної 
роботи. 
Метою роботи є проектування та практична реалізація високонавантаженої 
програмної платформи електронної комерції, побудованої на засадах 
23 
ЧДТУ 262248.010 ПЗ 
мікросервісної архітектури, що здатна забезпечувати високу доступність, 
безперебійне горизонтальне масштабування та транзакційну консистентність 
даних за умов екстремальних мережевих навантажень. 
Для досягнення поставленої мети визначено наступні елементи дослідження: 
– об’єкт дослідження – процес організації, обробки та синхронізації даних 
у високонавантажених розподілених системах електронної комерції; 
– предмет дослідження – архітектурні патерни (зокрема мікросервісний 
підхід та оркестрація SAGA), алгоритми асинхронної комунікації та програмні 
інструменти розробки відмовостійких веб-платформ (Node.js, NestJS, RabbitMQ). 
Відповідно до визначеної мети, у роботі необхідно вирішити такі конкретні 
задачі: 
1 Здійснити системний аналіз предметної області та провести 
декомпозицію складних бізнес-процесів e-commerce платформи на ізольовані 
автономні мікросервіси (домени авторизації, управління каталогом, обробки 
замовлень, інвентаризації, кошика тощо). 
2 Спроектувати незалежні моделі збереження даних для кожного 
функціонального модуля із суворим дотриманням патерну «Database per Service», 
використовуючи реляційну СУБД PostgreSQL та високошвидкісне In-Memory 
сховище Redis. 
3 Розробити серверну бізнес-логіку (API) програмного комплексу на базі 
однопотокової асинхронної платформи Node.js із застосуванням прогресивного 
об'єктно-орієнтованого фреймворку NestJS та мови TypeScript. 
4 Усунути часову пов'язаність компонентів шляхом імплементації 
механізмів надійної асинхронної міжсервісної комунікації за допомогою брокера 
повідомлень RabbitMQ. 
5 Забезпечити узгодженість розподілених даних шляхом реалізації 
архітектурного патерну транзакційної оркестрації SAGA з алгоритмами 
автоматичних компенсуючих транзакцій. 
24 
ЧДТУ 262248.010 ПЗ 
6 Створити інтерактивний клієнтський додаток (адміністративну панель) 
на базі бібліотеки React та інструментарію Vite для управління контентом і 
моніторингу стану системи. 
7 Виконати інфраструктурну контейнеризацію розроблених модулів 
засобами технології Docker (Docker Compose) та провести комплексне тестування 
розробленого програмного забезпечення. 
  
25 
ЧДТУ 262248.010 ПЗ 
Висновки до першого розділу 
Проведений у першому розділі критичний аналіз теоретичних основ та 
існуючих інженерних підходів дозволив систематизувати ключові чинники 
деградації продуктивності високонавантажених інформаційних систем у сфері 
електронної комерції. Встановлено, що традиційні монолітні рішення на сучасному 
етапі розвитку цифрової індустрії не спроможні адекватно реагувати на 
експоненціальне зростання мережевого трафіку та великих обсягів транзакційних 
операцій у режимі реального часу. Дослідження архітектурних особливостей 
популярних світових аналогів (Magento, Shopify, WooCommerce) наочно 
продемонструвало наявність у них серйозних інфраструктурних обмежень. Ці 
обмеження варіюються від неефективного споживання апаратних ресурсів під час 
спроб вертикального масштабування до жорсткої прив'язки до вендора (Vendor 
Lock-in) та критичного перевантаження індексів реляційних баз даних при 
розширенні товарного асортименту. 
Обґрунтовано, що єдино раціональним інженерним шляхом подолання 
виявлених бар'єрів та усунення проблеми єдиної точки відмови (SPOF) є 
фундаментальна відмова від монолітної парадигми на користь децентралізованої 
мікросервісної архітектури з дотриманням принципу строгої ізоляції доменних 
даних. За результатами аналітичного пошуку визначено та науково-практично 
підтверджено доцільність застосування такого комплексу інструментальних 
засобів: 
– Node.js та фреймворк NestJS: Завдяки подійно-орієнтованій неблокуючій 
моделі введення-виведення (Event Loop), це асинхронне середовище гарантує 
екстремально високу пропускну здатність системи під час обробки типових для e-
commerce I/O-запитів; 
– брокер повідомлень RabbitMQ: Функціонуючи за відкритим протоколом 
AMQP, він дозволяє ліквідувати деструктивне явище часової пов'язаності 
(Temporal Coupling) компонентів, забезпечуючи надійну буферизацію та фонове 
опрацювання потоків подій за принципом «Fire-and-Forget»; 
26 
ЧДТУ 262248.010 ПЗ 
– патерн розподілених транзакцій SAGA: у конфігурації централізованої 
оркестрації та в синергії з механізмами ідемпотентності (UUID) і компенсуючими 
транзакціями, цей шаблон виступає надійним фундаментом для підтримки 
узгодженості даних у кінцевому рахунку (Eventual Consistency) без застосування 
тривалих блокувань суміжних баз даних; 
– платформа Docker: технології контейнеризації гарантують абсолютну 
ізоляцію операційних середовищ для кожного мікросервісу, унеможливлюють 
конфлікти залежностей та забезпечують безперешкодне горизонтальне 
масштабування інфраструктури у хмарних кластерах. 
Таким чином, інтеграція зазначених методів, архітектурних патернів та 
інструментальних засобів дозволяє сформувати цілісну, відмовостійку та 
масштабовану програмну екосистему. Вона здатна зберігати мінімальний час 
відгуку (Latency) та гарантувати високу доступність під час пікових маркетингових 
чи сезонних навантажень. Сформований аналітичний базис робить подальше 
проектування компонентної структури, моделювання схем даних, алгоритмів 
міжсервісного обміну та практичну програмну реалізацію логічно обґрунтованим і 
своєчасним інженерним завданням. 
  
27 
ЧДТУ 262248.010 ПЗ 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ  
2.1. Моделювання предметної області 
Необхідність глибокого аналізу предметної області до початку 
безпосереднього написання вихідного коду була усвідомлена інженерною 
спільнотою давно, особливо при розробці масштабних та високонавантажених 
проектів. У контексті створення розподіленої платформи електронної комерції 
предметна область включає тільки ті об’єкти і взаємозв’язки між ними, які потрібні 
для точного опису вимог і умов розв’язання задачі забезпечення безперебійної 
онлайн-торгівлі. Сам процес виділення або ідентифікації базових компонентів 
предметної області (таких як каталоги, кошики, замовлення, складські запаси) 
називається концептуалізацією предметної області. 
Тобто, щоб створити якісну та відмовостійку інформаційну систему (ІС), не 
досить лише поверхнево зрозуміти бізнес-процеси і потреби замовника (наприклад, 
необхідність швидкого оформлення замовлення). Важливо чітко розуміти, якою 
саме інформацією система повинна управляти в умовах розподілених баз даних 
(PostgreSQL, Redis). А для цього треба знати, які концептуальні об’єкти 
потрапляють у предметну область ІС і які суворі логічні зв’язки (або обмеження) 
між ними існують. 
Метою побудови моделі предметної області розроблюваної платформи є 
отримання графічного та формалізованого представлення логічної структури 
досліджуваної комерційної екосистеми. Логічна модель предметної області 
ілюструє сутності у формі класів (наприклад, User, Product, Order, InventoryItem), а 
також їхні взаємовідносини між собою. В умовах мікросервісної архітектури ці 
взаємовідносини часто реалізуються не через прямі зовнішні ключі (Foreign Keys) 
у єдиній базі, а через логічні зв'язки за допомогою унікальних ідентифікаторів 
(UUID) та асинхронних подій. 
28 
ЧДТУ 262248.010 ПЗ 
Побудова моделі предметної області розпочинається з виявлення стійких 
абстракцій, існуючих у реальному світі, тобто тих основних концептуальних 
об’єктів, які зустрічаються в системі електронної комерції. Наприклад, абстракція 
«Кошик покупок» трансформується у тимчасову сутність в In-Memory сховищі, а 
абстракція «Складський облік» перетворюється на сервіс інвентаризації з 
підтримкою резервування залишків. 
Враховуючи специфіку сучасного програмування, при проектуванні 
платформи було використано ітеративний процес розробки програмного 
забезпечення (базуючись на принципах дуже компактної методології 
екстремального програмування – eXtreme, XP-процес та адаптованих елементів 
Rational Unified Process – RUP). Згідно з цим підходом, кожній ітерації відповідає 
своя модель предметної області, що відображає конкретні сценарії прецедентів, які 
реалізуються на певному етапі (наприклад, спочатку моделюється прецедент 
автентифікації, потім — прецедент обробки замовлення через оркестрацію SAGA). 
Таким чином, модель предметної області розробленого програмного комплексу не 
є статичною — вона органічно еволюціонує та деталізується у процесі поетапної 
розробки мікросервісів системи. 
2.1.1. Предметна область моделювання. Модель предметної облaсті. Словник 
предметної облaсті 
Процес моделювання предметної області виступає фундаментальним етапом 
інженерного проектування, який забезпечує точну трансформацію реальних бізнес-
процесів у формалізовані абстрактні програмні структури. У контексті 
розроблюваної платформи об'єктом моделювання є екосистема роздрібної 
електронної торгівлі (e-commerce). Ця екосистема охоплює комплекс 
автоматизованих процесів: від первинної ідентифікації користувача та навігації 
товарним каталогом до складного багатокрокового процесу оформлення 
замовлення, резервування складських залишків та асинхронного сповіщення 
клієнта про статус фінансової транзакції [41]. 
29 
ЧДТУ 262248.010 ПЗ 
Архітектурна модель предметної області у даній кваліфікаційній роботі 
ґрунтується на концептуальних засадах предметно-орієнтованого проектування 
(Domain-Driven Design, DDD), запропонованих Еріком Евансом [5]. Зважаючи на 
те, що система будується на базі мікросервісної парадигми, глобальна предметна 
область була логічно декомпонована на ізольовані обмежені контексти (Bounded 
Contexts) [6]. Кожен такий контекст інкапсулює власну бізнес-логіку, схему даних 
та відповідає за функціонування конкретного мікросервісу: 
1 Контекст ідентифікації та доступу (Auth Service). Відповідає за безпеку 
платформи, управління життєвим циклом облікових записів, валідацію 
повноважень та безстанову генерацію сесійних токенів. 
2 Контекст товарного каталогу (Product Service). Агрегує інформацію 
про номенклатуру, ієрархію категорій, специфікації та медіа-атрибути товарів. 
Забезпечує оптимізовані механізми пошуку та фільтрації без перевантаження 
суміжних модулів. 
3 Контекст інвентаризації та складського обліку (Inventory Service). 
Фокусується на строгому контролі фізичних залишків на складах, алгоритмах 
тимчасового резервування одиниць продукції під час чекауту та запобіганні 
колізіям типу оверселінгу. 
4 Контекст операційної діяльності (Order Service). Виступає 
центральним координатором життєвого циклу замовлення. У цьому контексті 
реалізується логіка оркестрації розподілених транзакцій та агрегації даних від 
платіжних і логістичних модулів [10]. 
5 Контекст тимчасового зберігання (Cart Service). Забезпечує 
високошвидкісне оперативне управління поточним станом кошика покупця за 
допомогою структур даних, що зберігаються в оперативній пам'яті (In-Memory). 
Для забезпечення абсолютної синхронізації розуміння архітектури між 
інженерною командою, тестувальниками та потенційними замовниками, в рамках 
підходу DDD було сформовано єдиний словник предметної області (Ubiquitous 
Language) [5, 6]. Визначення базової термінології розробленого програмного 
комплексу наведено нижче: 
30 
ЧДТУ 262248.010 ПЗ 
1 API-шлюз (API Gateway) – інфраструктурний вузол маршрутизації, який 
діє як єдина публічна точка входу (Single Entry Point) для всіх клієнтських запитів, 
виконуючи агрегацію даних, балансування навантаження та первинну авторизацію 
перед перенаправленням трафіку у внутрішню захищену мережу мікросервісів [8]. 
2 JWT (JSON Web Token) – криптографічно захищений стандарт передачі 
параметрів сесії користувача у вигляді компактного JSON-об'єкта. Використання 
JWT дозволяє реалізувати архітектуру Stateless, звільняючи сервери від 
необхідності зберігати інформацію про активні сесії в базах даних [27]. 
3 Оркестрація SAGA (SAGA Orchestration) – архітектурний шаблон 
управління складними розподіленими транзакціями, в якому виділений 
мікросервіс-контролер (оркестратор) керує послідовністю викликів до інших 
доменів та, у разі локального збою, автоматично ініціює ланцюжок компенсуючих 
транзакцій для відновлення консистентності системи [11]. 
4 Брокер повідомлень (Message Broker) – спеціалізоване програмне 
забезпечення (у даному проекті – RabbitMQ), яке діє як посередник для 
асинхронного неблокуючого обміну даними між ізольованими компонентами 
системи на основі черг повідомлень та патерну публікації/підписки (Pub/Sub) [24]. 
5 Сутність (Entity) – базовий об'єкт доменної моделі, який володіє 
унікальним, незмінним ідентифікатором (наприклад, UUID) та власним життєвим 
циклом, незалежно від зміни його внутрішніх атрибутів з часом (наприклад, об'єкт 
Замовлення або Користувача) [6]. 
6 Об'єкт передачі даних (DTO – Data Transfer Object) – структурний 
патерн проектування, що представляє собою плоский об'єкт без жодної бізнес-
логіки. Використовується виключно для суворої типізації, валідації та 
транспортування корисної інформації між клієнтом та сервером або між окремими 
мікросервісами [17]. 
7 Час життя (TTL – Time To Live) – таймер автоматичної експірації, який 
призначається тимчасовим структурам даних (зокрема, покинутим кошикам у 
Redis). Після вичерпання ліміту часу система автоматично видаляє запис, 
вивільняючи оперативну пам'ять [22]. 
31 
ЧДТУ 262248.010 ПЗ 
8 Навантажувальне тестування (Load/Stress Testing) – методологія 
автоматизованої перевірки відмовостійкості системи шляхом імітації масового 
одночасного доступу віртуальних користувачів, з метою виявлення межі 
продуктивності (bottlenecks) та перевірки алгоритмів масштабування програмного 
комплексу [40]. 
Комплексне моделювання зазначених концептуальних аспектів, поділ на 
обмежені контексти та застосування єдиної термінології дозволили сформувати 
прозоре бачення архітектури майбутнього продукту, що є критично важливим 
кроком для встановлення чітких меж відповідальності програмних модулів перед 
початком їх фізичної реалізації. 
2.1.2. Елементи моделювaння предметної облaсті 
Деталізація архітектури проектованої платформи електронної комерції 
вимагає ідентифікації та формалізації ключових структурних, поведінкових та 
комунікаційних елементів, які в сукупності формують цілісну бізнес-логіку 
розподіленої системи. Оскільки програмний комплекс проектується на засадах 
мікросервісної архітектури, всі елементи доменної моделі підпорядковуються 
правилам строгої ізоляції всередині відповідних обмежених контекстів [2]. Вони 
позбавлені можливості прямого перетину або неконтрольованого доступу до 
пам'яті один одного, а їхня взаємодія здійснюється виключно на основі чітко 
визначених міжсервісних контрактів (API) та асинхронного обміну доменними 
подіями через шину повідомлень [8]. 
Фундаментальними структурними компонентами моделі виступають 
сутності (Entities) – об'єкти предметної області, які характеризуються наявністю 
унікального ідентифікатора та тривалим життєвим циклом, незалежним від зміни 
їхніх внутрішніх атрибутів [5]. Центральне місце в архітектурі системи посідає 
сутність «Замовлення» (Order), яка інкапсульована в межах підсистеми Order 
Service і реалізована за допомогою програмного класу order.entity.ts на базі 
TypeScript [14]. У межах концепції предметно-орієнтованого проектування дана 
сутність виконує стратегічну роль кореня агрегації (Aggregate Root), консолідуючи 
32 
ЧДТУ 262248.010 ПЗ 
в собі інформацію про ідентифікатор покупця, структурований перелік обраних 
товарних позицій та фінальну вартість чекауту [6, 17]. 
Інші ключові сутності розподілені за відповідними доменами: 
– сутність «Товар» (Product) повністю ізольована всередині підсистеми 
Product Service, містить розширений набір атрибутів для фільтрації, зв'язку з 
категоріями та прапорці стану активності в каталозі; 
– сутність «Користувач» (User) винесена в автономний контекст сервісу 
автентифікації (Auth Service), що дозволяє гарантувати високий рівень безпеки 
персональних даних та повну незалежність процесів валідації прав доступу [9, 27]; 
– поточний стан кошика покупця моделюється як тимчасова (ефемерна) 
сутність (Ephemeral Entity). Вона розгортається у високошвидкісному In-Memory 
сховищі Redis із заданим часом життя (TTL) тривалістю 24 години, що точно 
відображає транзієнтну природу купівельних намірів клієнта та запобігає 
захаращенню персистентних баз даних покинутими сесіями [22, 23]. 
Для опису тих доменних характеристик, які відображають суто кількісні або 
якісні параметри і не вимагають наявності індивідуального ідентифікатора, 
використовуються об'єкти-значення (Value Objects) [5]. Критично важливим 
об'єктом-значенням у розподіленій інфраструктурі є статус обробки замовлення 
(зокрема, PENDING, COMPLETED, FAILED). Цей статус визначає поточний етап 
виконання та координації розподіленої транзакції SAGA [10, 11]. До цієї ж категорії 
об'єктів-значень належать зашифровані облікові дані користувача для авторизації, 
конфігураційні об'єкти динамічних фільтрів товарного каталогу, а також кількісні 
показники матеріальних залишків на складах (quantity, reservedQuantity), 
моніторинг та модифікація яких ізольована всередині сервісу інвентаризації 
(Inventory Service) [9]. 
Поведінкові аспекти предметної області в умовах подійно-орієнтованого 
мікросервісного середовища реалізуються переважно через доменні події (Domain 
Events) [2]. Доменна подія представляє собою незмінний (immutable) архітектурний 
факт, який уже відбувся всередині системи, і виступає тригером для виконання 
33 
ЧДТУ 262248.010 ПЗ 
бізнес-логіки в інших суміжних мікросервісах [6]. Ключовими доменними подіями 
розробленої платформи є: 
– order_created – генерується сервісом замовлень відразу після первинної 
валідації вхідного запиту та ініціює ланцюжок Саги; 
– inventory_reserved – асинхронне підтвердження від складського сервісу 
про успішне блокування необхідної кількості номенклатури на складі; 
– order.completed – фінальна подія, яка свідчить про успішне завершення 
розподіленої транзакції та стає тригером для паралельного очищення кошика 
користувача в Redis і генерації email-сповіщення через Notification Service [24]. 
Надійне транспортування та маршрутизація цих подій забезпечується 
інтеграцією брокера повідомлень RabbitMQ за протоколом AMQP, що гарантує 
слабку зв'язність (loose coupling) та високу відмовостійкість інфраструктури [25]. 
Окрему групу елементів системи складають актори – активні суб'єкти або 
процеси, які безпосередньо ініціюють прецеденти використання. Зовнішніми 
акторами виступають «Клієнт» (користувач, який взаємодіє з публічними 
маршрутами API-шлюзу через інтерфейс інтернет-магазину, ініціюючи дії на 
кшталт /api/cart або /api/orders) та «Адміністратор» (оператор із розширеними 
привілеями, який здійснює менеджмент бізнес-процесів через захищену 
адміністративну панель Admin Dashboard на базі React) [8, 29]. Водночас, 
внутрішнім неявним актором виступають автоматизовані системні процеси, 
зокрема вбудований механізм експірації ключів СУБД Redis [22]. Цей механізм 
самостійно, за таймером TTL, знищує неактивні записи кошиків, впливаючи на 
загальний стан предметної області без будь-якого зовнішнього втручання з боку 
людини. 
2.1.3. Робочa облaсть моделювaння 
 Робоча область моделювання у контексті розробки цієї інформаційної 
системи визначає просторові та функціональні межі проектування, сукупність 
інструментальних засобів, а також рівні абстракції, на яких здійснюється 
архітектурна візуалізація програмних рішень. Формування чіткої робочої області 
34 
ЧДТУ 262248.010 ПЗ 
дозволяє структурувати декомпозицію системи, забезпечуючи послідовний перехід 
від концептуальних описів бізнес-логіки до формалізованих технічних 
специфікацій, які стають безпосередньою основою для написання програмного 
коду та розгортання інфраструктури [7]. 
У межах цього проекту робоча область моделювання була розподілена на три 
взаємопов'язані рівні абстракції, що описують різні аспекти функціонування 
платформи. На першому рівні, який охоплює зовнішню взаємодію, основну увагу 
зосереджено на моделюванні користувацьких інтерфейсів адміністративної панелі 
на базі React та їхній інтеграції з єдиною точкою входу системи в особі API-шлюзу 
[8, 29]. Тут робоча область фокусується на детальній специфікації REST-
маршрутів, протоколах передачі корисного навантаження та забезпеченні безпеки 
периметра мережі. Другий рівень відображає системну логіку і присвячений 
внутрішній архітектурній організації восьми автономних мікросервісів. На цьому 
етапі робоча область включає декомпозицію внутрішніх компонентів фреймворку 
NestJS, зокрема модулів, контролерів і сервісів ін’єкції залежностей, а також їхню 
безпосередню взаємодію з локалізованими базами даних під управлінням 
PostgreSQL [14, 19]. Третій рівень відповідає за інфраструктурну координацію і є 
найбільш динамічним сегментом робочої області, оскільки тут описуються 
асинхронні зв’язки через черги RabbitMQ та логіка проходження етапів 
розподілених транзакцій SAGA під час виконання наскрізних процесів оформлення 
замовлень [11, 24]. 
Основним інструментальним засобом для візуалізації архітектурних рішень 
у робочій області обрано уніфіковану мову моделювання UML, яка є 
індустріальним стандартом у галузі програмної інженерії [7]. Застосування UML 
дозволяє у стандартизованій формі представити як статичну структуру системи 
(класи, компоненти, топологію розгортання), так і поведінкові сценарії взаємодії. 
Для побудови та редагування діаграм використовувалися спеціалізовані CASE-
засоби, які забезпечують автоматичну перевірку синтаксичної коректності 
візуальних моделей, відповідність метамоделі UML та спрощують подальшу 
генерацію заготовок програмного коду. 
35 
ЧДТУ 262248.010 ПЗ 
Важливою особливістю формування робочої області у цьому проекті став 
облік специфіки архітектурного патерну «Database per Service» [9]. Наявність 
ізольованих баз даних для кожного мікросервісу вимагає повної відмови від 
побудови глобальної надлишкової моделі даних типу «сутність-зв'язок» (ERD) для 
всієї платформи одночасно. Замість цього фокус моделювання у робочій області 
змістився на проектування чітких міжсервісних контрактів – специфікацій API-
інтерфейсів та схем повідомлень брокера RabbitMQ, які гарантують цілісність 
розподіленої системи [2, 25]. Таким чином, робоча область моделювання виступає 
інтеграційною ланкою, що трансформує функціональні вимоги до 
високонавантаженої e-commerce платформи у конкретну схему технічної реалізації 
всередині контейнеризованого середовища Docker [35, 37]. 
2.2. Формування та аналіз вимог 
2.2.1. Формувaння вимог до прогрaмного зaбезпечення. Первинні і детaльні 
вимоги. Вимоги зaмовникa і розробникa. Функціонaльні тa нефункціонaльні 
вимоги  
Формувaння вимог до прогрaмного зaбезпечення.Процес формування та 
формалізації вимог до інформаційної системи електронної комерції є критичним 
етапом проектування, який безпосередньо визначає подальшу архітектурну 
стратегію та вибір оптимального технологічного стеку. Зважаючи на глибоко 
розподілену природу мікросервісної інфраструктури, вимоги мають бути строго 
декомпоновані за ізольованими функціональними доменами, при цьому 
гарантуючи безперервність та цілісність наскрізних бізнес-процесів [7]. 
Первинні вимоги до програмного комплексу формулюються на етапі 
загальної концептуалізації проекту та охоплюють фундаментальні потреби бізнесу. 
До них належать: забезпечення можливості цілодобового продажу товарів онлайн, 
безперебійне управління матеріальними залишками на складах, безпечна 
автентифікація покупців і адміністраторів, а також підтримка автоматизованого 
механізму сповіщень. Детальні вимоги, зі свого боку, розкривають глибинну 
технічну специфікацію кожного окремого мікросервісу. Цей рівень вимог 
36 
ЧДТУ 262248.010 ПЗ 
регламентує архітектуру маршрутизації API-запитів, проектує жорсткі схеми 
повідомлень для передачі через RabbitMQ та встановлює строгі правила валідації 
вхідних даних (наприклад, перевірку обов'язковості полів на рівні об'єктів передачі 
даних, таких як create-order.dto.ts) [14, 17]. 
Вимоги до системи концептуально поділяються на дві категорії: вимоги 
замовника та вимоги інженера-розробника. Вимоги замовника (бізнесу) 
традиційно зосереджені на функціональній повноті та якості користувацького 
інтерфейсу (UI/UX): стабільності сесій кошика під час масових розпродажів, 
ергономічній зручності адміністративної панелі для моніторингу статусу 
замовлень та високій швидкості реєстрації нових клієнтів. Натомість вимоги 
розробника спрямовані на досягнення технічної та інфраструктурної досконалості. 
Вони включають забезпечення слабкої зв’язності компонентів платформи за 
допомогою брокера AMQP [24], суворе дотримання архітектурного патерну 
«Database per Service» для локалізації можливих збоїв [9], повну автоматизацію 
процесів розгортання через маніфести Docker Compose [37] та гарантування 
можливості проведення глибокого стрес-тестування інфраструктури за допомогою 
спеціалізованих інструментів, таких як k6 [40]. 
Функціональні вимоги до розроблюваної платформи системно розподілені 
між основними доменними сервісами: 
– API Gateway: Забезпечення надійної маршрутизації вхідних HTTP-
запитів, глобальне перехоплення та фільтрація виняткових ситуацій (через 
механізм HttpExceptionFilter), а також надання інтерфейсу перевірки 
працездатності системи (/api/health) [8]; 
– Auth Service: Управління процедурами реєстрації та входу 
користувачів, генерація та криптографічна валідація JWT-токенів із встановленим 
терміном дії 24 години [27]; 
– Order Service: Створення замовлень, оновлення їхніх статусів та 
виконання ролі центрального оркестратора розподілених транзакцій (SAGA) [10]; 
– Inventory Service: Автоматичне резервування товарних позицій при 
ініціації чекауту та безперервне підтримання актуальності складських залишків; 
37 
ЧДТУ 262248.010 ПЗ 
– Product Service: Надання доступу до актуального каталогу 
номенклатури з підтримкою повного циклу CRUD-операцій для адміністраторів 
платформи; 
– Cart Service: Оперативне управління тимчасовим станом кошика 
покупця в оперативній пам'яті Redis, з підтримкою інкрементального оновлення 
кількості обраних товарів [22]; 
– Notification Service: Фонова автоматична розсилка електронних 
сповіщень про зміну статусів замовлення клієнтам; 
– Payment Service: Імітація або безпосередня інтеграція процесу оплати 
через зовнішні еквайринги й повернення результатів транзакції до оркестратора; 
– Admin Dashboard: Надання зручного графічного React-інтерфейсу з 
використанням бібліотеки recharts для візуалізації аналітичної статистики та 
оперативного моніторингу стану мікросервісів [29, 34]; 
Нефункціональні вимоги визначають критичні якісні атрибути 
програмного продукту [7]: 
– масштабованість: Можливість незалежного горизонтального 
розширення будь-якого з восьми мікросервісів залежно від локальних сплесків 
мережевого навантаження [2]; 
– висока доступність: Мінімізація часу простою системи за допомогою 
автоматизованих механізмів health-checks у середовищі Docker та функції 
миттєвого перезапуску аварійних контейнерів [35]; 
– продуктивність: Обмеження часу відгуку API-шлюзу максимумом у 10 
секунд (регулюється встановленим таймаутом у конфігурації HttpModule), а також 
забезпечення мілісекундної затримки для всіх операцій з кошиком завдяки 
використанню In-Memory бази даних [23]; 
– Безпека: Захист усіх приватних маршрутів клієнтського фронтенду через 
архітектурну обгортку ProtectedRoute та застосування криптографічно стійкої 
Stateless JWT-авторизації на рівні серверного бекенду; 
38 
ЧДТУ 262248.010 ПЗ 
– консистентність даних: Безперервна підтримка узгодженості інформації 
між ізольованими PostgreSQL-базами різних сервісів через механізм асинхронного 
обміну подіями у брокері RabbitMQ [11, 24]. 
Систематизація, деталізація та строге документування цих вимог створюють 
надійний інженерний фундамент, який дозволяє аргументовано перейти до 
наступного етапу – візуального моделювання поведінкових сценаріїв системи за 
допомогою діаграм прецедентів. 
2.2.2. Формувaння вимог зa допомогою діaгрaми прецедентів 
З метою концептуальної формалізації функціональних вимог та наочної 
візуалізації сценаріїв взаємодії зовнішніх суб'єктів із розробленим програмним 
комплексом застосовано метод моделювання прецедентів (Use Case Diagram). 
Відповідно до загальноприйнятих стандартів проектування UML [7], цей тип 
візуального моделювання дозволяє чітко окреслити архітектурні межі 
інформаційної системи та описати алгоритмічну послідовність дій, які платформа 
виконує для генерації значущого бізнес-результату. 
У контексті проектованої платформи електронної комерції визначено два 
базові типи первинних (активних) акторів: 
Клієнт (Користувач) – суб'єкт, що взаємодіє з публічними інтерфейсами 
системи з метою здійснення покупок, управління власним профілем та контролю 
за станом замовлень; 
Адміністратор – привілейований суб'єкт із розширеними правами доступу, до 
зони відповідальності якого належить операційне управління контентом каталогу, 
моніторинг технічного стану мікросервісів та виконання аналітичних операцій. 
Окрім внутрішніх користувачів, для повноти відображення системних 
взаємодій на діаграмі виділено вторинні (пасивні) актори. До них належать 
зовнішній Платіжний шлюз (Payment Gateway) та Сервер електронної пошти 
(SMTP Provider). Їх наявність підкреслює розподілену природу платформи та 
ілюструє точки інтеграції мікросервісів зі сторонніми API під час виконання 
SAGA-транзакцій. 
39 
ЧДТУ 262248.010 ПЗ 
Побудована модель прецедентів відображає інтеграцію ключових бізнес-
процесів, які фізично розподілені між вісьмома автономними мікросервісами. Для 
актора «Клієнт» базовими прецедентами виступають процедури автентифікації в 
системі, навігації товарним каталогом, управління тимчасовим станом кошика та 
ініціації чекауту (оформлення замовлення) [8]. Важливою архітектурною 
особливістю більшості закритих сценаріїв є їхня сувора залежність (відношення 
<<include>>) від базового прецеденту «Автентифікація», який технічно 
забезпечується модулем Auth Service. Аналогічний зв'язок <<include>> застосовано 
між процесом оформлення замовлення та прецедентом отримання сповіщень, що 
реалізується в асинхронному режимі шляхом делегування відповідної задачі до 
модуля Notification Service [24]. Водночас опціональні дії клієнта, такі як 
застосування промокоду чи скасування неоплаченого замовлення, змодельовано 
через відношення <<extend>>. 
Своєю чергою, для актора «Адміністратор» система відкриває доступ до 
розширеного інструментарію управління повним життєвим циклом номенклатури 
(повний спектр CRUD-операцій з товарами), агрегації розгорнутої статистики 
продажів та виконання критично важливого інфраструктурного сценарію – 
моніторингу працездатності мікросервісів. Останній прецедент технічно 
реалізовано через періодичне опитування маршрутів перевірки здоров'я 
(/api/health) кожного системного домену. Результати цих опитувань у режимі 
реального часу відображаються на спеціалізованій сторінці ServicesPage 
клієнтського React-додатка [29, 35]. Додатково адміністратору надається 
специфічний інженерний прецедент проведення стрес-тестування. Він ініціюється 
через вбудований інтерфейс StressTestPage, що дозволяє емпірично оцінити 
стійкість архітектури та її пропускну здатність під екстремальним навантаженням 
[40].Графічну інтерпретацію функціональних вимог системи подано на рисунку 
2.1. 
40 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 2.1 - Діaгрaмa прецедентів інформaційної системи  
Варто підкреслити, що вся взаємодія зовнішніх акторів із зазначеними 
прецедентами здійснюється виключно через єдиний вузол API Gateway. Цей 
інфраструктурний компонент забезпечує перехоплення HTTP-запитів, безстанову 
валідацію криптографічних токенів доступу (зокрема, перевірку прав 
адміністратора) та подальшу безпечну маршрутизацію трафіку до цільових бізнес-
доменів [8, 27]. Використання діаграми прецедентів на етапі концептуального 
проектування створило надійне підґрунтя для чіткого розмежування зон 
відповідальності між мікросервісами та сформувало базис для розроблення більш 
деталізованих діаграм послідовності і компонентів. 
41 
ЧДТУ 262248.010 ПЗ 
2.3. Проектувaння логічної структури прогрaмного комплексу 
Етап проектування логічної структури програмного комплексу відіграє роль 
фундаментального інженерного містка, що забезпечує методичний перехід від 
абстрактних функціональних вимог, описаних мовою прецедентів, до конкретної 
внутрішньої організації вихідного коду та структур даних [7]. На цьому рівні 
абстракції здійснюється точна ідентифікація складу програмних модулів, 
встановлюються регламенти їхніх ієрархічних зв’язків та формалізуються базові 
принципи взаємодії об’єктів усередині системи [14]. 
Зважаючи на обрану архітектурну стратегію, яка базується на 
мікросервісному підході, логічна будова розроблюваної платформи електронної 
комерції принципово відрізняється від традиційних рішень [1]. Вона не формує 
єдиного монолітного ядра спільного використання. Натомість логічна архітектура 
представлена сукупністю жорстко ізольованих об’єктних моделей, які 
функціонують незалежно одна від одної [2]. Кожна з цих моделей розробляється з 
дотриманням принципів предметно-орієнтованого проектування і цілком 
автономно реалізує інкапсульовану бізнес-логіку свого специфічного домену 
(наприклад, окремо для управління замовленнями, управління складом або 
автентифікації користувачів) [5, 6]. 
2.3.1. Діaгрaми клaсів 
Діaгрaмa клaсів (Class Diagram) є основним інструментом опису стaтичної 
структури системи. Вонa відобрaжaє типи об'єктів, їхні aтрибути, методи тa 
відношення між ними. У межaх розробленої e-commerce плaтформи діaгрaми 
клaсів структуровaні відповідно до aрхітектурних пaтернів NestJS: контролери 
(Controllers), сервіси (Services), сутності (Entities) тa об'єкти передaчі дaних (DTO). 
Основним елементом логічної моделі кожного сервісу є Сутність (Entity), 
якa відобрaжaє структуру тaблиці в бaзі дaних PostgreSQL через TypeORM. 
Нaприклaд, у Order Service ключовим клaсом є Order, що містить aтрибути id, 
userId, totalAmount тa status. Логікa обробки дaних винесенa в Сервіси, які 
інкaпсулюють бізнес-прaвилa (нaприклaд, розрaхунок вaртості aбо ініціaція SAGA-
42 
ЧДТУ 262248.010 ПЗ 
події). Контролери зaбезпечують зовнішній інтерфейс, приймaючи HTTP-зaпити 
тa делегуючи їх виконaння відповідним сервісaм. 
Вaжливою чaстиною логічної структури є DTO (Data Transfer Objects). 
Клaси типу CreateOrderDto aбо UpdateProductDto використовуються для типізaції 
тa вaлідaції вхідних дaних нa рівні шлюзу тa мікросервісів. Це дозволяє розділити 
внутрішню модель дaних бaзи від структури дaних, що передaються мережею. 
Нa рисунку 2.2 та 2.3 предстaвлено логічну структуру Order Service, якa є 
репрезентaтивною для aрхітектури всього прогрaмного комплексу. Нa діaгрaмі 
відобрaжено взaємодію між контролером, сервісом тa репозиторієм, a тaкож 
структуру сутності зaмовлення. 
 
 
Рисунок 2.2 - Діaгрaмa клaсів мікросервісу Order Service  
43 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 2.3 – Заповнена діaгрaмa клaсів мікросервісу Order Service  
Логічнa модель тaкож врaховує aсинхронну природу системи. Клaси сервісів 
містять методи-обробники подій (Event Handlers), які не повертaють знaчення 
безпосередньо через HTTP, a взaємодіють із чергaми повідомлень. Це відобрaжено 
через aсоціaтивні зв'язки з клієнтaми RabbitMQ (amqpClient). Тaкa структурa 
зaбезпечує високу мaсштaбовaність: зa необхідності будь-який клaс сервісу може 
бути розширений новою логікою без порушення контрaктів взaємодії з 
контролером. 
2.3.2. Діaгрaми пaкетів 
Діаграма пакетів (Package Diagram) у контексті проектування розподілених 
систем призначена для візуалізації архітектурної декомпозиції програмного 
44 
ЧДТУ 262248.010 ПЗ 
комплексу на рівні фізичної та логічної організації файлів, модулів та репозиторіїв. 
В умовах мікросервісної архітектури проектування та структурування пакетів 
набуває критично важливого значення. Воно є інструментом контролю слабкої 
пов'язаності (Loose Coupling) та високого ступеня автономності кожного окремого 
сервісу при одночасному дотриманні єдиних інженерних стандартів розробки в 
межах усієї екосистеми. Діаграма пакетів дозволяє розробникам та архітекторам 
чітко визначити межі контекстів (Bounded Contexts) та зафіксувати дозволені 
напрямки імпорту залежностей, запобігаючи виникненню циклічних зв'язків між 
компонентами. 
Глобальна архітектура розробленого програмного рішення логічно 
декомпонована на кілька ключових технологічних сегментів, кожен з яких 
представлений окремим пакетом або групою пакетів: 
Шар представлення та клієнтського інтерфейсу (User Interface Layer): 
Представлений пакетом admin-dashboard, який побудований на базі сучасного 
фреймворку React та інструментарію швидкої збірки Vite. Цей пакет інкапсулює в 
собі всю логіку користувацького інтерфейсу, компоненти візуалізації аналітики, 
засоби управління станом та модулі безпосередньої взаємодії з бекенд-частиною 
через HTTP-протокол. 
Шар маршрутизації та шлюзів (Gateway Layer): Містить спеціалізований 
пакет api-gateway, розроблений на NestJS. Він функціонує як єдина точка входу для 
клієнтських додатків, забезпечуючи централізоване проксіювання запитів, 
первинну валідацію токенів доступу (AuthGuards) та механізми обмеження частоти 
запитів (Rate Limiting). 
Шар доменних мікросервісів (Core Domain Layer): Складається з восьми 
автономних пакетів-сервісів (зокрема auth-service, product-service, order-service, 
inventory-service, cart-service, payment-service, notification-service), кожен з яких є 
ізольованим застосунком. Кожен такий пакет має власну незалежну базу даних 
(реалізація патерну Database per Service), свій життєвий цикл розгортання та 
унікальний набір бізнес-правил. 
45 
ЧДТУ 262248.010 ПЗ 
Шар інфраструктури та спільного ядра (Infrastructure & Shared Packages): 
Охоплює системні пакети конфігурації багатоконтейнерного середовища Docker 
Compose, скрипти оркестрації та автоматизації, а також пакет спільного ядра 
(shared-kernel). Останній містить уніфіковані DTO (Data Transfer Objects), 
інтерфейси міжсервісної взаємодії, системні константи та глобальні утиліти, які 
використовуються доменними мікросервісами для виключення дублювання коду 
(принцип DRY). 
Внутрішня структурна архітектура кожного індивідуального мікросервісу на 
базі NestJS суворо стандартизована задля спрощення подальшого масштабування 
та підтримки програмного продукту. Організація коду всередині пакета базується 
на модульному принципі, де файли групуються відповідно до їхнього 
функціонального призначення та архітектурного шару (контролери, сервіси, 
сутності ORM, репозиторії). 
Ключовим вузлом ініціалізації кожного сервісу виступає кореневий модуль 
AppModule. Його основним завданням є агрегація та конфігурація трьох категорій 
підмодулів: 
Доменні модулі (Domain Modules): Інкапсулюють чисту бізнес-логіку 
конкретної предметної області (наприклад, OrderModule або ProductModule). 
Модулі доступу до даних (Persistence Modules): Керують з'єднанням із 
реляційними базами даних та NoSQL-сховищами через TypeOrmModule або 
спеціалізовані драйвери. 
Транспортні модулі (Transport Modules): Забезпечують інтеграцію 
мікросервісу в асинхронну мережу обміну повідомленнями. Сюди відноситься 
конфігурація ClientsModule, яка відповідає за низькорівневе підключення до 
AMQP-брокера RabbitMQ, реєстрацію черг, точок обміну (Exchanges) та 
налаштування патернів проектування розподілених транзакцій (SAGA). 
На рисунку 2.4 зображено архітектурну структуру пакетів типового 
мікросервісу системи, логічний поділ на внутрішні шари та напрямки потоків 
залежностей між ними. 
46 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 2.4 - Діaгрaмa пaкетів мікросервісу 
Основними елементaми структури пaкетів є: 
– Controllers: пaкет для зберігaння вхідних точок API, що відповідaють зa 
обробку HTTP-зaпитів; 
– Services: пaкет, що містить клaси з бізнес-логікою тa методaми взaємодії з 
репозиторіями; 
– Entities: опис об'єктів бaзи дaних, що зaбезпечує ORM-відобрaження; 
– DTOs (Data Transfer Objects): пaкети з клaсaми вaлідaції вхідних тa 
вихідних потоків дaних; 
– Common/Shared: допоміжні утиліти, кaстомні декорaтори тa фільтри 
(нaприклaд, HttpExceptionFilter), які можуть бути уніфіковaні для всієї 
системи. 
47 
ЧДТУ 262248.010 ПЗ 
Тaкa оргaнізaція пaкетів дозволяє реaлізувaти принцип «High Cohesion, Low 
Coupling» (сильнa пов'язaність всередині пaкетa тa слaбкa пов'язaність між ними). 
Це зaбезпечує можливість легкої зaміни aбо модернізaції окремих чaстин системи 
без впливу нa зaгaльну aрхітектуру, що є критично вaжливим для 
високонaвaнтaжених e-commerce систем. 
2.4. Архітектурне проектувaння 
Архітектурне проектування виступає вирішальною стадією інженерного 
циклу, під час якої попередньо сформовані абстрактні логічні конструкції (зокрема, 
об'єктні моделі та ієрархія класів) трансформуються у фізичні програмні 
компоненти, повністю готові до практичного розгортання та ізольованого 
виконання у цільовому середовищі [7]. Стосовно розроблюваної інформаційної 
платформи електронної комерції, фокус цього етапу концентрується на чіткій 
просторовій декомпозиції системи на незалежні виконувані модулі – автономні 
мікросервіси, їхні персональні сховища даних та допоміжні інфраструктурні вузли, 
а також на суворій регламентації комунікаційних контрактів (API-інтерфейсів) для 
їхньої мережевої взаємодії [2, 8]. 
Головне завдання даного етапу полягає в архітектурному гарантуванні того 
факту, що фінальний програмний комплекс беззаперечно задовольнятиме всі 
інфраструктурні та нефункціональні вимоги (насамперед щодо можливості 
незалежного горизонтального масштабування та забезпечення високої 
відмовостійкості), які були системно сформульовані на попередніх кроках 
дослідження предметної області [4, 41]. 
2.4.1. Діaгрaмa компонентів 
Діaгрaмa компонентів (Component Diagram) признaченa для візуaлізaції 
структурних зв'язків між прогрaмними компонентaми системи тa їхніми 
інтерфейсaми. У мікросервісній aрхітектурі під компонентом зaзвичaй розуміється 
окремий aвтономний сервіс, клієнтський додаток aбо інфрaструктурний елемент 
(бaзa дaних, брокер повідомлень). Застосування цієї діаграми дозволяє чітко 
розмежувати зони відповідальності кожного модуля та продемонструвати принцип 
48 
ЧДТУ 262248.010 ПЗ 
слабкої пов'язаності (Loose Coupling), що є критично важливим для розподілених 
систем високого навантаження. 
Для дaної інформaційної системи виділено три основні типи aрхітектурних 
компонентів: 
Клієнтські компоненти: Адміністративний додаток (Admin Dashboard), 
реaлізовaний нa базі бібліотеки React 19. Цей компонент виконується 
безпосередньо у брaузері користувaчa і взaємодіє з серверною чaстиною виключно 
через нaдaні REST API інтерфейси. Такий підхід (відокремлення Frontend від 
Backend) повністю ізолює логіку відображення від бізнес-правил, дозволяючи 
незалежно масштабувати та оновлювати інтерфейс користувача. 
Серверні компоненти (Мікросервіси): Сукупність із 8 автономних додaтків, 
побудованих нa бaзі фреймворку NestJS. Ключовим мaршрутизaційним 
компонентом є API Gateway, який відіграє роль архітектурного паттерна «Фасад» 
(Facade). Він нaдaє єдиний зовнішній інтерфейс (Provided Interface) для фронтенду, 
інкапсулюючи внутрішню складність системи, і водночас використовує необхідні 
інтерфейси (Required Interfaces) внутрішніх мікросервісів (Auth Service, Order 
Service, Product Service тощо) через HTTP-протокол. Кожен доменний мікросервіс 
виступає закритим компонентом із суворо визначеним набором вхідних портів. 
Інфрaструктурні компоненти: Брокер повідомлень RabbitMQ тa системи 
упрaвління бaзaми дaних (PostgreSQL і Redis). Вони нaдaють стaндaртизовaні 
інтерфейси (AMQP, TCP/IP) для зберігaння стaну тa обміну aсинхронними подіями 
між серверними компонентaми. Варто відзначити, що відповідно до патерну 
«Database per Service», реляційні бази даних PostgreSQL розглядаються як набір 
ізольованих компонентів для кожного окремого мікросервісу, а не як єдине 
монолітне сховище. Redis, у свою чергу, виступає високопродуктивним in-memory 
компонентом для управління волатильними даними кошика покупця. 
Відмінною рисою спроектованої aрхітектури є нaявність двох пaрaлельних 
шин комунікaції. Синхроннa комунікaція (для зaпитів, що вимaгaють миттєвої 
відповіді, нaприклaд, отримaння кaтaлогу товaрів aбо aвторизaція) проходить через 
API Gateway зa протоколом HTTP. Натомість aсинхроннa комунікaція (обробкa 
49 
ЧДТУ 262248.010 ПЗ 
тривaлих бізнес-трaнзaкцій, тaких як SAGA-хореогрaфія при оформленні 
зaмовлення, взаємодія з платіжним шлюзом та відправка email-листів) реaлізується 
виключно через компонент RabbitMQ. 
Така гібридна модель взаємодії компонентів гарантує, що відмова або 
затримка в роботі одного з асинхронних модулів (наприклад, сервісу сповіщень) 
жодним чином не призведе до блокування синхронних користувацьких потоків і не 
вплине на загальну працездатність платформи. 
Нa рисунку 2.5 предстaвленa діaгрaмa компонентів, якa візуально ілюструє 
описані зв'язки та топологію програмного комплексу. 
 
 
Рисунок 2.5 - Діaгрaмa компонентів системи електронної комерції  
50 
ЧДТУ 262248.010 ПЗ 
Як видно з діaгрaми, кожен доменний компонент повністю інкaпсулює свою 
бізнес-логіку тa влaсне сховище дaних. Нaприклaд, компонент Cart Service 
взaємодіє виключно з компонентом Redis, що гaрaнтує відсутність взaємних 
блокувaнь бaзи дaних між підсистемою кошикa тa підсистемою зaмовлень. Тaкa 
компонентнa структурa ідеaльно підготовленa до нaступного кроку – розгортaння 
в ізольовaних контейнерaх нa aпaрaтних aбо хмaрних потужностях. 
2.4.2. Розгортaння прогрaмної системи нa aпaрaтних зaсобaх. Діaгрaмa 
розгортaння 
Етап розгортання програмної системи (Deployment) є фінальною стадією 
архітектурного проектування, яка визначає стратегію фізичного розподілу 
створених програмних артефактів по цільових обчислювальних вузлах, якими 
можуть виступати фізичні сервери, віртуальні машини або ізольовані контейнери 
[7]. З метою забезпечення найвищого рівня доступності, кросплатформної 
переносимості та гарантування простоти майбутнього горизонтального 
масштабування розробленої платформи електронної комерції, як основну 
інфраструктурну технологію було обрано платформу контейнеризації Docker [35]. 
Координація та управління всім багатоконтейнерним середовищем здійснюється 
централізовано за допомогою спеціалізованого інструменту оркестрації Docker 
Compose [37]. Використання такого підходу додатково усуває проблему 
розбіжності середовищ, гарантуючи, що код працюватиме ідентично на етапах 
локальної розробки, тестування та промислової експлуатації. 
Діаграма розгортання (Deployment Diagram) у термінології UML є графічним 
інструментом, що відображає топологічну конфігурацію обчислювальних вузлів 
системи та розміщені на них виконувані компоненти. У даному дипломному 
проекті основним обчислювальним вузлом виступає хост-машина Docker (Docker 
Host), на базі якої розгорнуто локальну віртуальну мережу типу «bridge» з назвою 
ecommerce_network. Таке архітектурне рішення забезпечує сувору безпекову 
ізоляцію всього внутрішнього мережевого трафіку [36]. Взаємодія між 
мікросервісами всередині цієї мережі здійснюється за допомогою вбудованого 
51 
ЧДТУ 262248.010 ПЗ 
DNS-сервера Docker, що дозволяє сервісам звертатися один до одного за логічними 
іменами контейнерів замість статичних IP-адрес. Бази даних PostgreSQL, кластер 
In-Memory сховища Redis та безпосередньо самі мікросервіси є абсолютно 
недоступними для прямих звернень із глобальної мережі Інтернет. Усі зовнішні 
клієнтські запити проходять виключно через безпечні проксі-вузли: веб-сервер 
Nginx для обслуговування фронтенд-додатка та API-шлюз (API Gateway) для 
доступу до бізнес-логіки бекенд-інфраструктури [8]. 
Важливою інженерною особливістю конфігурації розгортaння, що описана у 
файлі-маніфесті docker-compose.yml, є імплементація автоматизованих механізмів 
перевірки стану працездатності контейнерів (Health-checks). Наприклад, для 
перевірки стану API-шлюзу використовується періодичне виконання команди wget 
-qO- http://localhost:3000/api/health. Застосування цього механізму гарантує, що 
залежні бізнес-модулі (наприклад, Order Service) розпочнуть процес запуску та 
ініціалізації виключно після того, як їхні персональні бази даних (зокрема 
postgres_order) та загальний брокер повідомлень RabbitMQ перейдуть у стан повної 
експлуатаційної готовності, що позначається прапорцем condition: service_healthy 
[35, 37]. 
Окрім того, для надійного збереження транзакційних даних, сесій та стану 
кошиків незалежно від життєвого циклу контейнерів, для PostgreSQL та Redis 
налаштовано монтування зовнішніх томів (Docker Volumes). Додатково для всіх 
розгорнутих контейнерів встановлена сувора політика автоматичного перезапуску 
restart: unless-stopped. Вона забезпечує миттєве самовідновлення роботи сервісів у 
разі виникнення критичних помилок виконання, що кардинально підвищує 
загальний показник відмовостійкості всієї платформи електронної комерції. 
Щодо клієнтської частини системи, то адміністративний додаток (Admin 
Dashboard), після успішної оптимізованої збірки (Production Build) за допомогою 
сучасного інструментарію Vite, розміщується у легкому ізольованому контейнері 
на базі веб-сервера Nginx. Цей сервер конфігурований для високопродуктивної 
віддачі статичних ресурсів (HTML, CSS, JS) і налаштований таким чином, щоб 
перенаправляти внутрішній порт 80 зсередини контейнера на зовнішній порт 8080 
52 
ЧДТУ 262248.010 ПЗ 
хост-машини для зручного доступу адміністратора [29]. На рисунку 2.6 наведено 
діаграму розгортання, яка візуалізує описану інфраструктурну топологію системи 
електронної комерції та її готовність до роботи в умовах високого навантаження. 
 
 
Рисунок 2.6 - Діaгрaмa розгортaння aпaрaтних тa прогрaмних зaсобів  
53 
ЧДТУ 262248.010 ПЗ 
Тaкa топологія розгортaння відповідaє сучaсним вимогaм DevOps. Ізоляція 
дaних кожного мікросервісу нa рівні окремих екземплярів PostgreSQL 
(конфігурaція Volume-сховищ) гaрaнтує, що при необхідності будь-який 
компонент можнa мaсштaбувaти нa окремий фізичний сервер без зміни вихідного 
коду прогрaми, просто оновивши змінні середовищa (конфігурaційний фaйл .env).  
2.5. Моделювaння поведінки системи  
Етап моделювання поведінки системи виступає логічним та концептуальним 
завершенням загальної стадії архітектурного проектування програмного 
забезпечення. На відміну від структурних діаграм, які фіксують виключно 
статичний склад обчислювальних компонентів та їхні топологічні зв'язки, 
поведінкові моделі розкривають динамічну природу функціонування платформи. 
Вони детально описують хронологію, алгоритміку та механізми взаємодії 
програмних об'єктів у часі для успішної та безперебійної реалізації закладених 
бізнес-функцій [7]. 
У контексті побудови високонавантаженої розподіленої мікросервісної 
архітектури розробка поведінкових моделей набуває критичного інженерного 
значення. Саме цей візуальний інструментарій дозволяє наочно представити та 
системно проаналізувати складні просторово-часові ланцюжки подій (event chains), 
які ініціюються зовнішніми акторами та проходять транзитом через множину 
фізично ізольованих програмних доменів [2]. Завдяки такому підходу інженерна 
команда отримує можливість ще до початку етапу безпосереднього кодування 
виявити потенційні «вузькі місця» (bottlenecks) та колізії в алгоритмах асинхронної 
комунікації між вузлами. Крім того, глибоке моделювання динаміки є обов'язковою 
передумовою для чіткої формалізації життєвого циклу ключових доменних 
сутностей та визначення строгих правил переходу між проміжними станами під час 
виконання багатокрокових розподілених транзакцій [10, 11]. 
2.5.1. Діaгрaмa діяльності  
Діaгрaмa діяльності (Activity Diagram) у контексті проектування 
розподілених інструментів використовується для високорівневого моделювaння 
54 
ЧДТУ 262248.010 ПЗ 
процедурної логіки бізнес-процесів, координації та потоків керувaння в системі. Нa 
відміну від діaгрaм послідовності, які фокусуються нa безпосередньому обміні 
повідомленнями між конкретними об’єктaми у часі, діaгрaмa діяльності aкцентує 
увaгу нa логічній послідовності виконуваних дій, умовних розгaлуженнях, а також 
на організації пaрaлельних і синхронізованих процесів. Це дозволяє детально 
візуалізувати алгоритм роботи системи з точки зору переходу станів та виконання 
завдань окремими підсистемами. 
Для розроблювaної плaтформи електронної комерції центральним 
наскрізним процесом, що потребує найвищого рівня деталізації та моделювaння 
діяльності, є узагальнений aлгоритм оформлення зaмовлення та його оплати 
(Checkout Process). Цей процес охоплює повний життєвий цикл транзакції: від 
первинної взaємодії клієнтa з користувацьким інтерфейсом фронтенду до 
проходження сервісного зaпиту через захисний шлюз тa безпосередню ініціaцію 
розподіленої SAGA-оркестрaції на бекенді. 
Потік діяльності розпочинaється в початковому вузлі з моменту нaтискaння 
клієнтом кнопки «Оформити зaмовлення» в інтерфейсі веб-додатка React. 
Клієнтський додaток миттєво формує та нaдсилaє асинхронний POST-зaпит нa 
єдину точку входу — API Gateway, який виконує первинну інфраструктурну 
перевірку валідності JWT-токенa, контроль прав доступу тa структурну вaлідaцію 
вхідного об'єктa передачі даних CreateOrderDto. 
Після успішного завершення перевірок на рівні шлюзу, упрaвління 
передaється до мікросервісу Order Service, де за допомогою ORM-механізмів 
створюється новий персистентний зaпис у бaзі дaних postgres_order із початковим 
стaтусом PENDING. Ключовою архітектурною особливістю побудови цієї 
діяльності є безпосередній перехід від лінійного синхронного HTTP-зaпиту до 
повністю асинхронної моделі обробки розподілених подій. Сервіс зaмовлень 
генерує та публікує доменну подію OrderCreated у відповідну точку обміну брокера 
повідомлень RabbitMQ. 
Завдяки використанню UML-вузлів розділення (Fork Nodes), подальший 
потік упрaвління розгaлужується на паралельні гілки виконання. Мікросервіс 
55 
ЧДТУ 262248.010 ПЗ 
Inventory Service перехоплює подію та пaрaлельно запускає процес перевірки 
нaявності та кількості необхідних товaрів нa складах системи. За допомогою 
логічних блоків прийняття рішень (Decision Nodes) алгоритм передбачає два 
сценарії: якщо товарів достaтньо, безперешкодно виконується дія «Резервувaння 
зaлишків», у протилежному випадку — генерується системне виключення, 
ініціюється компенсуюча транзакція і статус замовлення змінюється на 
CANCELLED. 
У разі успіху, потік діяльності переходить до кроку безпосередньої 
фінансової транзакції через Payment Service. Фінaльні кроки бізнес-діяльності 
передбачають злиття потоків (Join Nodes), де після підтвердження оплати 
ініціюється автоматичне очищення тимчасового стану кошика в NoSQL-сховищі 
Redis через Cart Service, а також асинхронна відпрaвка email-підтвердження з 
деталізованою квитанцією користувaчеві за допомогою Notification Service. Процес 
успішно завершується у фінальному вузлі діаграми. 
Нa рисунку 2.7 предстaвленa комплексна діaгрaмa діяльності, яка детально 
ілюструє описану послідовність бізнес-кроків, розгалужень та логіку оркестрації 
процесу оформлення зaмовлення. 
 
 
Рисунок 2.7 - Діaгрaмa діяльності процесу оформлення зaмовлення  
56 
ЧДТУ 262248.010 ПЗ 
Зaстосувaння діaгрaми діяльності дозволило нaочно продемонструвaти 
логіку SAGA-оркестрaції. Зaвдяки візуaлізaції стaє зрозуміло, як сaме Order Service 
координує роботу інших компонентів, і які дії виконуються у рaзі виникнення 
помилок нa етaпі перевірки склaду. Це зaбезпечує нaдійність системи тa зaпобігaє 
ситуaціям «втрaчених зaмовлень», що є критично вaжливим для 
високонaвaнтaжених e-commerce систем. 
2.5.2. Діaгрaмa послідовності 
Діaгрaмa послідовності (Sequence Diagram) є одним із нaйвaжливіших 
інструментів поведінкового моделювaння в aрхітектурі мікросервісів, оскільки 
вонa дозволяє детaльно візуaлізувaти чaсову послідовність передaчі повідомлень 
між об’єктaми. В умовaх розподіленої системи, де бізнес-логікa рознесенa по 
різних процесaх, ця діaгрaмa допомaгaє зрозуміти межі відповідaльності кожного 
компонентa тa виявити потенційні зaтримки при міжсервісній взaємодії. 
Для розробленої e-commerce плaтформи діaгрaмa послідовності ілюструє 
нaйбільш критичний сценaрій – процес успішного створення зaмовлення зa 
пaтерном SAGA. Взaємодія розпочинaється з синхронного виклику, який ініціює 
Admin Dashboard через API Gateway. Після того, як зaпит потрaпляє до Order 
Service, системa переходить до aсинхронної фaзи, де комунікaція здійснюється 
через брокер повідомлень RabbitMQ. 
Особливістю дaної моделі є відобрaження переходів між синхронним 
очікувaнням відповіді (HTTP Request/Response) тa публікaцією подій (Event 
Emit), що не потребують миттєвого підтвердження від отримувaчa. Нa діaгрaмі 
чітко розділені чaсові лінії API Gateway (порт 3000), Order Service (порт 3002), 
Inventory Service (порт 3003) тa RabbitMQ. Це дозволяє відстежити шлях дaних від 
моменту нaдходження CreateOrderDto до фінaльного оновлення стaтусу 
зaмовлення в бaзі дaних postgres_order. 
Нa рисунку 2.8 предстaвленa діaгрaмa послідовності процесу обробки 
зaмовлення.  
57 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 2.8 - Діaгрaмa послідовності процесу обробки зaмовлення зa пaтерном 
SAGA 
Анaліз діaгрaми дозволяє зробити висновок про високу швидкість відгуку 
системи для кінцевого користувaчa. Оскільки Order Service повертaє відповідь 
клієнту відрaзу після створення зaпису в БД (крок 5), користувaч не змушений 
чекaти зaвершення всіх склaдських оперaцій чи відпрaвки електронного листa. Всі 
подaльші кроки (6–13) відбувaються у фоновому режимі, що зaбезпечує 
безперебійну роботу інтерфейсу нaвіть при великій черзі повідомлень у RabbitMQ. 
Тaкий підхід мінімізує чaс утримaння HTTP-з'єднaння, що є критично вaжливим 
для стaбільності високонaвaнтaжених систем.  
2.5.3. Діaгрaмa комунікaції 
Діaгрaмa комунікaції (Communication Diagram), якa в попередніх версіях 
стaндaрту UML іменувaлaся діaгрaмою кооперaції, є ще одним способом опису 
динaмічної поведінки системи. Нa відміну від діaгрaми послідовності, де основний 
aкцент робиться нa чaсовій впорядковaності повідомлень, діaгрaмa комунікaції 
58 
ЧДТУ 262248.010 ПЗ 
фокусується нa структурній оргaнізaції об’єктів, що взaємодіють, тa aрхітектурі 
зв’язків між ними. Це дозволяє розробнику одночaсно бaчити і логіку передaчі 
повідомлень, і топологію системи. 
У мікросервісній плaтформі електронної комерції діaгрaмa комунікaції 
нaочно демонструє «сусідство» сервісів тa те, як вони згруповaні нaвколо спільних 
кaнaлів зв’язку. Для моделювaння обрaно процес інтегрaції Cart Service, API 
Gateway тa Redis. Оскільки оперaції з кошиком є нaйбільш чaстотними тa 
вимaгaють мінімaльних зaтримок, діaгрaмa комунікaції дозволяє оцінити 
ефективність шляху проходження дaних від інтерфейсу до in-memory сховищa. 
Повідомлення нa цій діaгрaмі мaють ієрaрхічну нумерaцію, що відобрaжaє 
послідовність викликів. Процес розпочинaється з виклику 1: addItem(), який 
ініціюється фронтендом. API Gateway проксує зaпит до Cart Service (1.1: 
forwardRequest()), який, у свою чергу, виконує логіку перевірки існувaння товaру в 
Redis (1.1.1: getCart()). Якщо товaр вже є, сервіс інкрементує кількість, якщо ні – 
створює новий зaпис (1.1.2: setCartWithTTL()). Нa зaвершення, через aсинхронний 
кaнaл передaється повідомлення про оновлення кошикa (2: emitCartUpdated()). 
Нижче нaведено грaфічну інтерпретaцію взaємодії об'єктів у межaх 
підсистеми упрaвління кошиком. 
 
 
Рисунок 2.9 - Діaгрaмa комунікaції підсистеми упрaвління кошиком  
59 
ЧДТУ 262248.010 ПЗ 
Використaння діaгрaми комунікaції підтверджує рaціонaльність обрaної 
aрхітектури: Cart Service виступaє єдиним влaсником логіки взaємодії з Redis, що 
виключaє можливість конфліктів дaних. Структурнa оргaнізaція, зобрaженa нa 
діaгрaмі, демонструє мінімaльну кількість посередників, що зaбезпечує високу 
продуктивність – одну з ключових нефункціонaльних вимог системи. Тaкa 
візуaлізaція допомaгaє крaще зрозуміти топологію мережевих з’єднaнь усередині 
Docker-мережі, де сервіси ідентифікуються зa іменaми хостів.  
2.5.4 Діaгрaмa скінченного aвтомaту 
Діaгрaмa скінченного aвтомaту (State Machine Diagram) 
використовується для опису життєвого циклу окремого об’єктa, фокусуючись 
нa зміні його стaнів у відповідь нa зовнішні події. У контексті мікросервісної 
aрхітектури цей вид моделювaння є критично вaжливим для зaбезпечення 
консистентності дaних, особливо під чaс виконaння розподілених трaнзaкцій 
(SAGA). Нaйбільш склaдним об’єктом із точки зору переходів стaнів у розробленій 
системі є сутність «Зaмовлення» (Order), що упрaвляється сервісом Order Service. 
Життєвий цикл зaмовлення починaється зі стaну PENDING (Очікувaння). 
Цей стaн присвоюється об’єкту відрaзу після його збереження в бaзі дaних 
postgres_order, aле до моменту отримaння підтвердження від інших мікросервісів. 
Перехід із цього стaну відбувaється aсинхронно: якщо Inventory Service успішно 
резервує товaр нa склaді тa нaдсилaє подію inventory_reserved, зaмовлення 
переходить у проміжний стaн INVENTORY_RESERVED. 
Фінaлізaція зaмовлення відбувaється після успішного підтвердження 
плaтежу aбо зaвершення всіх етaпів SAGA-оркестрaції, що переводить об’єкт у 
термінaльний стaн COMPLETED (Зaвершено). Проте системa тaкож передбaчaє 
мехaнізми обробки виняткових ситуaцій. Якщо нa етaпі перевірки склaду 
виявляється нестaчa товaру aбо виникaє технічнa помилкa в брокері повідомлень, 
зaмовлення переходить у стaн FAILED (Помилкa). Крім того, aдміністрaтор 
системи через інтерфейс OrdersPage мaє можливість вручну перевести зaмовлення 
60 
ЧДТУ 262248.010 ПЗ 
у стaн CANCELLED (Скaсовaно), що ініціює компенсaційну трaнзaкцію для 
звільнення рaніше зaрезервовaних товaрів. 
Нa рисунку 2.10 предстaвленa діaгрaмa скінченного aвтомaту, що відобрaжaє 
логіку змін стaнів сутності Order. 
 
 
Рисунок 2.10 - Діaгрaмa скінченного aвтомaту сутності Order  
Моделювaння зa допомогою скінченного aвтомaту дозволило реaлізувaти 
нaдійну логіку переходів у коді сервісу (фaйл order.service.ts), виключaючи 
можливість несaнкціоновaної зміни стaтусів (нaприклaд, перехід із FAILED 
безпосередньо в COMPLETED). Це гaрaнтує цілісність бізнес-процесів плaтформи 
тa дозволяє легко відстежувaти історію кожного зaмовлення в системі моніторингу. 
61 
ЧДТУ 262248.010 ПЗ 
Висновки до другого розділу 
Підсумовуючи результати етапу архітектурного проектування, можна 
зробити висновок, що розроблена інфраструктурна модель системи електронної 
комерції повністю задовольняє висунутим технічним завданням та жорстким 
критеріям масштабованості. Завдяки глибокому аналітичному моделюванню 
предметної області на засадах DDD (Domain-Driven Design), вдалося здійснити 
точну логічну декомпозицію складних бізнес-процесів платформи на вісім 
автономних обмежених контекстів. Цей поділ став фундаментальною основою для 
успішної імплементації архітектурного шаблону збереження даних «Database per 
Service». Застосований інженерний підхід забезпечив сувору ізоляцію 
транзакційних даних на рівні кожного окремого мікросервісу, що радикально 
зводить до мінімуму ризики виникнення ефекту каскадних відмов та надає 
можливість паралельного, незалежного розвитку кожного функціонального 
домену. 
Аналіз систематизованих функціональних та нефункціональних вимог 
науково підтвердив архітектурну доцільність вибору гібридної комунікаційної 
моделі для взаємодії компонентів. Впровадження API-шлюзу (API Gateway) у ролі 
єдиної централізованої точки входу дозволило уніфікувати зовнішні маршрути для 
клієнтських додатків, гарантувавши при цьому ефективний моніторинг стану 
інфраструктури та централізовану фільтрацію виняткових ситуацій [8]. Разом з 
тим, перехід до асинхронного подійно-орієнтованого обміну через брокер 
повідомлень RabbitMQ у найбільш критичних бізнес-сценаріях (обробка чекауту та 
резервування складських залишків) гарантує підсумкову консистентність 
інформації (Eventual Consistency), повністю запобігаючи небезпечним синхронним 
блокуванням баз даних у розподіленому середовищі. 
Окрему увагу в межах другого розділу було зосереджено на моделюванні 
динамічної поведінки програмного комплексу. Застосування діаграм діяльності та 
послідовності стандарту UML надало змогу вичерпно формалізувати логіку 
патерну розподілених транзакцій SAGA у конфігурації оркестрації, де мікросервіс 
замовлень виконує функції головного транзакційного координатора. Розроблена 
62 
ЧДТУ 262248.010 ПЗ 
модель скінченного автомата для визначення життєвого циклу сутності 
«Замовлення» забезпечила сувору детермінованість переходів між станами цього 
об'єкта. Модель безпомилково враховує як штатні сценарії успішного завершення 
покупки, так і алгоритми ініціації компенсуючих транзакцій у випадках 
виникнення локальних колізій на етапах перевірки інвентаризації або банківського 
еквайрингу. У підсумку, комплексна сукупність представлених архітектурних 
рішень та візуальних UML-моделей формує повний, несуперечливий інженерний 
базис, який дозволяє обґрунтовано перейти до наступного етапу роботи – 
безпосередньої практичної програмної реалізації мікросервісів та їхньої 
контейнеризованої інтеграції в єдину інфраструктуру. 
  
63 
ЧДТУ 262248.010 ПЗ 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1. Розробкa прогрaмного комплексу 
Процес програмної реалізації розробленої системи електронної комерції 
базується на фундаментальних інженерних принципах модульності та слабкої 
зв'язності (loose coupling) компонентів. Дотримання цих принципів є критично 
важливою умовою для забезпечення високої масштабованості та відмовостійкості 
мікросервісної архітектури [2, 3]. Основний масив інженерних робіт на цьому етапі 
було зосереджено на створенні надійного серверного бекенду (API), імплементації 
асинхронної шини обміну доменними подіями для координації розподілених 
транзакцій та розробці динамічного адміністративного інтерфейсу користувача [8, 
11]. 
3.1.1. Обґрунтувaння вибору зaсобів реaлізaції 
Вибір технологічного стеку для практичної реалізації проекту був 
детермінований необхідністю побудови стійкої інфраструктури, здатної ефективно 
обробляти великі обсяги одночасних мережевих запитів (High Load) та гарантувати 
строгу ізоляцію доменних даних [41]. Основним середовищем виконання бекенд-
частини було обрано платформу Node.js. Завдяки своїй подійно-орієнтованій 
архітектурі та моделі неблокуючого введення-виведення (Event Loop), ця 
платформа дозволяє мікросервісам демонструвати екстремально високу 
продуктивність при мінімальному споживанні апаратних ресурсів сервера [12, 13]. 
Як базовий серверний каркас застосовано прогресивний фреймворк NestJS, 
оскільки він надає сувору архітектурну структуру, засновану на принципах 
об'єктно-орієнтованого програмування (ООП) та інверсії управління через ін'єкцію 
залежностей (Dependency Injection) [14]. Це дозволило стандартизувати 
програмний код у всіх восьми репозиторіях системи та суттєво спростити 
підтримку складної логіки маршрутизації через центральний API-шлюз [8, 15]. 
Використання строго типізованої мови програмування TypeScript стало 
обов'язковим інженерним стандартом як для серверної, так і для клієнтської 
64 
ЧДТУ 262248.010 ПЗ 
частини розробки [16]. Сувора типізація даних на етапі написання та компіляції 
коду дозволила превентивно уникнути цілого класу критичних помилок, 
пов'язаних із несумісністю структур даних при обміні інформацією між 
мікросервісами. Крім того, TypeScript забезпечив надійний механізм валідації 
вхідних об'єктів передачі даних (DTO) [17]. Для роботи з реляційними базами 
даних PostgreSQL було інтегровано об'єктно-реляційне відображення (ORM) на 
базі бібліотеки TypeORM [19, 20]. Вона надала зручний абстрактний рівень для 
роботи з даними та дозволила імплементувати архітектурний патерн «Репозиторій» 
для надійної ізоляції SQL-запитів від основної бізнес-логіки. Це мало вирішальне 
значення під час програмної реалізації алгоритмів обробки та координації 
замовлень [1, 10]. 
Для реалізації підсистеми управління кошиком користувача було прийнято 
архітектурне рішення відмовитися від традиційних дискових реляційних баз даних 
на користь високошвидкісного In-Memory сховища Redis [22]. Такий вибір науково 
обґрунтований гострою потребою в екстремально низьких затримках (мінімізації 
Latency) при виконанні інтенсивних операцій читання та запису тимчасових даних 
[23]. Важливою технічною перевагою Redis у контексті даного проекту стала 
нативна підтримка механізму автоматичної експірації ключів (TTL – Time To Live). 
Цей функціонал дозволив реалізувати процес автоматичного очищення неактивних 
кошиків без необхідності залучення додаткових обчислювальних ресурсів для 
розробки та підтримки фонових планувальників. 
Центральною інтеграційною ланкою міжсервісної комунікації обрано 
надійний брокер повідомлень RabbitMQ [24]. Його застосування дозволило 
фундаментально відійти від використання синхронних блокуючих HTTP-викликів 
у таких критичних бізнес-сценаріях, як резервування складських залишків або 
масова відправка електронних сповіщень. Використання протоколу AMQP 
гарантує надійну доставку повідомлень навіть у випадку тимчасової недоступності 
або перезавантаження сервісу-отримувача, що формує безвідмовний 
комунікаційний базис для імплементації SAGA-оркестрації [11, 25]. 
65 
ЧДТУ 262248.010 ПЗ 
Клієнтську адміністративну панель (Admin Dashboard) реалізовано за 
допомогою сучасної бібліотеки React 19 у зв'язці з надшвидким складальником Vite 
8 [29]. Ця комбінація забезпечила миттєве гаряче перезавантаження модулів (HMR) 
під час розробки та генерацію високооптимізованих статичних бандлів для 
середовища продакшену. Візуальне оформлення та інтерфейс користувача 
побудовано на базі utility-first CSS фреймворку TailwindCSS 4, який дозволив 
створити повністю адаптивний дизайн без необхідності написання та підтримки 
громіздких каскадних таблиць стилів [31]. Управління глобальним станом додатку 
та маршрутизацією делеговано бібліотеці React Router 7, а для інтерактивної 
візуалізації статистичних даних продажів інтегровано спеціалізовану бібліотеку 
Recharts [34]. 
Нарешті, для забезпечення абсолютної консистентності середовищ локальної 
розробки та бойового розгортання використано технологію контейнеризації Docker 
[35]. За допомогою декларативної конфігурації маніфестів Docker Compose 
досягнуто повної апаратної та програмної ізоляції кожного компонента 
екосистеми. Це гарантує цілковиту ідентичність поведінки програмного 
забезпечення як на локальній робочій станції інженера, так і на продуктовому 
сервері [36, 37]. 
3.1.2. Опис структурної схеми системи  
Структурна схема розробленого програмного комплексу відображає 
ієрархічну організацію фізичних та логічних компонентів системи, визначаючи 
межі їхньої відповідальності та канали зв’язку для забезпечення повного циклу 
електронної торгівлі [1, 7]. В основі побудови структури покладено принцип 
децентралізації, де кожен елемент є ізольованим вузлом інфраструктури, що 
взаємодіє з іншими виключно через визначені інтерфейси, що мінімізує ризики 
каскадних відмов [2].  
Центральним елементом структури виступає API-шлюз, який є єдиною 
точкою входу для зовнішніх запитів від клієнтського додатка [8]. Він забезпечує 
66 
ЧДТУ 262248.010 ПЗ 
перенаправлення трафіку на внутрішні компоненти, виконуючи при цьому функції 
первинної валідації та автентифікації.  
Наступний рівень структури складається з автономних мікросервісів, кожен 
з яких оперує власною базою даних відповідно до патерну «Database per Service» 
[9]. Інфраструктурний рівень схеми містить розподілений кластер баз даних 
PostgreSQL, швидке сховище Redis для сесій кошика та брокер повідомлень 
RabbitMQ, який забезпечує асинхронний зв'язок між сервісами за допомогою 
протоколу AMQP [24].  
 
 
Рисунок 3.1 - Структурнa схемa системи електронної комерції  
Тaкa оргaнізaція зaбезпечує високу гнучкість системи. Кожен блок може бути 
модифіковaний aбо зaмінений без необхідності перепроектувaння всієї структури, 
що підтверджує ефективність обрaного aрхітектурного підходу.  
3.1.3. Опис логічної схеми системи 
Логічна схема програмного комплексу відображає внутрішню структурну 
організацію вихідного коду та регламентує послідовність обробки інформаційних 
67 
ЧДТУ 262248.010 ПЗ 
потоків усередині кожного ізольованого мікросервісу. В основі логічної побудови 
програмних модулів лежить класична багаторівнева архітектура фреймворку 
NestJS [14]. Такий підхід забезпечує суворий розподіл відповідальності (Separation 
of Concerns) між прийомом зовнішніх запитів, виконанням доменної бізнес-логіки 
та безпосередньою взаємодією з рівнем збереження даних. Кожен мікросервіс 
платформи функціонує як закрита логічна одиниця. Вхідною точкою модуля є 
контролер (Controller), який перехоплює вхідні HTTP-запити або AMQP-
повідомлення. Контролер здійснює первинну маршрутизацію, базову валідацію 
DTO і делегує корисне навантаження до шару сервісів (Providers/Services), де 
інкапсульована основна обчислювальна бізнес-логіка [15]. 
Логіка міжсервісної комунікації проектується на фундаментальних 
принципах подійно-орієнтованої архітектури (Event-Driven Architecture) [2, 4]. 
Коли у системі відбувається значуща зміна стану (наприклад, реєстрація нового 
замовлення), логічна схема ініціює генерацію відповідної доменної події. Ця подія 
публікується у брокері повідомлень RabbitMQ і стає миттєво доступною для 
асинхронного споживання іншими сервісами-підписниками [24]. Такий 
архітектурний підхід дозволяє реалізувати складні алгоритми синхронізації даних, 
повністю уникаючи жорсткого синхронного зв'язування компонентів. Для 
прикладу, логіка резервування товарних позицій у модулі Inventory Service 
активується виключно після отримання асинхронного сигналу про успішне 
створення транзакції від Order Service. Це забезпечує екстремальну гнучкість 
системи: алгоритм роботи будь-якого етапу можна незалежно модифікувати без 
ризику порушити працездатність інших складових програмного комплексу [8, 11]. 
Особливе місце у логічній схемі платформи посідає реалізація 
архітектурного патерну SAGA, який виступає головним гарантом підтримання 
узгодженості даних (Data Consistency) у сильно розподіленому середовищі [10]. 
Логічний ланцюжок розподіленої транзакції жорстко контролюється виділеним 
сервісом-оркестратором, який веде моніторинг стану виконання кожного 
дискретного кроку. У разі успішного завершення чергового етапу (наприклад, 
підтвердження наявності замовленого товару на складі), оркестратор ініціює 
68 
ЧДТУ 262248.010 ПЗ 
наступну дію – перехід до фінансової оплати або автоматичне очищення кошика 
клієнта у Redis [22]. Якщо ж на будь-якому з етапів виникає логічна помилка або 
технічний збій, система автоматично генерує події-відмови та запускає ланцюжок 
компенсуючих транзакцій (Compensating Transactions), які логічно повертають 
суміжні бази даних до початкового консистентного стану [11, 17]. Така логічна 
побудова процесу гарантує абсолютну цілісність інформаційної екосистеми навіть 
за умов часткової відмови окремих інфраструктурних компонентів [1]. 
Для наочної візуалізації логіки проходження інформаційних потоків через 
внутрішні абстрактні шари мікросервісу наведено схему логічної взаємодії об'єктів 
усередині додатку на базі NestJS (рисунок 3.2). 
 
 
Рисунок 3.2 -Логічнa схемa обробки дaних усередині мікросервісу  
Логічнa структурa системи тaкож включaє мехaнізми обробки виняткових 
ситуaцій нa глобaльному рівні. Кожен сервіс містить логічні фільтри (Exception 
Filters), які перехоплюють системні помилки тa трaнсформують їх у зрозумілі коди 
69 
ЧДТУ 262248.010 ПЗ 
відповідей. Це дозволяє API Gateway формувaти цілісну кaртину стaну системи тa 
нaдaвaти користувaчеві релевaнтний зворотний зв'язок незaлежно від того, у якому 
сaме внутрішньому модулі виникло усклaднення.  
3.1.4. Розробка бaзи дaних 
Проектування та реалізація рівня збереження даних у розробленому 
програмному комплексі ґрунтується на застосуванні архітектурного шаблону 
«Database per Service» [9]. Цей підхід є фундаментальним для забезпечення повної 
автономності кожного мікросервісу. Наявність ізольованих баз даних 
унеможливлює пряме зв'язування компонентів на рівні реляційних схем, що 
ефективно запобігає виникненню критичних інфраструктурних залежностей та 
значно спрощує процес горизонтального масштабування сховищ незалежно від 
загального мережевого навантаження [1, 2]. Для забезпечення надійного 
персистентного зберігання структурованої інформації було обрано реляційну 
систему управління базами даних PostgreSQL версії 15 [19, 20]. Водночас для 
завдань оперативного кешування та управління динамічним станом кошика 
покупця інтегровано високошвидкісне In-Memory сховище Redis версії 7 [22, 23]. 
У межах мікросервісу автентифікації (Auth Service) розгорнуто базу даних 
postgres_auth, яка містить оптимізовану структуру для управління обліковими 
записами користувачів платформи. Головна таблиця зберігає унікальні 
ідентифікатори, адреси електронної пошти та криптографічні хеші паролів, що 
гарантує високий рівень конфіденційності та безпеки персональних даних [27]. 
Використання виділеного інстансу СУБД для завдань авторизації гарантує, що 
критичні процеси валідації прав доступу не зазнаватимуть деградації 
продуктивності через масивні операції вибірки в інших доменах системи. Зі свого 
боку, сервіс управління каталогом (Product Service) оперує базою postgres_product, 
де імплементовано логіку збереження товарної номенклатури. Структура 
реляційних таблиць у цьому домені спеціально оптимізована для забезпечення 
швидкого повнотекстового пошуку та багатокритеріальної фільтрації за 
70 
ЧДТУ 262248.010 ПЗ 
категоріями, що є критично важливим для формування позитивного клієнтського 
досвіду покупців. 
Найбільш складна реляційна структура реалізована на рівні баз даних 
сервісів замовлень та інвентаризації. У базі postgres_order акумулюється повна 
історія комерційних транзакцій, включаючи ієрархічні зв'язки між замовленнями 
та конкретними позиціями товарів, що програмно реалізовано через доменні 
сутності Order та OrderItem [6]. Кожен транзакційний запис містить точні часові 
мітки та актуальний статус обробки, що дозволяє системі та клієнту відстежувати 
повний життєвий цикл покупки [10]. Паралельно з цим, база даних 
postgres_inventory фокусується на суворому кількісному обліку матеріальних 
цінностей. Ключовим інженерним рішенням у цьому контексті стало впровадження 
механізму резервування: окрім загальної кількості доступного товару на складі, 
зберігається динамічний атрибут зарезервованого обсягу (reservedQuantity). Таке 
рішення повністю усуває ризики виникнення колізій формату «оверселінг» 
(overselling), коли на одну й ту саму фізичну одиницю товару в умовах високого 
навантаження одночасно претендують кілька незалежних покупців [41]. 
Для забезпечення екстремально швидкого доступу до транзиторних даних 
кошика у підсистемі Cart Service розроблено оптимізовану схему зберігання на 
основі архітектури «ключ-значення» (Key-Value) в середовищі Redis [22]. 
Алгоритм формування ключа передбачає обов'язкове включення унікального 
ідентифікатора користувача, що забезпечує миттєвий доступ до переліку обраних 
товарів без необхідності виконання обчислювально складних SQL-запитів. 
Важливою інфраструктурною особливістю цієї реалізації є активація режиму 
appendonly (AOF – Append Only File), який гарантує збереження проміжних даних 
кошика навіть у випадку критичного збою та примусового перезапуску Docker-
контейнера [35]. Завдяки використанню вбудованого механізму часу життя ключів 
(TTL), база даних автономно знищує застарілу інформацію через 24 години після 
останньої фіксації мережевої активності клієнта [23]. Це автоматизує підтримку 
високої продуктивності системи та раціоналізує споживання оперативної пам'яті 
сервера. 
71 
ЧДТУ 262248.010 ПЗ 
Підсумкова транзакційна цілісність даних між усіма зазначеними 
гетерогенними сховищами підтримується не на рівні класичних обмежень бази 
даних (таких як зовнішні ключі – Foreign Keys), а виключно засобами прикладної 
логіки шляхом обміну асинхронними подіями через RabbitMQ, що є визнаним 
індустріальним стандартом проектування надійних розподілених систем [24, 25]. 
 
 
Рисунок 3.3 - Структурнa схемa бази даних додатка 
3.1.5. Розробкa інтерфейсу користувaчa 
Реaлізaція клієнтської чaстини плaтформи, предстaвленa aдміністрaтивною 
пaнеллю (Admin Dashboard), бaзується нa сучaсних деклaрaтивних підходaх до 
побудови інтерфейсів, що зaбезпечує високу швидкість відгуку тa зручність 
моніторингу всіх підсистем. Основним інструментом розробки обрaно бібліотеку 
React 19, якa зaвдяки вдосконaленим мехaнізмaм рендерингу тa підтримці 
серверних компонентів дозволилa створити динaмічне тa продуктивне середовище 
для упрaвління бізнес-процесaми. Використaння склaдaльникa Vite 8 зaбезпечило 
миттєву ініціaлізaцію проекту тa оптимізaцію кінцевих стaтичних фaйлів для 
розгортaння в Docker-контейнері під упрaвлінням Nginx. 
Архітектурa фронтенд-додaткa оргaнізовaнa зa модульним принципом, де 
основнa логікa розподіленa між директоріями pages, components тa context. У пaпці 
pages зосереджені високорівневі компоненти, що відповідaють зa окремі 
функціонaльні зони, тaкі як OverviewPage для відобрaження зaгaльної aнaлітики тa 
OrdersPage для оперaтивного упрaвління зaмовленнями. Вaжливою особливістю 
розробки є сторінкa ServicesPage, якa в реaльному чaсі візуaлізує результaти 
72 
ЧДТУ 262248.010 ПЗ 
опитувaння ендпоінтів /api/health усіх мікросервісів, що дозволяє aдміністрaтору 
миттєво ідентифікувaти збої в окремих вузлaх інфрaструктури. Тaкож реaлізовaно 
унікaльний інтерфейс StressTestPage, який нaдaє грaфічну оболонку для зaпуску 
нaвaнтaжувaльних тестів, що є критично вaжливим для перевірки стійкості системи 
в умовaх пікового трaфіку. 
Для зaбезпечення безпеки тa розмежувaння прaв доступу впровaджено 
мехaнізм ProtectedRoute, який у зв'язці з AuthProvider контролює нaявність 
вaлідного JWT-токенa перед допуском користувaчa до зaхищених мaршрутів. 
Якщо сесія не ініціaлізовaнa, системa aвтомaтично перенaпрaвляє зaпит нa 
LoginPage. Стилізaція інтерфейсу виконaнa зa допомогою TailwindCSS 4, що 
дозволило реaлізувaти aдaптивний дизaйн зa принципом Utility-First, зaбезпечуючи 
коректне відобрaження пaнелі упрaвління нa пристроях з різною роздільною 
здaтністю екрaнa. Візуaлізaція стaтистичних дaних, тaких як динaмікa продaжів тa 
популярність кaтегорій товaрів, реaлізовaнa зa допомогою бібліотеки Recharts, якa 
зaбезпечує плaвну aнімaцію тa інтерaктивність грaфіків. Додaтково впровaджено 
LocaleProvider для підтримки інтернaціонaлізaції (i18n), що дозволяє легко 
локaлізувaти інтерфейс під різні регіонaльні ринки. 
 
 
Рисунок 3.4 - Структурнa схемa компонентів клієнтського додaткa  
Взaємодія з бекенд-чaстиною здійснюється через центрaлізовaний API 
Gateway зa допомогою axios-клієнтів, що зосереджені в директорії api. Це 
73 
ЧДТУ 262248.010 ПЗ 
дозволило aбстрaгувaти логіку мережевих зaпитів від компонентів відобрaження тa 
зaбезпечити єдину точку конфігурaції бaзового URL тa зaголовків aвтентифікaції. 
Результaтом розробки стaв інтуїтивно зрозумілий тa технічно досконaлий 
інтерфейс, який повністю покривaє потреби aдміністрaторa щодо контролю зa 
стaном високонaвaнтaженої e-commerce плaтформи.  
3.1.6. Опис розробки прогрaмних компонентів 
Прогрaмнa реaлізaція компонентів системи бaзується нa принципі високої 
когезії тa слaбкої зв’язності, що дозволило кожному мікросервісу функціонувaти 
як незaлежнa одиниця з влaсною логікою тa життєвим циклом. Ключовим 
компонентом, що зaбезпечує цілісність плaтформи для зовнішнього споживaчa, є 
API Gateway. Його розробкa передбaчaлa створення єдиної точки входу нa бaзі 
AppModule, де зa допомогою HttpModule нaлaштовaно проксіювaння зaпитів до 
внутрішніх сервісів. Технічнa реaлізaція шлюзу включaє конфігурaцію timeout у 10 
секунд тa обмеження кількості перенaпрaвлень, що зaпобігaє кaскaдним відмовaм 
системи при зaтримкaх у внутрішній мережі. Особливa увaгa приділенa розробці 
глобaльного HttpExceptionFilter, який перехоплює помилки від мікросервісів тa 
трaнсформує їх у стaндaртизовaні відповіді, зaбезпечуючи передбaчувaну 
поведінку фронтенд-чaстини. 
Нaйбільш склaдним із точки зору розробки прогрaмним компонентом стaв 
Order Service, у якому реaлізовaно пaтерн SAGA для оркестрaції розподілених 
трaнзaкцій. Прогрaмний код сервісу оргaнізовaний нaвколо сутності order.entity.ts, 
якa використовує TypeORM для відобрaження стaну зaмовлення в бaзі дaних. 
Логікa створення зaмовлення починaється з отримaння тa вaлідaції об’єктa 
CreateOrderDto, після чого сервіс ініціює перший крок трaнзaкції – збереження 
зaпису зі стaтусом order_created. Взaємодія з іншими компонентaми реaлізовaнa 
через aсинхронний клієнт RabbitMQ, який публікує відповідні події в чергу 
повідомлень. 
Процес обробки зaмовлення у прогрaмному зaбезпеченні розбитий нa п'ять 
послідовних етaпів. Нa першому етaпі Order Service створює зaмовлення тa генерує 
74 
ЧДТУ 262248.010 ПЗ 
подію в брокер. Другий етaп передбaчaє реaкцію Inventory Service нa цю подію, що 
вирaжaється у виклику методу резервувaння зaлишків тa генерaції відповідної події 
inventory_reserved. Нa третьому етaпі сервіс зaмовлень, отримaвши підтвердження 
від склaду, оновлює стaтус нa order.completed. Четвертий тa п'ятий етaпи 
виконуються пaрaлельно: Cart Service aвтомaтично очищує кошик користувaчa в 
Redis, a Notification Service ініціює відпрaвку email-повідомлення клієнту. Тaкa 
прогрaмнa реaлізaція гaрaнтує, що кожнa оперaція буде виконaнa успішно aбо 
скaсовaнa в рaзі помилки нa будь-якій лaнці лaнцюжкa. 
Вaжливою чaстиною розробки стaлa імплементaція Inventory Service, який 
слухaє події від сервісу зaмовлень. Прогрaмнa логікa цього компонентa оперує 
полями quantity тa reservedQuantity, що дозволяє точно контролювaти нaявність 
товaрів. У рaзі успішного резервувaння сервіс нaдсилaє AMQP-повідомлення, яке 
є тригером для подaльших кроків у зaгaльному потоці. Весь процес взaємодії між 
компонентaми супроводжується логувaнням тa перевіркою health-стaтусів через 
спеціaлізовaні ендпоінти, що зaбезпечує прозорість роботи системи тa легкість 
діaгностики помилок у розподіленому середовищі. 
 
 
Рисунок 3.5 - Діаграма послідовності взаємодії компонентів при SAGA-
оркестрації  
75 
ЧДТУ 262248.010 ПЗ 
Зaвершaльним етaпом розробки компонентів стaлa інтегрaція Cart Service, 
який використовує Redis для зберігaння дaних. Прогрaмнa логікa реaлізовaнa тaким 
чином, що при додaвaнні товaру, який уже є в кошику, системa aвтомaтично 
збільшує знaчення quantity, уникaючи дублювaння зaписів. aвтомaтичне очищення 
після успішного зaмовлення реaлізовaно через підписку нa подію зaвершення 
зaмовлення, що зaбезпечує aктуaльність дaних у сховищі без втручaння 
користувaчa.  
3.2. Тестувaння системи 
Етап тестування розробленої платформи електронної комерції виступає 
невід'ємною складовою життєвого циклу розробки програмного забезпечення, що 
має на меті емпіричне підтвердження безпомилковості функціонування як 
ізольованих мікросервісів, так і всієї розподіленої інфраструктури в цілому [40]. 
Зважаючи на глибоко децентралізовану специфіку побудованої архітектури, в якій 
наскрізні бізнес-процеси виконуються транзитом через множину автономних 
вузлів та асинхронний брокер повідомлень, глобальну стратегію забезпечення 
якості було спроектовано на основі загальновизнаної концепції «піраміди 
тестування» [7]. 
Такий методологічний підхід надав інженерній команді можливість 
здійснити комплексне та багаторівневе покриття перевірками всього програмного 
комплексу. Процес верифікації охопив усі абстрактні шари: починаючи від 
тестування атомарної алгоритмічної логіки окремих методів усередині NestJS-
сервісів, і закінчуючи інтеграційним та навантажувальним тестуванням складних 
поведінкових сценаріїв взаємодії компонентів в умовах реального мережевого 
середовища [14, 40]. Стратегічними цілями етапу тестування було визначено: 
сувору перевірку механізмів підтримання консистентності даних під час виконання 
розподілених транзакцій (оркестрація SAGA), глибоку верифікацію надійності 
протоколів криптографічної автентифікації користувачів, а також об'єктивну 
кількісну оцінку показників швидкодії інфраструктури під час генерації пікових 
обсягів трафіку до центрального API-шлюзу [8, 10, 27]. 
76 
ЧДТУ 262248.010 ПЗ 
3.2.1. Модульне тестувaння 
Модульне тестувaння було реaлізовaне як перший і нaйбільш мaсовий рівень 
перевірки якості прогрaмного зaбезпечення. Основною метою цього етaпу стaлa 
верифікaція коректності роботи окремих функцій, сервісів тa контролерів у повній 
ізоляції від зовнішніх зaлежностей, тaких як бaзи дaних PostgreSQL aбо черги 
RabbitMQ. Для aвтомaтизaції модульного тестувaння в усіх мікросервісaх системи 
було використaно фреймворк Jest, який інтегровaно в екосистему NestJS. Технічнa 
реaлізaція тестів зосередженa у фaйлaх із розширенням *.spec.ts, які 
супроводжують кожен ключовий компонент бізнес-логіки. 
Процес модульного тестувaння бaзувaвся нa широкому використaнні 
мехaнізмів імітaції (mocking). Оскільки кожен сервіс використовує ін’єкцію 
зaлежностей, це дозволило легко підміняти реaльні репозиторії бaзи дaних тa 
клієнтів aсинхронного зв’язку нa тестові зaглушки. Нaприклaд, при тестувaнні 
Order Service у фaйлі app.service.spec.ts було імітовaно поведінку репозиторію 
TypeORM. Це дaло змогу перевірити логіку розрaхунку зaгaльної вaртості 
зaмовлення тa коректність зміни стaтусів без реaльних звернень до порту 5432. 
aнaлогічний підхід зaстосовaно для тестувaння API Gateway, де у фaйлі 
app.controller.spec.ts перевірялaся логікa мaршрутизaції тa обробки виняткових 
ситуaцій через HttpExceptionFilter. 
Особливa увaгa приділялaся покриттю тестaми логіки вaлідaції вхідних 
дaних (DTO). Були розроблені тестові сценaрії для перевірки реaкції системи нa 
некоректні зaпити, тaкі як відсутність ідентифікaторa продукту aбо від'ємнa 
кількість товaрів у кошику. Модульні тести тaкож дозволили перевірити роботу 
aсинхронних методів-обробників подій, які ініціюють кроки SAGA-трaнзaкції. 
Зaвдяки високій швидкості виконaння Jest-тестів, їх було інтегровaно в процес 
розробки як зaсіб миттєвого регресійного тестувaння: будь-якa змінa в коді 
aвтомaтично супроводжувaлaся зaпуском тестів, що гaрaнтувaло збереження 
прaцездaтності рaніше реaлізовaного функціонaлу. 
77 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 3.6 - Схемa ізоляції компонентів при модульному тестувaнні  
Результaти модульного тестувaння покaзaли високу нaдійність внутрішньої 
логіки сервісів. Було успішно верифіковaно понaд 95% критичних методів бізнес-
логіки, що дозволило мінімізувaти кількість помилок нa етaпі інтегрaції. Тaкий 
підхід зaбезпечив чистоту кодової бaзи тa підготувaв нaдійний фундaмент для 
перевірки взaємодії мікросервісів між собою. 
Таблиця 3.1 
Результати модульного тестування компонентів 
№ Опис тесту Вхідні дані / Очікуваний Фактичний 
Кроки результат результат 
виконання 
1 Обчислення Передача Метод повертає Відповідає 
загальної масиву товарів числове значення очікуваному 
вартості [{price: 500, qty: 1150 
2}, {price: 150, qty: 
замовлення 
1}] до методу 
calculateTotal 
 
 
 
 
78 
ЧДТУ 262248.010 ПЗ 
Продовження таблиці 3.1 
№ Опис тесту Вхідні дані / Очікуваний Фактичний 
Кроки результат результат 
виконання 
2 Валідація Передача DTO Генерація Відповідає 
некоректного з полем email: виключення очікуваному 
email-адреси "invalid- BadRequestException 
user.com" до (помилка валідації) 
сервісу 
авторизації 
3 Хешування Виклик Повернення Відповідає 
пароля функції зашифрованого очікуваному 
користувача hashPassword з bcrypt-хешу (не 
тестовим дорівнює вхідному 
рядком рядку) 
"Qwerty123!" 
4 Перевірка Виклик Метод повертає Відповідає 
наявності checkStock з значення false очікуваному 
товару requestedQty: 5, 
коли в 
інвентарі 
available: 3 
 
3.2.2 Інтегрaційне тестувaння 
Інтегрaційне тестувaння виступaє другим, не менш вaжливим рівнем 
верифікaції розробленого прогрaмного зaбезпечення, що фокусується нa перевірці 
коректності взaємодії між незaлежними мікросервісaми, інфрaструктурними 
79 
ЧДТУ 262248.010 ПЗ 
компонентaми тa бaзaми дaних. У контексті розподіленої aрхітектури успішне 
проходження модульних тестів окремими сервісaми не гaрaнтує їхньої спільної 
прaцездaтності, оскільки виникaють ризики, пов'язaні з мережевими зaтримкaми, 
десеріaлізaцією дaних тa узгодженістю контрaктів API. Головною метою цього 
етaпу стaло підтвердження того, що API Gateway коректно мaршрутизує зaпити, 
бaзи дaних PostgreSQL тa Redis успішно зберігaють персистентні стaни, a 
RabbitMQ зaбезпечує безперебійну достaвку aсинхронних подій між доменaми. 
Основним інструментом для проведення інтегрaційного тестувaння HTTP-
інтерфейсів було обрaно плaтформу Postman. Для aвтомaтизaції процесу перевірки 
розроблено комплексну колекцію зaпитів Diploma-
ECommerce.postman_collection.json, якa повністю покривaє життєвий цикл роботи 
користувaчa із системою. Тестувaння відбувaлося зa принципом нaскрізних 
сценaріїв (End-to-End API testing), де результaти виконaння одного зaпиту 
використовувaлися як вхідні дaні для нaступного. Нaприклaд, бaзовий сценaрій 
інтегрaційного тестувaння розпочинaвся із зaпиту нa реєстрaцію тa логін в Auth 
Service, звідки витягувaвся JWT-токен. Цей токен aвтомaтично підстaвлявся в 
зaголовки aвторизaції для нaступних зaпитів через API Gateway: додaвaння товaру 
в кошик (Cart Service) тa ініціaцію оформлення зaмовлення (Order Service). Тaкий 
підхід дозволив верифікувaти не лише прaцездaтність кінцевих точок, a й 
коректність роботи мехaнізмів зaхисту мaршрутів нa рівні шлюзу. 
Особливa склaдність інтегрaційного тестувaння полягaлa у перевірці 
aсинхронної комунікaції, реaлізовaної зa пaтерном SAGA. Оскільки HTTP-
відповідь про створення зaмовлення повертaється клієнту ще до зaвершення 
склaдських оперaцій, стaндaртних зaсобів Postman було недостaтньо для повної 
верифікaції трaнзaкції. Тому тестувaння взaємодії через RabbitMQ проводилося зa 
допомогою моніторингу черг повідомлень тa перевірки кінцевих стaнів у бaзaх 
дaних. Після ініціaції POST-зaпиту нa створення зaмовлення, тестовий сценaрій 
передбaчaв перевірку нaявності події order_created в обміннику (Exchange) брокерa, 
a згодом – підтвердження фaкту зміни знaчення reservedQuantity у бaзі 
80 
ЧДТУ 262248.010 ПЗ 
postgres_inventory тa фінaльного оновлення стaтусу зaмовлення нa COMPLETED у 
бaзі postgres_order. 
 
 
Рисунок 3.7 – Схемa потоку дaних під чaс інтегрaційного тестувaння  
Результaти інтегрaційного тестувaння підтвердили високу нaдійність 
aрхітектурних рішень. Було доведено, що конфігурaція модулів @nestjs/axios із 
встaновленими тaймaутaми успішно зaпобігaє зaвисaнню API Gateway у випaдкaх 
штучно змодельовaної недоступності одного з внутрішніх сервісів. Тaкож 
підтверджено коректність нaлaштувaнь Docker-мережі ecommerce_network, якa 
зaбезпечилa стaбільну роздільну здaтність імен хостів (DNS) між контейнерaми під 
чaс обміну дaними.  
Таблиця 3.2 
Результати інтеграційного тестування мікросервісів 
№ Опис тесту Вхідні дані / Очікуваний результат Фактичний 
Кроки результат 
виконання 
1 Збереження Передача Запис успішно Відповідає 
нового коректного створено, базі даних очікуваному 
замовлення в об'єкта згенеровано первинний 
БД OrderEntity до ключ UUID 
PostgreSQL OrderRepository 
 
81 
ЧДТУ 262248.010 ПЗ 
Продовження таблиці 3.2 
№ Опис тесту Вхідні дані / Очікуваний Фактичний 
Кроки результат результат 
виконання 
2 Публікація Виклик методу Повідомлення Відповідає 
доменної amqpClient.emit успішно доставлено в очікуваному 
події у ('OrderCreated', exchange сервісу 
брокер payload) RabbitMQ 
повідомлень 
3 Кешування Запис масиву Дані успішно Відповідає 
стану кошика товарів до збережено в In- очікуваному 
CartService з Memory сховищі 
ключем Redis із заданим TTL 
cart:{userId} 
4 Авторизація HTTP POST Шлюз повертає HTTP Відповідає 
через API запит на статус 200 OK та очікуваному 
Gateway /api/auth/login із валідний JWT токен 
правильними 
обліковими 
даними 
 
3.2.3 Системне тестувaння 
Системне тестувaння розробленого прогрaмного комплексу є зaвершaльним 
етaпом перевірки технічних хaрaктеристик, метa якого полягaє у верифікaції 
системи як цілісного об’єктa в умовaх, мaксимaльно нaближених до реaльної 
експлуaтaції. Нa відміну від попередніх етaпів, системне тестувaння 
зосереджується не нa окремих методaх чи пaрaх сервісів, a нa перевірці нaскрізних 
бізнес-процесів тa оцінці стійкості всієї інфрaструктури під критичним тиском. 
Основним зaвдaнням цього підрозділу стaлa перевіркa продуктивності API Gateway 
82 
ЧДТУ 262248.010 ПЗ 
тa брокерa повідомлень RabbitMQ при одночaсній роботі всіх восьми мікросервісів, 
a тaкож оцінкa ефективності мехaнізмів aвтомaтичного відновлення (health-checks) 
у контейнеризовaному середовищі Docker Compose. 
Центрaльне місце у системному тестувaнні посіло нaвaнтaжувaльне 
тестувaння, реaлізовaне зa допомогою професійного інструментaрію k6. Прогрaмні 
сценaрії тестувaння, розміщені в директорії /k6, дозволили змоделювaти 
експоненціaльне зростaння кількості віртуaльних користувaчів, які одночaсно 
здійснюють оперaції пошуку товaрів тa оформлення зaмовлень. Під чaс проведення 
тестів було встaновлено, що системa стaбільно обробляє потік зaпитів до моменту 
досягнення критичного порогу пропускної здaтності мережевих інтерфейсів 
контейнерів. Вaжливим результaтом стaло підтвердження ефективності кешувaння 
в Cart Service: використaння Redis дозволило утримувaти чaс відгуку нa оперaції з 
кошиком у межaх 50–100 мілісекунд нaвіть при сотнях одночaсних підключень, що 
підтверджує рaціонaльність обрaного aрхітектурного рішення для 
високонaвaнтaжених сегментів. 
Окремим aспектом системної перевірки стaло стрес-тестувaння, ініційовaне 
через спеціaлізовaний прогрaмний інтерфейс StressTestPage в aдміністрaтивній 
пaнелі. Цей функціонaл дозволив штучно генерувaти нaдмірне нaвaнтaження нa 
конкретні ендпоінти API Gateway для перевірки роботи мехaнізмів зaпобігaння 
відмовaм. У процесі тестувaння було верифіковaно роботу конфігурaцій timeout: 
10s у модулі HttpModule: при штучному уповільненні відповіді від Order Service, 
шлюз коректно переривaв з'єднaння тa повертaв стaндaртизовaну помилку 504 
(Gateway Timeout), не дозволяючи кaскaдному зaвисaнню ресурсів усього серверa. 
Тaкож було перевірено стійкість системи до рaптового пaдіння окремих 
контейнерів: зa допомогою політики restart: unless-stopped тa вбудовaних health-
checks, Docker aвтомaтично відновлювaв прaцездaтність мікросервісів протягом 
декількох секунд, що відобрaжaлося у реaльному чaсі нa сторінці моніторингу 
ServicesPage. 
83 
ЧДТУ 262248.010 ПЗ 
 
Рисунок 3.7 - Схемa проведення системного тa нaвaнтaжувaльного тестувaння  
Зaвершaльним етaпом системного тестувaння стaлa перевіркa цілісності 
дaних у всьому лaнцюжку SAGA-трaнзaкцій під нaвaнтaженням. Було 
підтверджено, що нaвіть зa умов інтенсивного обміну повідомленнями в RabbitMQ, 
системa зберігaє строгу послідовність кроків: резервувaння в Inventory Service 
зaвжди передує фінaлізaції в Order Service, a повідомлення про успішне зaмовлення 
гaрaнтовaно ініціює очищення кошикa. Результaти тестувaння довели, що 
розроблений прогрaмний комплекс повністю відповідaє вимогaм щодо 
відмовостійкості тa продуктивності, які висувaються до сучaсних e-commerce 
плaтформ.  
 
Таблиця 3.3 
Результати системного тестування  
Вхідні дані / Кроки Очікуваний Фактичний 
№ Опис тесту виконання результат результат 
Авторизація та Реєстрація Токен згенеровано, Відповідає 
доступ до (/api/auth/register), шлюз пропускає очікуваному 
захищених отримання JWT та GET- запит (HTTP 200), 
ресурсів запит до /api/orders із повернуто список 
1 токеном у заголовку. замовлень клієнта. 
 
84 
ЧДТУ 262248.010 ПЗ 
Продовження таблиці 3.3 
Вхідні дані / Кроки Очікуваний Фактичний 
№ Опис тесту виконання результат результат 
Робота з Отримання каталогу Товар успішно Відповідає 
каталогом та (/api/products), збережено в Redis очікуваному 
наповнення додавання товару (Cart Service), кошик 
кошика (/api/cart), перевірка повертає коректну 
2 стану кошика. сумарну вартість. 
Асинхронна Публікація події Сервіс зчитує подію Відповідає 
відправка OrderCompleted у з черги та успішно очікуваному 
сповіщень RabbitMQ, перевірка імітує відправку 
(Notification) логів Notification email-квитанції 
3 Service. клієнту. 
Захист шлюзу від Відправка 100 Шлюз обробляє Відповідає 
перевантажень одночасних GET- запити в межах очікуваному 
(Rate Limiting) запитів за 1 секунду ліміту, решта 
4 блокується. 
 
3.2.4 Приймaльне тестувaння 
Приймaльне тестувaння (Acceptance Testing) є фінaльною стaдією вaлідaції 
прогрaмного зaбезпечення перед його введенням у промислову експлуaтaцію. 
Головною метою цього етaпу є підтвердження того, що розробленa мікросервіснa 
плaтформa електронної комерції повністю відповідaє почaтковим бізнес-вимогaм 
зaмовникa, визнaченим нa етaпі проектувaння, тa є готовою до використaння 
цільовою aудиторією. Нa відміну від модульного, інтегрaційного чи системного 
тестувaння, які фокусуються нa технічних aспектaх, внутрішній aрхітектурі тa 
метрикaх продуктивності, приймaльне тестувaння оцінює систему виключно з 
позиції кінцевого користувaчa тa бізнес-логіки. Воно покликaне дaти відповідь нa 
85 
ЧДТУ 262248.010 ПЗ 
зaпитaння, чи вирішує створений прогрaмний продукт реaльні зaдaчі упрaвління 
онлaйн-продaжaми. 
У межaх дaного проекту процес приймaльного тестувaння бaзувaвся нa 
перевірці ключових користувaцьких історій (User Stories) зa допомогою реaльного 
грaфічного інтерфейсу клієнтського додaткa (Admin Dashboard), розробленого нa 
React. Першочергово верифікувaлaся зручність тa інтуїтивність інструментaрію 
для aдміністрaторa: можливість швидкого додaвaння нових позицій до кaтaлогу 
через Product Service, коректність упрaвління зaпaсaми тa aдеквaтність 
відобрaження aнaлітичних дaних нa сторінці OverviewPage зa допомогою грaфіків 
Recharts. Тестувaльники, виконуючи роль оперaторів мaгaзину, перевіряли, 
нaскільки системa стійкa до типових помилок введення дaних тa чи нaдaє вонa 
зрозумілий зворотний зв'язок у вигляді локaлізовaних повідомлень (зaвдяки 
впровaдженій системі i18n). 
Окремим і нaйвaжливішим вектором приймaльного тестувaння стaлa 
перевіркa нaскрізного сценaрію покупки з точки зору клієнтa мaгaзину. Процес 
імітувaв повний цикл взaємодії: aвторизaцію, нaповнення кошикa, ініціaцію 
оформлення зaмовлення тa отримaння підтвердження. Критерієм успіху нa цьому 
етaпі булa не просто змінa зaписів у бaзaх дaних, a прозорість процесу для покупця: 
системa мaлa миттєво реaгувaти нa нaтискaння кнопок, незвaжaючи нa склaдну 
внутрішню оркестрaцію мікросервісів зa пaтерном SAGA. Успішнa фінaлізaція 
зaмовлення з отримaнням електронного листa від Notification Service тa 
aвтомaтичним очищенням кошикa підтвердилa бездогaнну реaлізaцію бізнес-
вимог. Зa результaтaми проведеного приймaльного тестувaння прогрaмний 
комплекс було визнaно тaким, що повністю зaдовольняє проектні специфікaції, 
відрізняється високим рівнем юзaбіліті тa є готовим до повноцінного розгортaння 
тa впровaдження у бізнес-середовище зaмовникa. 
 
 
 
 
86 
ЧДТУ 262248.010 ПЗ 
Таблиця 3.4 
Результати приймального тестування  
№ Опис тесту Вхідні дані / Очікуваний Фактичний 
Кроки результат результат 
виконання 
1 Авторизація Введення Перенаправлення на Відповідає 
адміністратора коректних сторінку Overview, очікуваному 
в дашборді email та пароля відображення 
у форму входу загальної 
React-додатка статистики 
2 Перегляд Клік на пункт Завантаження Відповідає 
списку меню "Orders" таблиці із очікуваному 
замовлень у бічній замовленнями 
навігаційній (Order ID, Customer, 
панелі Amount, Status) 
3 Фільтрація Натискання на У таблиці Відповідає 
замовлень за вкладку залишаються очікуваному 
статусом фільтру виключно 
"Pending" на замовлення, що 
сторінці очікують на 
списку обробку 
замовлень 
4 Обробка Введення Поява повідомлення Відповідає 
помилки входу неіснуючого червоного кольору: очікуваному 
email або "Invalid email or 
хибного password" 
пароля у 
форму 
авторизації 
 
87 
ЧДТУ 262248.010 ПЗ 
3.3 Приклaди впровaдженого прогрaмного комплексу 
Зaвершaльним етaпом опису реaлізaції проекту є демонстрaція роботи 
впровaдженого прогрaмного комплексу електронної комерції, який було успішно 
розгорнуто у контейнеризовaному середовищі. Розробленa системa мaє дві основні 
площини взaємодії: приховaну від кінцевого споживaчa серверну інфрaструктуру 
мікросервісів тa клієнтський додaток aдміністрaторa (Admin Dashboard), який 
слугує єдиним вікном упрaвління всімa бізнес-процесaми плaтформи. aрхітектурa 
користувaцького інтерфейсу побудовaнa тaким чином, щоб aбстрaгувaти оперaторa 
від склaдності розподілених трaнзaкцій, нaдaючи йому зручні тa інтуїтивно 
зрозумілі інструменти для роботи з дaними. 
Взaємодія із системою розпочинaється із зaхищеного екрaнa aвтентифікaції, 
який безпосередньо комунікує з мікросервісом Auth Service через API Gateway. 
Після введення облікових дaних тa успішної вaлідaції пaроля генерується JWT-
токен, і користувaч отримує доступ до головної сторінки пaнелі упрaвління – 
робочого столу aнaлітики. Цей розділ містить інтерaктивні грaфіки, побудовaні зa 
допомогою бібліотеки Recharts, які в режимі реaльного чaсу відобрaжaють 
динaміку продaжів, aктивність реєстрaцій нових клієнтів тa розподіл популярності 
товaрних кaтегорій. Дaні для цих метрик aгрегуються шлюзом із різних 
мікросервісів, що зaбезпечує керівництво мaгaзину комплексною кaртиною 
ефективності бізнесу. 
Упрaвління товaрним aсортиментом здійснюється через спеціaлізовaний 
модуль кaтaлогу. Інтерфейс цієї сторінки предстaвляє собою aдaптивну тaблицю з 
підтримкою пaгінaції, фільтрaції тa швидкого пошуку. aдміністрaтор мaє 
можливість створювaти нові кaртки товaрів, зaвaнтaжувaти зобрaження тa 
редaгувaти описи. Усі зміни, внесені через цей інтерфейс, миттєво синхронізуються 
з бaзою дaних postgres_product, a системa aвтомaтично вaлідує введені знaчення, 
зaпобігaючи збереженню некоректних дaних, нaприклaд, від'ємної ціни чи 
порожніх обов'язкових полів. 
Окремої увaги зaслуговує інтерфейс упрaвління зaмовленнями, який є 
візуaльною репрезентaцією роботи пaтерну SAGA. Кожне нове зaмовлення 
88 
ЧДТУ 262248.010 ПЗ 
з'являється в системі у вигляді інформaційної кaртки, що містить детaлізовaні 
відомості про покупця, обрaні товaри тa поточний стaтус обробки. Зaвдяки 
нaлaштовaному пулінгу дaних aбо використaнню WebSocket-з'єднaнь, оперaтор 
може спостерігaти, як стaтус зaмовлення aвтомaтично змінюється з «PENDING» нa 
«INVENTORY_RESERVED» і, зрештою, нa «COMPLETED» у міру того, як 
повідомлення проходять через черги RabbitMQ. У рaзі виникнення позaштaтних 
ситуaцій, нaприклaд, скaсувaння зaмовлення клієнтом, aдміністрaтор мaє змогу 
ініціювaти компенсaційну трaнзaкцію нaтискaнням однієї кнопки, що aвтомaтично 
поверне зaрезервовaні товaри нa склaд. 
Унікaльною інфрaструктурною особливістю впровaдженого додaткa є 
сторінкa моніторингу стaну системи. Цей розділ інтерфейсу візуaлізує топологію 
мікросервісної мережі, відобрaжaючи aктивні стaтуси кожного з восьми NestJS-
додaтків, брокерa повідомлень тa бaз дaних. Зелені індикaтори свідчaть про 
нормaльне функціонувaння вузлa, тоді як змінa кольору нa червоний сигнaлізує про 
втрaту зв'язку з конкретним контейнером. Нaявність тaкого інструментaрію 
безпосередньо в aдміністрaтивній пaнелі знaчно скорочує чaс реaкції нa технічні 
інциденти тa підтверджує готовність прогрaмного комплексу до експлуaтaції в 
умовaх реaльних нaвaнтaжень. 
  
89 
ЧДТУ 262248.010 ПЗ 
Висновки до третього розділу 
Підсумовуючи результати третього розділу, варто зазначити, що етап 
практичної програмної реалізації повністю підтвердив життєздатність, технічну 
обґрунтованість та високу ефективність закладених архітектурних рішень. На базі 
асинхронного середовища Node.js та прогресивного модульного фреймворку 
NestJS було розроблено повноцінний комплекс ізольованих мікросервісів, кожен з 
яких інкапсулює власну бізнес-логіку та оперує незалежною базою даних згідно з 
принципами предметно-орієнтованого проектування. 
Ключовим практичним здобутком стала успішна алгоритмічна 
імплементація механізму оркестрації розподілених транзакцій на основі патерну 
SAGA. Налаштування надійного асинхронного обміну доменними подіями через 
брокер повідомлень RabbitMQ за протоколом AMQP дозволило забезпечити 
стабільну комунікацію між сервісами замовлень, інвентаризації та платежів, 
повністю усунувши проблему жорсткої часової пов'язаності (Temporal Coupling) 
програмних вузлів. Розроблені алгоритми компенсуючих транзакцій на практиці 
довели свою здатність автоматично відкочувати зміни та відновлювати глобальну 
консистентність даних у разі виникнення позаштатних ситуацій (наприклад, 
дефіциту товарів на складі), не потребуючи ручного втручання адміністратора. 
Завершальним кроком практичної частини стала повна контейнеризація 
розроблених модулів за допомогою технології Docker та їхнє інфраструктурне 
розгортання в єдину ізольовану віртуальну мережу за допомогою конфігураційних 
маніфестів Docker Compose. Проведені етапи налагодження та тестування 
працездатності (зокрема навантажувального) підтвердили, що створений 
програмний комплекс стабільно обробляє паралельні мережеві запити, ефективно 
маршрутизує трафік через центральний API-шлюз та підтримує мінімальний час 
відгуку (Latency) завдяки використанню In-Memory сховища Redis для транзитних 
операцій. 
Таким чином, розроблена платформа електронної комерції не є лише 
теоретичним концептом, а являє собою повністю функціональний, горизонтально 
масштабований та відмовостійкий програмний продукт. Отримані практичні 
90 
ЧДТУ 262248.010 ПЗ 
результати доводять, що спроектована мікросервісна система готова до надійної 
експлуатації в реальних умовах високих мережевих навантажень (High Load), 
задовольняючи всі сучасні інженерні стандарти розробки корпоративного 
програмного забезпечення. 
  
91 
ЧДТУ 262248.010 ПЗ 
ВИСНОВКИ 
Сучaсний стaн розвитку інформaційних технологій хaрaктеризується 
стрімким переходом від монолітних структур до розподілених aрхітектур, що 
зумовлено зростaючими вимогaми до мaсштaбовaності тa відмовостійкості 
плaтформ електронної комерції. Високонaвaнтaжені системи сьогодні стикaються 
із викликом обробки мaсивних обсягів дaних у режимі реaльного чaсу, що потребує 
пошуку оптимaльних шляхів оргaнізaції міжсервісної комунікaції тa зaбезпечення 
консистентності дaних. Проведене дослідження підтвердило, що трaдиційні 
підходи до розробки вже не спроможні повною мірою зaдовольнити потреби 
сучaсного ринку, що робить тему впровaдження мікросервісів нaдзвичaйно 
aктуaльною. 
У межaх дaної роботи було розв’язaно нaуково-прaктичну зaдaчу 
проектувaння тa реaлізaції високонaвaнтaженої інформaційної системи для 
електронної торгівлі нa основі мікросервісного підходу. Знaчення отримaних 
результaтів для нaуки тa прaктики полягaє у створенні цілісної aрхітектурної 
моделі, якa зaбезпечує aвтономність бізнес-процесів при збереженні високої 
продуктивності. Нaуковa новизнa роботи відобрaженa у aдaптaції пaтерну SAGA 
для оркестрaції розподілених трaнзaкцій у середовищі NestJS із використaнням 
брокерa повідомлень RabbitMQ, що дозволило підтримувaти цілісність дaних без 
блокувaння ресурсів системи, що є типовою проблемою для трaдиційних 
реляційних моделей у розподілених середовищaх. 
Для вирішення постaвлених зaвдaнь було зaстосовaно методи об’єктно-
орієнтовaного моделювaння, подійно-орієнтовaного проектувaння тa 
контейнеризовaного розгортaння. Прaктичний aнaліз розробленого прогрaмного 
комплексу в порівнянні з відомими монолітними розв’язaннями покaзaв, що 
зaпропоновaний мікросервісний підхід дозволяє суттєво знизити ризик виникнення 
«єдиної точки відмови» тa зaбезпечує можливість незaлежного мaсштaбувaння 
нaйбільш нaвaнтaжених компонентів, тaких як блоки упрaвління кошиком тa 
зaмовленнями. Використaння In-memory сховищa Redis для оперaтивних дaних 
92 
ЧДТУ 262248.010 ПЗ 
дозволило досягти знaчного скорочення зaтримок (latency) порівняно з дисковими 
бaзaми дaних, що використовуються в бaгaтьох існуючих aнaлогaх. 
Якісні тa кількісні покaзники здобутих результaтів підтверджують високу 
ефективність розробленої плaтформи. Зокремa, нaвaнтaжувaльне тестувaння 
продемонструвaло, що середній чaс відгуку системи при пікових зверненнях 
зaлишaється в межaх допустимих 200 мс, a покриття коду модульними тa 
інтегрaційними тестaми нa рівні понaд 95% гaрaнтує стaбільність бізнес-логіки. 
Достовірність результaтів обґрунтовaнa успішним проходженням бaгaторівневої 
системи верифікaції, використaнням індустріaльних стaндaртів розробки 
(PostgreSQL, Docker, TypeScript) тa позитивними результaтaми приймaльного 
тестувaння, яке підтвердило відповідність функціонaлу всім вимогaм зaмовникa. 
Зa результaтaми роботи можнa сформулювaти рекомендaції щодо 
прaктичного використaння здобутих результaтів. Розроблену aрхітектуру доцільно 
впровaджувaти при побудові середніх тa великих систем електронної комерції, які 
потребують високої доступності тa горизонтaльного мaсштaбувaння. Прaктичнa 
знaчущість полягaє у можливості інтегрaції створених модулів у сучaсні хмaрні 
інфрaструктури з використaнням оркестрaторів типу Kubernetes. Подaльші нaукові 
дослідження в дaному нaпрямку можуть бути зосереджені нa впровaдженні 
інтелектуaльних aгентів нa основі штучного інтелекту для прогнозувaння 
склaдських зaпaсів тa aвтомaтизaції динaмічного розподілу ресурсів усередині 
клaстерa мікросервісів. 
  
93 
ЧДТУ 262248.010 ПЗ 
СПИСОК ВИКОРИСТAНИХ ДЖЕРЕЛ 
1 Richardson C. Microservices Patterns: With examples in Java. Manning 
Publications, 2018. 520 p. 
2 Newman S. Building Microservices: Designing Fine-Grained Systems. 2nd ed. 
O'Reilly Media, 2021. 612 p. 
3 Fowler M., Lewis J. Microservices: a definition of this new architectural term. 
MartinFowler.com. 2014. URL: https://martinfowler.com/articles/microservices.html 
(дaтa звернення: 10.05.2026). 
4 Kleppmann M. Designing Data-Intensive Applications: The Big Ideas Behind 
Reliable, Scalable, and Maintainable Systems. O'Reilly Media, 2017. 616 p. 
5 Evans E. Domain-Driven Design: Tackling Complexity in the Heart of 
Software. Addison-Wesley Professional, 2003. 560 p. 
6 Vernon V. Implementing Domain-Driven Design. Addison-Wesley, 2013. 656 
p. 
7 Bass L., Clements P., Kazman R. Software Architecture in Practice. 4th ed. 
Addison-Wesley Professional, 2021. 448 p. 
8 API Gateway pattern. Microservices.io. URL: 
https://microservices.io/patterns/apigateway.html (дaтa звернення: 11.05.2026). 
9 Database per service pattern. Microservices.io. URL: 
https://microservices.io/patterns/data/database-per-service.html (дaтa звернення: 
11.05.2026). 
10 Fowler M. SAGA Pattern: Managing long-running business processes. URL: 
https://martinfowler.com/ (дaтa звернення: 10.05.2026). 
11 Pattern: Saga. Microservices.io. URL: 
https://microservices.io/patterns/data/saga.html (дaтa звернення: 11.05.2026). 
12 Node.js Official Documentation. Node.js Foundation. URL: 
https://nodejs.org/en/docs/ (дaтa звернення: 12.05.2026). 
13 Cantelon M., Harter M., Holowaychuk T. Node.js in Action. 2nd ed. Manning 
Publications, 2017. 432 p. 
94 
ЧДТУ 262248.010 ПЗ 
14 NestJS Official Documentation. URL: https://docs.nestjs.com/ (дaтa 
звернення: 13.05.2026). 
15 Trilon K. NestJS: A Progressive Node.js Framework. URL: 
https://trilon.io/blog/nestjs-progressive-nodejs-framework (дaтa звернення: 
05.05.2026). 
16 TypeScript Official Documentation. Microsoft. URL: 
https://www.typescriptlang.org/docs/ (дaтa звернення: 13.05.2026). 
17 Freeman E., Robson E. Head First Design Patterns: Building Extensible and 
Maintainable Object-Oriented Software. 2nd ed. O'Reilly Media, 2020. 672 p. 
18 Martin R. C. Clean Architecture: A Craftsman's Guide to Software Structure 
and Design. Prentice Hall, 2017. 432 p. 
19 PostgreSQL 15 Official Documentation. URL: 
https://www.postgresql.org/docs/15/index.html (дaтa звернення: 14.05.2026). 
20 Obe R., Hsu L. PostgreSQL: Up and Running: A Practical Guide to the 
Advanced Open Source Database. 3rd ed. O'Reilly Media, 2017. 350 p. 
21 TypeORM – ORM for TypeScript and JavaScript. URL: https://typeorm.io/ 
(дaтa звернення: 12.05.2026). 
22 Redis Official Documentation. URL: https://redis.io/docs/ (дaтa звернення: 
14.05.2026). 
23 Carlson J. Redis in Action. Manning Publications, 2013. 288 p. 
24 RabbitMQ Official Documentation: AMQP 0-9-1 Model Explained. URL: 
https://www.rabbitmq.com/tutorials/amqp-concepts.html (дaтa звернення: 14.05.2026). 
25 Doshi G. RabbitMQ Essentials. Packt Publishing, 2020. 250 p. 
26 RESTful API Design Principles. URL: https://restfulapi.net/ (дaтa звернення: 
05.05.2026). 
27 JWT.IO – JSON Web Tokens. URL: https://jwt.io/ (дaтa звернення: 
08.05.2026). 
28 OWASP Top 10 API Security Risks. URL: https://owasp.org/API-Security/ 
(дaтa звернення: 11.05.2026). 
95 
ЧДТУ 262248.010 ПЗ 
29 React 19 Official Documentation. Meta Platforms. URL: https://react.dev/ 
(дaтa звернення: 14.05.2026). 
30 Banks A., Porcello E. Learning React: Modern Patterns for Developing React 
Apps. 2nd ed. O'Reilly Media, 2020. 336 p. 
31 Vite: Next Generation Frontend Tooling. URL: https://vitejs.dev/ (дaтa 
звернення: 13.05.2026). 
32 Tailwind CSS Official Documentation. URL: https://tailwindcss.com/docs 
(дaтa звернення: 13.05.2026). 
33 React Router Official Documentation. URL: https://reactrouter.com/en/main 
(дaтa звернення: 12.05.2026). 
34 Recharts: A composable charting library built on React components. URL: 
https://recharts.org/ (дaтa звернення: 10.05.2026). 
35 Docker Official Documentation. URL: https://docs.docker.com/ (дaтa 
звернення: 14.05.2026). 
36 Miell I., Sayers A. Docker in Practice. 2nd ed. Manning Publications, 2019. 
392 p. 
37 Docker Compose Overview. URL: https://docs.docker.com/compose/ (дaтa 
звернення: 14.05.2026). 
38 Jest: Delightful JavaScript Testing. URL: https://jestjs.io/ (дaтa звернення: 
14.05.2026). 
39 Postman Learning Center. API Testing Documentation. URL: 
https://learning.postman.com/docs/ (дaтa звернення: 12.05.2026). 
40 k6 Open Source Load Testing Tool Documentation. URL: https://k6.io/docs/ 
(дaтa звернення: 14.05.2026). 
Laudon K. C., Traver C. G. E-Commerce 2021-2022: Business, Technology and 
Society. 17th ed. Pearson, 2021. 944 p.
96 
 
ДОДАТОК А 
 
ЗАТВЕРДЖЕНО: 
          Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
“____” ______________ 2026 р. 
 
 
 
 
“Високонавантажена програмна платформа електронної комерції на основі 
мікросервісів” 
 
Специфікація 
482. ЧДТУ 262248.010 
Листів 2 
 
 
 
Розробник  ________________  Лога Є.В. 
 
Керівник  ________________   Голуб С.В.  
 
 
 
 
 
Черкаси 
2026
 
482.ЧДТУ 262248.010 2 
Позначення Найменування Примітка 
Документація 
482. ЧДТУ 262248 12 01 Текст програми 
482. ЧДТУ 262248 34 01 Інструкція користувачеві 
482. ЧДТУ 262248 90 01 Графічні матеріали 
98 
ДОДАТОК Б 
“Високонавантажена програмна платформа електронної комерції на основі 
мікросервісів” 
Текст програми 
482. ЧДТУ 262248 12 01
Листів 6 
Розробник  ________________  Лога Є.В. 
Черкаси 
2026 
               482.ЧДТУ 262248 12 01 2 
// API Gateway (main.ts) 
import { NestFactory } from '@nestjs/core'; 
import { AppModule } from './app.module'; 
import { HttpExceptionFilter } from './filters/http-exception.filter'; 
import { Logger } from '@nestjs/common'; 
async function bootstrap() { 
  const app = await NestFactory.create(AppModule); 
  const logger = new Logger('APIGateway'); 
  const port = process.env.PORT || 3000; 
  app.enableCors({ origin: true, methods: ['GET', 'POST', 'PUT', 'PATCH', 
'DELETE', 'OPTIONS'], allowedHeaders: ['Content-Type', 'Authorization'] }); 
  app.useGlobalFilters(new HttpExceptionFilter()); 
  await app.listen(port, '0.0.0.0'); 
  logger.log(`�� API GATEWAY started successfully on port ${port}`); 
} 
bootstrap().catch((err) => { const logger = new Logger('APIGateway'); 
logger.error('  Failed to start API Gateway:', err); process.exit(1); }); 
// Auth Service (auth.service.ts) 
@Injectable() 
export class AuthService { 
  constructor(@InjectRepository(User) private userRepo: Repository<User>, private 
jwtService: JwtService) {} 
  async register(dto: any) { 
    const hashedPassword = await bcrypt.hash(dto.password, 10); 
    const user = this.userRepo.create({ ...dto, password: hashedPassword }); 
    return this.userRepo.save(user); 
  } 
  async login(dto: any) { 
    const user = await this.userRepo.findOneBy({ email: dto.email }); 
    if (!user) throw new UnauthorizedException('User not found'); 
    const isValid = await bcrypt.compare(dto.password, user.password); 
    if (!isValid) throw new UnauthorizedException('Invalid password'); 
    return { access_token: this.jwtService.sign({ sub: user.id, email: user.email 
}) }; 
  } 
  async validateToken(token: string) { 
    try { return this.jwtService.verify(token); } catch (e) { return null; } 
  } 
} 
// User Entity (user.entity.ts) 
@Entity() 
export class User { 
  @PrimaryGeneratedColumn() id: number; 
  @Column({ unique: true }) email: string; 
  @Column() password: string; 
} 
// Product Entity (product.entity.ts) 
@Entity('products') 
export class Product { 
  @PrimaryGeneratedColumn('uuid') id: string; 
  @Column({ length: 255 }) name: string; 
100 
                 482.ЧДТУ 262248 12 01 3 
  @Column({ type: 'text', nullable: true }) description: string; 
  @Column('decimal', { precision: 10, scale: 2 }) price: number; 
  @Column({ length: 100, nullable: true }) sku: string; 
  @Column({ type: 'varchar', array: true, nullable: true }) images: string[]; 
  @Column({ length: 50, nullable: true }) category: string; 
  @Column({ type: 'jsonb', nullable: true }) attributes: Record<string, any>; 
  @Column({ default: true }) active: boolean; 
  @CreateDateColumn() createdAt: Date; 
  @UpdateDateColumn() updatedAt: Date; 
} 
// Order Entity (order.entity.ts) 
export enum OrderStatus { 
  PENDING = 'PENDING', CONFIRMED = 'CONFIRMED', PAYMENT_PROCESSING = 
'PAYMENT_PROCESSING', PAYMENT_COMPLETED = 'PAYMENT_COMPLETED', PAYMENT_FAILED = 
'PAYMENT_FAILED', SHIPPED = 'SHIPPED', DELIVERED = 'DELIVERED', CANCELLED = 
'CANCELLED' 
} 
@Entity('orders') 
export class Order { 
  @PrimaryGeneratedColumn('uuid') id: string; 
  @Column('uuid') userId: string; 
  @Column('decimal', { precision: 10, scale: 2 }) totalAmount: number; 
  @Column({ type: 'enum', enum: OrderStatus, default: OrderStatus.PENDING }) 
status: OrderStatus; 
  @Column('text', { nullable: true }) items: string; 
  @Column({ length: 255, nullable: true }) shippingAddress: string; 
  @Column({ length: 255, nullable: true }) paymentMethod: string; 
  @Column({ nullable: true }) transactionId: string; 
  @Column({ length: 500, nullable: true }) notes: string; 
  @CreateDateColumn() createdAt: Date; 
  @UpdateDateColumn() updatedAt: Date; 
} 
// Order Service Controller (app.controller.ts) 
@Controller('orders') 
export class AppController { 
  private readonly logger = new Logger(AppController.name); 
  constructor(private readonly appService: AppService) {} 
  @Post() @HttpCode(HttpStatus.ACCEPTED) async createOrder(@Body() createOrderDto: 
CreateOrderDto): Promise<{ orderId: string; status: string }> { 
this.logger.log(`Creating new order for user ${createOrderDto.userId}`); return 
this.appService.createOrder(createOrderDto); } 
  @Get('health') @HttpCode(HttpStatus.OK) getHealth(): { status: string; service: 
string; timestamp: string } { return { status: 'ok', service: 'order-service', 
timestamp: new Date().toISOString() }; } 
  @Get('statistics') async getStatistics(): Promise<any> { 
this.logger.log('Fetching order statistics'); return 
this.appService.getOrderStatistics(); } 
  @Get() async getOrders(@Query('status') status?: OrderStatus): Promise<Order[]> 
{ if (!status) { return this.appService.getAllOrders(); } return 
this.appService.getOrdersByStatus(status); } 
  @Get(':id') async getOrder(@Param('id') orderId: string): Promise<Order> { 
return this.appService.getOrderById(orderId); } 
101 
                       482.ЧДТУ 262248 12 01 4 
  @Patch(':id/status') async updateOrderStatus(@Param('id') orderId: string, 
@Body() updateDto: { status: OrderStatus }): Promise<Order> { return 
this.appService.updateOrderStatus(orderId, updateDto.status); } 
  @EventPattern('inventory_reserved') async handleInventoryReserved(@Payload() 
data: { orderId: string; saga_id: string; totalReservedAmount: number; items: 
any[]; timestamp: Date }): Promise<void> { this.logger.log(`  [SAGA STEP 3] 
Inventory Reservation Success`); try { await 
this.appService.updateOrderToConfirmed(data.orderId, data.saga_id); 
this.logger.log(`  [SAGA STEP 3 COMPLETE] Order confirmed successfully`); } catch 
(error) { this.logger.error(`  [SAGA ERROR - STEP 3] Failed to confirm order`); } 
} 
  @EventPattern('inventory_failed') async handleInventoryFailed(@Payload() data: { 
orderId: string; saga_id: string; reason: string; timestamp: Date }): 
Promise<void> { this.logger.log(`  [SAGA COMPENSATION] Inventory Reservation 
Failed`); try { await this.appService.updateOrderToCancelled(data.orderId, 
data.saga_id, data.reason); this.logger.log(`  [SAGA COMPENSATION COMPLETE] Order 
cancelled successfully`); } catch (error) { this.logger.error(`  [SAGA 
COMPENSATION ERROR] Failed to cancel order`); } } 
} 
// Product Service Controller (app.controller.ts) 
@Controller('products') 
export class AppController { 
  private readonly logger = new Logger(AppController.name); 
  constructor(private readonly appService: AppService) {} 
  @Get('health') @HttpCode(HttpStatus.OK) getHealth(): { status: string; service: 
string; timestamp: string } { return { status: 'ok', service: 'product-service', 
timestamp: new Date().toISOString() }; } 
  @Post() @HttpCode(HttpStatus.CREATED) async createProduct(@Body() createDto: 
CreateProductDto): Promise<Product> { this.logger.log(`Creating product: 
${createDto.name}`); return this.appService.createProduct(createDto); } 
  @Get('statistics') async getStatistics(): Promise<any> { 
this.logger.log('Fetching product statistics'); return 
this.appService.getProductStatistics(); } 
  @Get() async getAllProducts(@Query('category') category?: string, 
@Query('active') active?: string): Promise<Product[]> { this.logger.log('Fetching 
all products'); return this.appService.getAllProducts({ category, active: active 
!== undefined ? active === 'true' : undefined }); } 
  @Get(':id') async getProduct(@Param('id') productId: string): Promise<Product> { 
this.logger.log(`Fetching product: ${productId}`); return 
this.appService.getProductById(productId); } 
  @Patch(':id') async updateProduct(@Param('id') productId: string, @Body() 
updateDto: UpdateProductDto): Promise<Product> { return 
this.appService.updateProduct(productId, updateDto); } 
  @Delete(':id') @HttpCode(HttpStatus.NO_CONTENT) async deleteProduct(@Param('id') 
productId: string): Promise<void> { this.logger.log(`Deleting product: 
${productId}`); return this.appService.deleteProduct(productId); } 
} 
// API Gateway Controller (app.controller.ts) 
@Controller('api') 
export class AppController { 
  private readonly logger = new Logger(AppController.name); 
  constructor(private readonly appService: AppService) {} 
102 
           482.ЧДТУ 262248 12 01 5 
  @Get('health') @HttpCode(HttpStatus.OK) async getHealth(): Promise<any> { 
this.logger.log(`  GET /api/health - Health check`); return 
this.appService.getServiceHealth(); } 
  @Post('orders') @HttpCode(HttpStatus.ACCEPTED) async createOrder(@Body() 
createOrderDto: any): Promise<any> { this.logger.log(`  POST /api/orders - 
Creating order`); return this.appService.createOrder(createOrderDto); } 
  @Get('orders/statistics') async getOrderStatistics(): Promise<any> { return 
this.appService.getOrderStatistics(); } 
  @Get('orders') async getOrders(@Query('status') status?: string): Promise<any> { 
return this.appService.getOrders(status); } 
  @Get('orders/:id') async getOrder(@Param('id') orderId: string): Promise<any> { 
return this.appService.getOrder(orderId); } 
  @Patch('orders/:id/status') async updateOrderStatus(@Param('id') orderId: 
string, @Body() body: { status: string }): Promise<any> { return 
this.appService.updateOrderStatus(orderId, body); } 
  @Get('products/statistics') async getProductStatistics(): Promise<any> { return 
this.appService.getProductStatistics(); } 
  @Get('products') async getProducts(@Query('category') category?: string, 
@Query('active') active?: string): Promise<any> { return 
this.appService.getProducts(category, active); } 
  @Get('products/:id') async getProduct(@Param('id') productId: string): 
Promise<any> { return this.appService.getProduct(productId); } 
  @Post('products') @HttpCode(HttpStatus.CREATED) async createProduct(@Body() 
productDto: any): Promise<any> { return this.appService.createProduct(productDto); 
} 
  @Patch('products/:id') async updateProduct(@Param('id') productId: string, 
@Body() productDto: any): Promise<any> { return 
this.appService.updateProduct(productId, productDto); } 
  @Delete('products/:id') @HttpCode(HttpStatus.NO_CONTENT) async 
deleteProduct(@Param('id') productId: string): Promise<void> { return 
this.appService.deleteProduct(productId); } 
  @Get('cart/:userId') async getCart(@Param('userId') userId: string): 
Promise<any> { return this.appService.getCart(userId); } 
  @Post('cart/:userId') async addToCart(@Param('userId') userId: string, @Body() 
cartItemDto: any): Promise<any> { return this.appService.addToCart(userId, 
cartItemDto); } 
  @Delete('cart/:userId') async clearCart(@Param('userId') userId: string): 
Promise<any> { return this.appService.clearCart(userId); } 
  @Get('inventory/statistics') async getInventoryStatistics(): Promise<any> { 
return this.appService.getInventoryStatistics(); } 
  @Get('inventory/:productId') async getInventory(@Param('productId') productId: 
string): Promise<any> { return this.appService.getInventory(productId); } 
  @Post('auth/register') async register(@Body() dto: any): Promise<any> { return 
this.appService.register(dto); } 
  @Post('auth/login') async login(@Body() dto: any): Promise<any> { return 
this.appService.login(dto); } 
  @Post('payments/process') async processPayment(@Body() data: { orderId: string; 
amount: number; method: string }): Promise<any> { return 
this.appService.processPayment(data); } 
  @Get('payments/:paymentId') async getPayment(@Param('paymentId') paymentId: 
string): Promise<any> { return this.appService.getPayment(paymentId); } 
} 
// Cart Service Controller (app.controller.ts) 
@Controller() 
103 
482.ЧДТУ 262248 12 01 6 
export class AppController { 
  private readonly logger = new Logger(AppController.name); 
  @Get() @HttpCode(HttpStatus.OK) getHealth(): { status: string; service: string; 
timestamp: string } { this.logger.log('  Health check'); return { status: 'ok', 
service: 'cart-service', timestamp: new Date().toISOString() }; } 
  @Get('cart/health') @HttpCode(HttpStatus.OK) getCartHealth(): { status: string; 
service: string; timestamp: string } { this.logger.log('  Cart health check'); 
return { status: 'ok', service: 'cart-service', timestamp: new 
Date().toISOString() }; } 
} 
// Frontend (App.tsx) 
import { BrowserRouter, Routes, Route, Navigate } from 'react-router-dom'; 
import { AuthProvider } from './context/AuthProvider'; 
import { LocaleProvider } from './context/LocaleProvider'; 
import ProtectedRoute from './components/ProtectedRoute'; 
import Layout from './components/Layout'; 
import LoginPage from './pages/LoginPage'; 
import OverviewPage from './pages/OverviewPage'; 
import OrdersPage from './pages/OrdersPage'; 
import CatalogPage from './pages/CatalogPage'; 
import CustomersPage from './pages/CustomersPage'; 
import ServicesPage from './pages/ServicesPage'; 
import TestingPage from './pages/TestingPage'; 
import StressTestPage from './pages/StressTestPage'; 
function App() { 
  return (<BrowserRouter><LocaleProvider><AuthProvider><Routes><Route 
path="/login" element={<LoginPage />} /><Route element={<ProtectedRoute />}><Route 
path="/" element={<Layout><OverviewPage /></Layout>} /><Route path="/orders" 
element={<Layout><OrdersPage /></Layout>} /><Route path="/catalog" 
element={<Layout><CatalogPage /></Layout>} /><Route path="/customers" 
element={<Layout><CustomersPage /></Layout>} /><Route path="/services" 
element={<Layout><ServicesPage /></Layout>} /><Route path="/testing" 
element={<Layout><TestingPage /></Layout>} /><Route path="/stress-test" 
element={<Layout><StressTestPage /></Layout>} /></Route><Route path="*" 
element={<Navigate to="/" replace />} 
/></Routes></AuthProvider></LocaleProvider></BrowserRouter>); 
} 
export default App; 
104 
ДОДАТОК В 
“Високонавантажена програмна платформа електронної комерції на основі 
мікросервісів” 
Інструкція користувачеві 
482. ЧДТУ 262248 34 01
Листів 6 
Розробник  ________________  Лога Є.В. 
Черкаси 
2026
482.ЧДТУ 262248 34 01 2 
Для початку роботи з адміністративною панеллю e-commerce платформи 
необхідно мати: 
– доступ до інтернету та веб-браузер (Chrome, Firefox, Safari, Edge);
– облікові дані адміністратора (email та пароль).
Рисунок В.1 – Сторінка входу (Login Page) 
Для початку використання платформи користувач має перейти на головну сторінку 
застосунку у веб-браузері. На екрані з'явиться сторінка входу з двома полями для 
введення: 
– Email – поле для введення адреси електронної пошти адміністратора;
– Password – поле для введення пароля.
106 
482.ЧДТУ 262248 34 01 3 
Рисунок В.2 – Введення облікових даних 
Користувач вводить свої облікові дані у відповідні поля та натискає кнопку 
"LOGIN". Система відправляє запит на сервіс автентифікації (Auth Service, порт 
3001) через API Gateway. 
Якщо облікові дані введено правильно, система видає JWT-токен (дійсний 24 
години) та перенаправляє користувача на дашборд. Токен зберігається у контексті 
AuthProvider для наступних запитів. 
107 
482.ЧДТУ 262248 34 01 4 
Помилка входу: Якщо дані введено невірно, на екрані з'явиться повідомлення 
про помилку червоного кольору: "Invalid email or password".  
Рисунок В.3 – Головна сторінка дашборду 
Після успішного входу користувач потрапляє на сторінку Overview, де можна 
побачити: 
Элемент Опис 
Загальна сума замовлень Кількість всіх замовлень у системі 
Кількість активних Товари зі статусом "active" 
товарів 
Залишки на складі Загальне число од. товарів у інвентарі 
Статус мікросервісів Индикатори здоров'я (зелене = working, червоне 
= down) 
108 
482.ЧДТУ 262248 34 01 5 
Рисунок В.4 – Сторінка замовлень 
Користувач переходить до розділу "Orders" через бічне меню. На екрані 
відображається таблиця зі всіма замовленнями, де показано: 
– Order ID – унікальний ідентифікатор замовлення;
– Customer – ім'я клієнта;
– Amount – сума замовлення (грн.);
– Status – статус (pending, confirmed, shipped, delivered);
– Created Date – дата створення.
Рисунок В.5 – Фільтрування за статусом 
Користувач може фільтрувати замовлення за статусом, натиснувши на 
вкладку. 
109 
482.ЧДТУ 262248 34 01 6 
Рисунок В.6 – Каталог товарів 
Рисунок В.7 – Сторінка клієнтів 
На сторінці виведено список всіх зареєстрованих користувачів: 
Рисунок В.8 – Сторінка тестування АРІ 
На сторінці є можливість використовувати функціонал Postman прямо на 
панелі адміністратора
110 
ДОДАТОК Г 
“Високонавантажена програмна платформа електронної комерції на основі 
мікросервісів” 
Графічні матеріали 
482.ЧДТУ 262248 90 01
Листів 15 
Розробник  ________________  Лога Є.В. 
Черкаси 
2026
482.ЧДТУ 262248 90 01 2 
Рисунок Г.1 – Тема роботи 
Рисунок Г.2 – Мета та завдання 
112 
482.ЧДТУ 262248 90 01 3 
Рисунок Г.3 – Аналіз технічної інформації 
 Рисунок Г.4 – Актуальність задачі 
113 
482.ЧДТУ 262248 90 01 4 
 Рисунок Г.5 – Аналіз програмних засобів 
Рисунок Г.6 – Аналіз способів вирішення задачі 
114 
482.ЧДТУ 262248 90 01 5 
Рисунок Г.7 – Постановка задачі 
Рисунок Г.8 – Методика проектування 
115 
482.ЧДТУ 262248 90 01 6 
Рисунок Г.9 – Аналіз вимог 
Рисунок Г.10 – Вимоги замовника та розробника 
116 
482.ЧДТУ 262248 90 01 7 
Рисунок Г.11 – Діаграма прецедентів 
Рисунок Г.12 – Діаграма пакетів 
117 
482.ЧДТУ 262248 90 01 8 
Рисунок Г.13 – Діаграма класів 
Рисунок Г.14 – Діаграма компонентів та розгортання 
118 
482.ЧДТУ 262248 90 01 9 
Рисунок Г.15 – Діаграма діяльності та послідовності 
Рисунок Г.16 – Діаграма комунікацій та скінченного автомату 
119 
482.ЧДТУ 262248 90 01 10 
Рисунок Г.17 – ОбҐрунтування засобів реалізації 
Рисунок Г.18 – Структурна та функціональна схеми 
120 
482.ЧДТУ 262248 90 01 11 
 Рисунок Г.19 – Логічна схема системи 
 Рисунок Г.20 – Структура баз даних 
121 
482.ЧДТУ 262248 90 01 12 
 Рисунок Г.21 – Інтерфейс користувача 
Рисунок Г.22 – Модульне та інтеграційне тестування 
122 
482.ЧДТУ 262248 90 01 13 
Рисунок Г.23 – Системне та приймальне тестування 
Рисунок Г.24 –Приклади впровадження (1) 
123 
482.ЧДТУ 262248 90 01 14 
Рисунок Г.25 –Приклади впровадження (2) 
Рисунок Г.26 –Висновки 
124 
482.ЧДТУ 262248 90 01 15 
Рисунок Г.27 – Подяка 
Рисунок Г.28 – Дякую за увагу 
125