Навчіться проєктувати розподілені застосунки на реальних бізнес-кейсах
2 листопада 2026 - 7 грудня 2026
Понеділок та четвер (19:30 за Києвом)
Зустрічі в Zoom (+запис)
Постійний зв'язок у Slack
11 занять по 1.5 години
17 годин ДЗ
330$ за курс
Манібек 7 днів
System Design in Practice — це практичний курс для розробників, які хочуть навчитися проєктувати системи в умовах, наближених до реальної роботи: з бізнес-вимогами, обмеженнями, trade-offs і рішеннями, які потрібно вміти пояснювати та захищати.
На курсі ми не просто розбиратимемо архітектурні патерни — ми пройдемо повний шлях від бізнес-кейсу до архітектури розподіленого застосунку. Крок за кроком визначимо межі системи, функціональні та нефункціональні вимоги, спроєктуємо API, доменну модель, сховища, інтеграції, real-time updates, пошук, фонову обробку, observability, безпеку та механізми масштабування.
Фокус курсу — навчитися мислити як інженер, який відповідає за архітектурне рішення: бачити обмеження, ставити правильні питання, оцінювати ризики, порівнювати підходи й аргументувати, чому в конкретному контексті варто обрати саме таку архітектуру.
Курс буде корисним middle- та senior-розробникам, які хочуть впевненіше брати участь в архітектурних дискусіях, проєктувати новий функціонал з нуля, бачити слабкі місця в системах і краще підходити до system design interviews.
Ви візьмете з курсу максимум, якщо у вас уже є:
Досвід роботи з HTTP, REST API, SQL. Також вміння читати приклади коду на TypeScript.
Знайомство з поняттями кеш, черга, реплікація, горизонтальне масштабування — глибокого досвіду не потрібно.
Заняття українською, але конспекти та додаткові матеріали — англійською.
Сумніваєтесь, чи підходить вам курс? Напишіть у Telegram — підкажемо чесно.
Відгуки інженерів, які застосовують здобуті знання у своїй роботі.
AI Engineer | Agentic Systems | Voice & Chat Assistants | Healthcare AI
Я дуже вдячний Олександру Марфуту за класний курс, дізнався багато чого нового та корисного для себе! Особливо сподобалось те, наскільки ретельно Олександр підходить до вибору матеріалу. Інформації дуже багато, та що, на мою думку, найбільш важливе — він завжди намагається навести реальні приклади та кейси зі своєю багаторічної практики. Олександр завжди готовий витратити свій час на те, щоб пояснити те, що комусь може бути не зрозуміло, навіть зробити індивідуальній дзвінок — аби учень повноцінно зрозумів тему та засвоїв матеріал. Домашні завдання дуже практичні та сприяють формуванню необхідних навичок. В цілому, курс супер — однозначно рекомендую!
PHP Software Developer
@BINTIME
Senior Software Engineer
@Tricentis
Визначимо, що ми хочемо побудувати, проаналізуємо бізнес-кейс, визначимо вимоги, use cases тощо.
Не всі NFR однаково важливі — частина з них для конкретної системи просто нерелевантна. Отримавши змішаний список із 15 нефункціональних вимог, визначте якомога більше тих, що для платформи управління інцидентами другорядні або зайві, і коротко поясніть, чому.
Побудуємо доменну модель, щоб архітектура спиралася на реальні бізнес-поняття, а не на випадковий набір таблиць і сервісів.
Розширте фінальну доменну модель уроку новою сутністю — follow-up action items, які команда фіксує після постмортему. Визначте її атрибути, зв’язки з інцидентом і користувачем, кардинальність, спосіб моделювання статусу та інваріанти, що обмежують її існування.
Спроєктуємо API-контракти так, щоб вони підтримували основні сценарії продукту і залишали простір для еволюції системи.
Розширте OpenAPI-специфікацію новим ресурсом — follow-up action items з попереднього уроку. Спроєктуйте шляхи, операції, схеми, коди відповідей і помилки так, щоб специфікація залишалась цілісною.
Розробимо high-level architecture першої версії системи і визначимо, які дані, сховища та гарантії потрібні різним частинам продукту.
Адаптуємо архітектуру під read-heavy навантаження.
Дослідіть сценарії використання Redis: кеш, сховище сесій, rate limiting, розподілені блокування, черги, pub/sub і стріми. Для кожного сценарію проаналізуйте, чи потрібен він Incident Management Platform — з посиланням на конкретну функціональну або нефункціональну вимогу.
Проаналізуємо стратегії масштабування API та оберемо найефективніший підхід.
Incident Management Platform очікує сплеск трафіка під час масового інциденту, коли кількість запитів до API Service зростає в кілька разів за хвилини. Оберіть тригери автоскейлінгу та порогові значення, оберіть підходи оптимізації Cold Start і визначте, які кроки Graceful Shutdown потрібні, щоб не втратити запити, що вже обробляються, під час scale-down.
Проаналізуємо способи розділити read та write навантаження та оберемо найоптимальніший.
GET /api/incidents — другий за навантаженням ендпоінт (~1000 RPS, ~70–80% запитів — дефолтний вигляд status=open, page 1), що живить dashboard grid у UI. Спроєктуйте формат cache key з обґрунтуванням кожного сегмента та TTL, напишіть псевдокод інвалідації для зміни статусу інциденту, розгляньте техніку cache versioning як альтернативу прямій інвалідації.
Спроєктуємо пошук як окремий архітектурний компонент: від вимог до індексації, синхронізації даних.
Сценарії: внутрішній довідник, пошук інцидентів під час великої аварії, адмінка на два тижні розробки, зміна даних, які продубльовані в тисячах документів пошукового індексу. Для кожного треба обрати найбільш дешевий механізм синхронізації реляційних даних (dual-write, scheduled sync, transactional outbox, full rebuild vs targeted update) із пошуковим індексом. Окремо треба спроєктувати, що станеться, коли синхронізація впаде.
Розберемо, як проєктувати системи, у яких клієнти отримують оновлення майже в реальному часі.
Спроєктуйте наскрізний flow near real-time updates для Incident Management Platform: payload події оновлення інциденту, поведінку клієнта при reconnect (виявлення пропущених подій і resync стану) та метрики (наприклад, delivery latency) і цільові значення для перевірки NFR.
Розширимо нашу архітектуру двома ключовими складовими — Audit Trail та Observability.
П'ять систем — від невеликого SaaS до державного архіву на 15 років. Для кожної ви обираєте сховище для audit logs. Кожен кейс має вимогу, яка відсікає найпопулярніший вибір.
Завершимо архітектуру системи безпечною моделлю доступу: від user authentication до service-to-service authorization і ролей у продукті.
Ви проєктуєте перевірку токенів для аптеки при лікарні: більшість запитів — звичайні читання, невелика частка — дії з наслідками для пацієнта. Дві вимоги тягнуть у різні боки: блокування співробітника має спрацьовувати миттєво, а система не може лягати разом з identity provider'ом. Обхідні шляхи закриті умовою — доведеться вирішувати, чи всі ендпоінти перевіряють токен однаково. Результат — ADR на одну сторінку з sequence діаграмою, цифрами та ціною рішення.
