У High-Load системах вартість інфраструктури часто зростає не через саме навантаження, а через неефективні архітектурні рішення: overprovisioning, надмірне використання managed-сервісів, зайвий data movement, неправильні SLA-рішення та відсутність прозорої cost-моделі. На конференції поговоримо, як підходити до cost optimization як до повноцінної архітектурної практики, а не як до разового скорочення ресурсів. Також поговоримо про аналіз workload profile, пошук реальних bottleneck’ів, побудову unit economics для інфраструктури, оптимізацію трафіку, кешування, CDN, observability та контрольовану деградацію сервісів. Окремо розберемо trade-off між performance, reliability та cost: де потрібна максимальна відмовостійкість, де достатньо eventually consistent підходу, а де managed-рішення варто замінити простішою self-hosted архітектурою.

У багатьох системах аналітика будується прямо в backend: події, воркери, enrichment через десятки запитів до бази та виклики інших сервісів. У нашому випадку один аналітичний event генерував до 10 звернень у БД, що при масштабі в мільйони подій створювало значне навантаження на production. У цій доповіді я розповім, як ми повністю змінили підхід: - перейшли від application events до CDC через Debezium; - почали віддавати зміни з кожної таблиці напряму в data pipeline; - перенесли enrichment та агрегації в BigQuery; і фактично прибрали аналітичне навантаження з backend-сервісів. У результаті: - ми позбулися мільйонів read-запитів до production бази; - зменшили складність backend-коду; - відокремили OLTP від аналітики; і зробили побудову аналітики значно швидшою. Окремо поговоримо про неочевидний ефект: тепер для побудови нових аналітичних сценаріїв достатньо одного Data Engineer, ERD-схеми та сучасних AI-інструментів — без залучення backend-команди і без змін у продакшн-коді. Також розглянемо: - де CDC реально дає виграш, а де ні; - які проблеми з’являються (lag, дублікати, schema changes); - як змінюється вартість системи; і чому “ті самі дані” в новій архітектурі — це не безкоштовно.

Більшість інженерів рано чи пізно стикаються з необхідністю проводити load testing: перевірити масштабування сервісу, протестувати нову базу даних або зробити performance benchmark для нової технології. І тут виникає питання — який інструмент обрати? Існуючі рішення добре працюють для HTTP-навантаження, але часто мають обмеження, коли потрібно тестувати інші протоколи, моделювати складні workload-патерни (open vs closed systems, skewed distributions, hot partitions) або запускати distributed load testing у кластері. У цій доповіді я розповім про NBomber — Load Testing Framework, який я створив для вирішення цих задач. Ми поговоримо про: - чому виникла ідея створити новий інструмент попри існування Gatling, Locust та k6; - використання .NET та мови F# для побудови latency-sensitive систем; - архітектуру NBomber; - як працює NBomber Cluster; - кілька практичних кейсів: database benchmarks, anomaly detection, Kubernetes integration, benchmark comparison та аналіз performance trends.

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 як для короткотривалих пайплайнів, так і розтягнутих в часі фонових задач.