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

Ви коли-небудь замислювались, що насправді відбувається під капотом розподілених систем? Не тих, що «типу кластер» на 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 векторів.