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

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

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

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

Масштабування системи з 66 мільйонів до понад 25 мільярдів записів - завдання не для людей зі слабкими нервами, особливо якщо мова йде про фінансову систему, де точність не підлягає обговоренню, а затримка даних не є прийнятним варіантом. У цій доповіді Дмитро розповість про реальний шлях масштабування такої системи, залишаючись при цьому здоровим глуздом і зберігаючи правильні цифри. Ви дізнаєтесь, як жонглювати надвисокою точністю та низькою затримкою, оптимізувати логіку вашого додатку та обійти звичайні пастки, які виникають при масштабуванні баз даних. Ця доповідь не про глибоке занурення у внутрішні деталі - вона про обмін прагматичними стратегіями, які допоможуть вам масштабувати, не потонувши у складнощах. Ідеально підходить для інженерів та системних архітекторів, які прагнуть вирішувати серйозні проблеми масштабування з ясністю та впевненістю.

Сьогодні Redis — це де-факто стандарт для кешування у сервісах застосунків. Він неймовірно швидкий і простий у використанні, що дало йому значну перевагу на ринку. Однак із зростанням складності системи Redis має кілька обмежень, які впливають на надійність і доступність вашої системи, особливо під високим навантаженням. У 2025 році ми починаємо поступово відмовлятися від Redis і переосмислювати підхід до кешування загалом. У цій доповіді я поділюся своїм баченням проблеми та її вирішення. Ми розглянемо виклики, пов’язані з Redis, та альтернативні рішення для створення більш стійких і масштабованих систем.

У своїй доповіді я розповім про ключові аспекти стратегії Zero Sales Lost, зосереджуючись на управлінні інцидентами в контексті розробки E-commerce та екосистеми "Сільпо". Поділюся нашим досвідом побудови процесу управління інцидентами, особливостями архітектури систем моніторингу та алертингу, а також тим, як ми масштабували ці процеси для 19 продуктів та 41 команду. Окрім цього, обговоримо роль DevOps культури та відповідальності команд у продуктовій розробці. На основі реальних кейсів проаналізуємо, чи можна запобігти критичним падінням і як саме.

Я поділюся проблемами, з якими зіткнулася наша команда під час розробки та підтримки програмного забезпечення з архітектурою мікросервісів протягом 5 років, які рішення ми застосували та як це вплинуло на нас. У доповіді ми розглянемо: моделювання домену, топологію активів, цінність стандартів і м'яких навичок.

Як створювати ефективну, економну та сучасну архітектуру на практиці.