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

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

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

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

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

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