SYSTEM DESIGN IN PRACTICE

Навчіться проєктувати розподілені застосунки на реальних бізнес-кейсах

ЗАРЕЄСТРУВАТИСЬ НА КУРС

Графік

27 липня 2026 - 27 серпня 2026
Понеділок та четвер (19:30)

Формат

Зустрічі в Zoom (+запис)

Постійний зв'язок у Slack

Зайнятість

10 занять по 1.5 години

20 годин ДЗ

Ціна

270$ за курс

Манібек 7 днів

ПРО КУРС

Навички System Design є одними з ключових для розробників. Як розробити багаторівневу стратегію кешування? Коли і як варто впроваджувати CQRS? Як виокремити логіку з моноліту в новий мікросервіс? Як вирішувати проблеми ordering та duplication у message-брокерах? Розуміння цих та інших архітектурних питань необхідне розробнику для проєктування нового функціоналу, виявлення слабких місць у наявних системах та успішного проходження інтерв’ю.

Цей курс допоможе вам опанувати ці та інші архітектурні теми у максимально практичний спосіб. Ми візьмемо бізнес-кейс і крок за кроком протягом курсу перетворимо його на детально продуману архітектуру, пройшовши повний цикл проєктування розподілених застосунків.

Такий формат курсу навчить вас ефективно використовувати різні патерни, практики та інструменти в комплексі для проєктування надійних і масштабованих застосунків з нуля.

ПРОГРАМА КУРСУ

Огляд бізнес-кейсу та аналіз вимог

Визначимо що ми хочемо побудувати, проаналізуємо бізнес-кейс, визначимо вимоги, use cases тощо.

На занятті
  • проаналізуємо функціональні вимоги бізнес-кейсу
  • визначимо ключові нефункціональні вимоги (NFRs): performance, scalability, availability, security тощо
  • сформуємо цільові значення для NFRs і визначимо способи їх вимірювання
  • розглянемо приклади, як цільові значення NFRs впливають на архітектурні рішення
Домашнє завдання (~2 год)
  • виділити user roles та user journeys з бізнес-кейсу
  • виділити та описати функціональні вимоги з мапінгом до ролей
  • розробити use case діаграму на основі визначених вимог
  • визначити додаткові нефункціональні вимоги (NFRs)
Заняття 1 27 липня 2026 19:30
Проєктування доменної моделі

Побудуємо доменну модель, щоб архітектура спиралася на реальні бізнес-поняття, а не на випадковий набір таблиць і сервісів.

На занятті
  • розробимо доменну модель системи, визначимо сутності та зв'язки між ними
  • проаналізуємо основні trade-offs, які виникають під час проєктування доменної моделі
  • розробимо state machine діаграми для обʼєктів домену з життєвим циклом
  • визначимо, які дані системи потребують strong consistency, а для яких допустима eventual consistency
Домашнє завдання (~2.5 год)
  • деталізувати доменні об'єкти та їхні властивості, розроблені під час заняття
  • модифікувати розроблену доменну модель з урахуванням додаткових вимог
  • провести класифікацію доменних об'єктів на Aggregate Roots, Entities, Value Objects та Enums
Заняття 2 30 липня 2026 19:30
Проєктування API контрактів

Спроєктуємо API-контракти так, щоб вони підтримували основні сценарії продукту і залишали простір для еволюції системи.

На занятті
  • спроєктуємо набір REST API для ключових функціональних вимог
  • розглянемо API-first підхід: OpenAPI, Client SDK Generation, Automated Testing
  • розробимо CI/CD-пайплайн для автоматичного налаштування та оновлення API Gateway на основі OpenAPI spec
  • сформуємо підхід до версіонування API-контрактів та забезпечення backward compatibility
  • порівняємо REST, gRPC, GraphQL та Event-driven API з точки зору архітектурних trade-offs
Домашнє завдання (~1 год)
  • розробити додаткові API та доповнити OpenAPI специфікацію
  • оновити API контракти з урахуванням нових бізнес-вимог
Заняття 3 3 серпня 2026 19:30
Розробка High-Level Design

Розробимо high-level architecture першої версії системи і визначимо, які дані, сховища та гарантії потрібні різним частинам продукту.

На занятті
  • розробимо початкову архітектуру, що покриває функціональні вимоги
  • визначимо, які дані доцільно зберігати в relational storage, а які — в інших типах сховищ
  • розробимо SQL schema для зберігання реляційних даних з визначенням ключів, зв'язків та індексів
  • оберемо NoSQL підходи до зберігання audit logs, пошукових індексів і згенерованих звітів
Домашнє завдання (~3 год)
  • розробити C4-діаграму для початкової архітектури системи
  • описати Architecture Decision Records (ADR) для основних архітектурних рішень
  • підібрати набір хмарних сервісів і їхні характеристики, необхідні для розгортання системи
Заняття 4 6 серпня 2026 19:30
Redesign for Read Scalability

Адаптуємо архітектуру під read-heavy навантаження.

На занятті
  • оцінимо здатність поточної архітектури задовольнити нефункціональні вимоги та визначимо обмеження
  • оптимізуємо систему для 50,000 read-only users під час major інцидентів
  • розберемо, як поєднувати кілька рівнів кешу (Redis, in-memory cache, CDN)
  • розберемо, як зменшувати навантаження на базу через denormalized read models та CQRS
Домашнє завдання (~2 год)
  • підібрати механізм інвалідації кешу залежно від типу збережених даних
  • спроєктувати fallback стратегії при відмовах інфраструктури (Redis, Message Broker тощо)
Заняття 5 10 серпня 2026 19:30
Проєктування Full-Text Search

Спроєктуємо пошук як окремий архітектурний компонент: від вимог до індексації, синхронізації даних.

На занятті
  • розберемо вимоги до пошуку, фільтрації та сортування інцидентів
  • порівняємо основні інструменти повнотекстового пошуку: OpenSearch, Algolia, Typesense
  • спроєктуємо базову архітектуру пошуку з використанням окремого search index та механізму синхронізації даних з основною базою
  • розглянемо синхронну й асинхронну індексацію, а також CDC у проєктуванні пошуку
Домашнє завдання (~1.5 год)
  • розробити JSON-схему для зберігання пошукового індексу
  • розробити API контракти для Search мікросервісу
Заняття 6 13 серпня 2026 19:30
Проєктування Near Real-Time Updates

Розберемо, як проєктувати системи, у яких клієнти отримують оновлення майже в реальному часі.

На занятті
  • спроєктуємо real-time update flow: від зміни інциденту до доставки оновлення в браузер користувача
  • розберемо WebSocket connection management: підключення, підписка на incident channel, reconnect, heartbeat
  • порівняємо polling, long polling, Server-Sent Events та WebSockets для оновлення даних
  • розберемо засоби масштабування WebSocket з'єднань при зростанні навантаження
Домашнє завдання (~2 год)
  • спроєктувати event payload для near real-time updates
  • описати, як система має поводитись при reconnect
  • визначити метрики та цільові значення для перевірки NFR
Заняття 7 17 серпня 2026 19:30
Проєктування Audit Trail та Observability

Розширимо нашу архітектуру двома ключовими складовими — Audit Trail та Observability.

На занятті
  • розберемо, що таке audit trail: як фіксувати хто, що, коли і в якому об’єкті змінив
  • спроєктуємо асинхронний flow для audit logs з використанням message queue, shared packages, workers та NoSQL сховища
  • розберемо OpenTelemetry як стандарт для збору logs, metrics і traces та інтеграції з observability-платформами
  • навчимося використовувати distributed tracing для аналізу повного шляху запиту між сервісами, базами даних, чергами
Домашнє завдання (~1.5 год)
  • спроєктувати механізм відображення Audit Logs на UI
Заняття 8 20 серпня 2026 19:30
Проєктування Notifications & Reports Generation

Розширимо нашу архітектуру, щоб врахувати потреби в сповіщеннях та генерації звітів.

На занятті
  • визначимо, які події в системі мають призводити до надсилання повідомлень користувачам через email, mobile та інші канали
  • спроєктуємо архітектуру notification system з використанням Outbox Pattern, message queue, workers, retries, deduplication та idempotent delivery
  • розберемо, коли необхідно генерувати звіти асинхронно
  • спроєктуємо архітектуру генерації звітів з використанням S3 object storage та signed download URLs
Домашнє завдання (~3 год)
  • розширити OpenAPI специфікацію ендпоінтами для створення репорту та перевірки статусу його генерації
  • спроєктувати модель налаштувань користувача: які типи сповіщень користувач хоче отримувати через email, SMS тощо
Заняття 9 24 серпня 2026 19:30
Проєктування аутентифікації та авторизації

Завершимо архітектуру системи безпечною моделлю доступу: від user authentication до service-to-service authorization і ролей у продукті.

На занятті
  • визначимо, як організувати безпечний доступ користувачів до системи
  • інтегруємо в систему OpenID Connect та Auth0 як Identity Provider
  • підберемо підходи до безпечної service-to-service взаємодії
  • розберемо, як працювати з JWT токенами (ID, Access, Refresh): зберегання, конфігурація, валідація
  • спроєктуємо Role-Based Access Control та розглянемо альтернативи PBAC, ABAC, ReBAC
Практика
  • описати authentication та authorization flows
  • спроєктувати RBAC matrix для основних ролей
Заняття 10 27 серпня 2026 19:30

ПРО ВИКЛАДАЧА

Фото автора

Олександр Марфут  LinkedIn Telegram

Technical Architect @SoftServe

Software Architect та Technical Leader з понад 15 роками досвіду проєктування cloud-native та enterprise-систем. Спеціалізуюся на архітектурі хмарних рішень (Azure, AWS), модернізації legacy-систем, розподілених системах та AI-трансформації бізнесу. Маю практичний досвід супроводу проєктів на всіх етапах — від pre-sales та discovery до production delivery. Окремий напрям моєї діяльності — викладання та розвиток інженерів: понад 5 років досвіду створення навчальних програм, проведення тренінгів і менторства.

ЧОГО ВИ НАВЧИТЕСЯ

Перетворювати бізнес-вимоги на архітектурні рішення — аналізувати функціональні та нефункціональні вимоги до продукту, аналізувати обмеження системи та обґрунтовувати вибір архітектурних підходів.
Застосовувати сучасні архітектурні патерни — працювати з API design, CQRS, Outbox Pattern, Asynchronous Messaging, Caching, WebSockets, Domain Driven Design та іншими підходами.
Уникати типових помилок у проєктуванні систем — розбирати реальні архітектурні проблеми з практичного досвіду викладача: невдалі рішення, їхні наслідки та підходи, які допомагають будувати надійніші системи.
Проєктувати ключовий функціонал сучасних систем — продумувати real-time updates, автентифікацію та авторизацію, кешування, пошук, нотифікації, фонову обробку, аудит, observability та інші важливі системні компоненти.