Поговоримо про архітектурні рішення, які дозволяють Elasticsearch залишатися стабільним під високим навантаженням: правильна організація індексів і шардів, політики ILM, використання persistent queues у Logstash, даунсемплінг метрик та моніторинг самої observability-системи. Поділюся досвідом побудови надійної платформи з терабайтами логів і мільйонами подій на день.

Шаблони проектування такі, як Event Sourcing та Event Streaming уже давно стали одними зі стандартів для побудови систем з real-time аналітикою. Проте коли навантаження в системі стає нелінійним зі швидкими і часто непередбачуваними піками, важливо вчасно реагувати на це, аби не втратити власне ефект режиму реального часу. В своїй розповіді хочу поділитися досвідом впровадження та використанням такого інструменту, як Temporal.io. Розглянемо еволюцію нашої системи підтримки актуальності звітів в режимі реального часу та поговоримо про використання Temporal як для короткотривалих пайплайнів, так і розтягнутих в часі фонових задач.

Ця доповідь присвячена практичному досвіду переходу з класичної Istio-архітектури з sidecar-контейнерами на нову модель — Istio Ambient Mesh. Ми розповімо, як масштабування мікросервісної інфраструктури на Kubernetes призвело до зростання витрат на ресурси, ускладнення CI/CD та затримок у запуску сервісів. Пошук рішень привів нас до впровадження Ambient Mesh — архітектури без sidecar-контейнерів, яка значно спрощує mesh-інтеграцію і знижує інфраструктурні витрати. У доповіді буде детально розглянуто технічні аспекти міграції: як ми готувалися до переходу, які виклики виникали у процесі впровадження та як вдалося їх подолати у співпраці зі спільнотою Istio. Поділимось результатами, аналітикою, реальними метриками до/після та дамо практичні поради командам, які планують впровадження Ambient Mesh у production.

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

Проговоримо про нашу історію. Як ми починали проєкт з невеликою векторною базою менш ніж 2 млн записів. Згодом прийшов запит на +100 млн записів, потім ще +100… І так поступово ми вийшли майже на 1 млрд. Стандартні інструменти швидко вичерпували себе — ми впирались у перформанс, розмір індексу та дуже обмежені ресурси. Після довгої серії проб і помилок ми зібрали власний low-cost кластер, який сьогодні стабільно обробляє тисячі запитів до понад 1B векторів.

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

Розглянемо, як e-commerce проекти готуються до найгарячішого періоду року, на які ключові аспекти варто звернути увагу та що очікувати. Поділимося досвідом налаштування автоскейлінгу, балансування навантаження, а також розкажемо, які навантаження витримує Сільпо і завдяки яким рішенням ми проходимо цей сезон без збоїв.

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