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

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

Чи працюють бізнес-підходи в оборонній сфері? Як збалансувати зручність та безпеку? Поділимось досвідом створення, розробки та впровадження з нуля інфраструктури DOT-Chain

Поговоримо про архітектурні рішення, які дозволяють 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 проекти готуються до найгарячішого періоду року, на які ключові аспекти варто звернути увагу та що очікувати. Поділимося досвідом налаштування автоскейлінгу, балансування навантаження, а також розкажемо, які навантаження витримує Сільпо і завдяки яким рішенням ми проходимо цей сезон без збоїв.