Ми розглянемо React Server Components зсередини, на прикладі імплементації на мові програмування Clojure. Ви дізнаєтесь як виглядає «магія» серверних компонентів під капотом, як працює стрімінг компонентів, чи справді можна відправити проміс HTTP запитом з серверу на клієнт? Яким чином функція, що є тільки на бекенді викликається на фронтенді? Як зробити так, щоб серверні компоненти працювали швидко? На додачу, ми зануримось у мову Clojure, щоб подивитись як одні й ті ж концепції можуть бути побудованими на радикально відмінній мові програмування.

Ви коли-небудь замислювались, що насправді відбувається під капотом розподілених систем? Не тих, що «типу кластер» на 3 ноди, а справжніх, що на ексабайтних масштабах? На цій доповіді ми разом зазирнемо за лаштунки сучасної інфраструктури. Як працюють системи, що обробляють гори даних? Які патерни, принципи та інженерні рішення ховаються за scalable архітектурами? Обговоримо: * Як виглядає життя розподіленої системи зсередини * Чим відрізняється розподілений застосунок від справжньої системи * Як схеми зберігання даних трансформуються у сучасні БД, черги й логи * Чому PostgreSQL у клауді, це вже не PostgreSQL? * Чим Northguard крутіший за Kafka? * Як працюють нові гравці типу NewSQL? Якщо ви архітектор, техлід, розробник або просто хочете зрозуміти, чому інфраструктура масштабується так, як масштабується - приходьте! Поділюся інсайтами, які, можливо, зможете застосувати у власних проєктах або розглянете їх під іншим кутом. P.S. І так, буде трохи магії ✨та багато правди про розподілені системи, які рухають цей світ ?

Презентація буде сфокусована на maintainability quality attribute - як зробити бізнес-логіку ізольованою, консолідованою, інкапсульованою та консистентною. А також як інтегрувати її з інфраструктурою зберігання, обміну повідомленнями, etc. Розглянемо особливості застосування таких підходів: - OOD / Rich Domain Model / DDD - Hexagonal layered architecture - CQRS/Persistance/ORM Всі особливості будуть продемонстровані на прикладі реального завдання та підходу до його реалізації (приклади коду будуть на .NET)

<p>JavaScript та Golang — це два різні світи, які часто перетинаються в сучасних проєктах: перший домінує у frontend-розробці та швидкому прототипуванні, тоді як другий — у високонавантажених сервісах та мікросервісних архітектурах. <p>У цій доповіді я поділюся власним досвідом переходу з JS на Go, порівняю підходи до асинхронного програмування, архітектури додатків, роботи з базами даних та інструментів. Ми розглянемо не тільки відмінності, а й спільні риси, які допомагають розробникам легше адаптуватися між цими екосистемами.</p>

Ця доповідь присвячена шляху розвитку після досягнення рівня сеньйор-інженера. Спираючись на власний досвід — від Junior Engineer до керівника Node.js Department — я розповім про особисті виклики, уроки та ключові моменти, які сформували мою кар’єру. Сесія стане практичним посібником для інженерів, які вже досягли рівня сеньйора і замислюються: «Що далі?». Ми розглянемо можливості як вертикального, так і горизонтального розвитку — від технічної майстерності до лідерства, від становлення експертом до формування команд і цілих департаментів.

Уявіть, що ви вирішили врятувати старий, зношений корабель, замінивши його двигуни на найсучасніші. Але замість того, щоб “полетіти у світле майбутнє”, він починає тонути ще швидше. Це історія про те, як Clean Architecture може стати і рятівним кругом, і каменем на шиї проєкту. У першій частині — хроніки болю: спроба впровадити архітектурну красу у хаос легасі коду, де навіть успіхи здавались випадковістю та чому "Ми просто робимо Clean Architecture" не завжди працює. У другій — історія “тріумфу”: коли зріла команда і правильний підхід перетворили Clean Architecture на фундамент масштабованої, гнучкої та живої системи. Дві історії з реальної практики, що показують, чому той самий підхід може як провалити, так і врятувати проєкт.

Покажу практичні підходи, типові граблі та готові шаблони, які дозволяють утримувати 200+ сервісів у продакшні і залишатися при здоровому глузді.

Запуск Diia AI всупереч усім труднощам Що потрібно, щоб створити розмовного AI-асистента для мільйонів громадян? Подорож зі створення Diia.AI, національного цифрового асистента України, почалася з простого й багатообіцяючого Proof of Concept. Але перехід від контрольної демо-версії до живої, продуктивної системи, що працює з чутливими даними та реальними державними сервісами, виявився шляхом, сповненим несподіваних викликів. Ця доповідь — чесний, закулісний погляд на нашу архітектурну еволюцію. Ми заглибимося у реальні виклики, з якими зіткнулися: від боротьби з непередбачуваними "галюцинаціями" LLM та інтеграції зі складними державними реєстрами, до проєктування системи для національного рівня безпеки й масштабування під екстремальним тиском. Це не історія бездоганного успіху; це історія вирішених проблем — від абсурдно простих до монументально складних. Приєднуйтесь, щоб дізнатися практичні уроки, яких немає в підручниках. Ми розповімо, як проєктували систему з урахуванням стійкості, застосовуючи RAG-підхід для боротьби з дезінформацією, впроваджували надійні Guardrails для забезпечення безпеки та будували масштабовану, відмовостійку екосистему. Ця сесія буде корисною для архітекторів, розробників і продуктових лідерів, які хочуть зрозуміти справжні «шрами від битв» та важко здобуті інсайти, що приходять із запуском масштабної AI-платформи всупереч усім труднощам.

Ми хотіли зробити сервіс швидким для користувачів у будь-якій точці світу. Edge Computing виглядало як ідеальне рішення. На практиці ж ми отримали і зменшення latency, і цілу купу несподіваних проблем. У цій доповіді я розповім: - як ми проектували edge-архітектуру для глобальних користувачів; - edge-провайдери та інфраструктура: що обрали і чому; - які оптимізації справді дали відчутний результат; - архітектурні компроміси, що вплинули на дизайн системи; - де edge перетворився на “edge-case” і змусив шукати нестандартні обхідні рішення; - наші факапи, та best practices;

Як проєктувати архітектуру для продукту, який уже має успішний прод, але всередині нього хочеться запускати стартапи? Як не завалити стабільну систему, зберегти довіру користувачів, і водночас дати бізнесу простір для експериментів? - Болючі кейси "важких фіч", що не прижились - Як перетворили бажання бізнесу "більше й швидше" на архітектуру - Успішний кейс швидких фіч: Таємні бокси в Expirenza - Проблеми після успіху "тимчасової" фічі - Зміна майндсету команди розробки