Ця доповідь демонструє практичні підходи до unified observability, де метрики, логи, траси та профілі інтегровані для швидкої діагностики проблем у розподілених системах. Розглянемо техніки кореляції даних через traceId та лейбли для миттєвого переходу від помилок до конкретних span'ів, налаштування continuous profiling для preview-середовищ, використання flame charts для аналізу продуктивності, dependency maps і service graphs для візуалізації архітектури. Окрема увага приділена AI-специфічним аспектам: застосування AI-асистентів для автоматизації root cause analysis та впровадження AI Evals для систематичного оцінювання якості, коректності та надійності AI-систем.

Low Latency в High-Load: шлях від Redis Pub/Sub до In-Memory Runtime — іграшка, яка зайшла надто далеко У доповіді розглянемо практичний досвід побудови low-latency системи для міжбіржових операцій, де географія не менш важлива, ніж алгоритми. Поговоримо про те, чому message brokers і класичні мікросервіси не є вдалим рішенням для HFT (High-Frequency Trading)-подібних сценаріїв, як in-memory state у поєднанні з регіональними runtime-вузлами забезпечує прогнозовану затримку, і де проходить межа між швидкістю та consistency.

Ріст команд і сервісів часто призводить до ситуації, коли кожне окреме рішення виглядає правильним, але система в цілому стає складною, непередбачуваною і важкою в підтримці. У доповіді Йожеф розповість, як вони з командою підійшли до стандартизації технологій, що саме вирішили уніфікувати, а що — залишити на розсуд команд, і чому observability стала не ціллю, а природним наслідком цього підходу.

Коли система складається з десятків незалежних репозиторіїв, класична monorepo не завжди підходить. Дмитро розповість, як meta-repo з git submodules та AI-інструментами дозволяє зберегти автономність сервісів, але працювати з ними як з єдиною екосистемою. Ви побачите реальні сценарії, де AI: • з’єднує код, контракти та документацію • допомагає з автотестами та інтеграціями • спрощує роботу для девелоперів, QA та продукту • пришвидшує прототипування та delivery

Знати SOLID та патерни GoF — це як знати правила дорожнього руху: можна здати іспит і все одно потрапити в аварію. Бо між «знаю, що існує Single Responsibility» і «розумію, навіщо він потрібен саме тут» — прірва. І в цій прірві живуть God-класи, незамінювані залежності та інтерфейси, які неможливо імплементувати. На прикладах реальних помилок великого проєкту поговоримо про різницю між знанням і розумінням, про те, як фреймворки можуть маскувати архітектурні проблеми, і чому єдиний спосіб писати підтримуваний код — це зрозуміти «навіщо», а не завчити «як».

Як за лічені години побудувати власне середовище для генеративного ШІ — від ідеї до робочого рішення? Під час виступу команда De Novo поділиться практичним досвідом створення керованого середовища для GenAI, розповість про архітектуру, підхід до безпеки та реальні сценарії використання в українських компаніях.

Доповідь присвячена підходу масштабування бізнесу через продуктовий архітектурний принцип (Product-Oriented Architecture) — перехід від одного рішення до повноцінної екосистеми з 10+ незалежних продуктів протягом трьох років.

Що може піти не так, якщо дозволити кожному сервісу напряму звертатися до бази даних? У стартапі це здається швидким і зручним рішенням, та з часом система масштабується, і зʼявляються проблеми, про які ніхто не здогадувався. У своїй доповіді я поділюся досвідом Solidgate у трансформації архітектури: від хаосу прямих підключень до сервісної моделі доступу до даних. Розповім про стадії переходу, bottlenecks і про те, як ізоляція вплинула на підтримку інфраструктури. Чесно покажу, що спрацювало, а що — ні. Словом, розберемо всю контроверсійність цієї теми.

2025 рік. Ігнорувати AI-слона в JavaScript-кімнаті стає все важче. Це створіння у ритмі вайб-кодингу топчеться по всьому що так дорого програмістам: по чистому коду, по архітектурі, по нашим звичкам і переконанням що вважати правильним, а що ні. Це знання коштувало мені пару десятків тисяч доларів у розробці проєкту з режимом використання ШІ "на максимум". І все що залишилося на згадку - ця доповідь. Звісно ми не зможемо торкнутися всього, але мені конче потрібен сеанс терапії про найболючіше - про те як я, спілкуючись з ШІ перестав розуміти що таке для мене архітектура і що з цим робити.

Коли на карту поставлена людська безпека, технічна надійність — не просто вимога. У цій доповіді розглянемо архітектуру, навантаження, WebSocket-рішення, масштабування Kubernetes та інші технічні аспекти створення карти повітряних тривог. Це історія не тільки про код, а й про відповідальність.