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

Що може піти не так, якщо дозволити кожному сервісу напряму звертатися до бази даних? У стартапі це здається швидким і зручним рішенням, та з часом система масштабується, і зʼявляються проблеми, про які ніхто не здогадувався. У своїй доповіді я поділюся досвідом Solidgate у трансформації архітектури: від хаосу прямих підключень до сервісної моделі доступу до даних. Розповім про стадії переходу, bottlenecks і про те, як ізоляція вплинула на підтримку інфраструктури. Чесно покажу, що спрацювало, а що — ні. Словом, розберемо всю контроверсійність цієї теми.

In this presentation I will try to analyze the experience of using pgbouncer and other database proxies at prom.ua. What profit does it bring in organizational sense, what new flexibility it gives to the infrastructure and everyday maintenance and scaling, which additional enchancements we managed to implement and test, what worked and what did not.

В цій доповіді я спробую проаналізувати досвід використання pgbouncer і побічно інших проксі до бази даних в проекті prom.ua. Яку вигоду несе використання проксі в організаційному плані, яку гнучкість додає інфраструктурі в процесі підтримки та масштабування, які додаткові покращення ми змогли розробити та протестувати, що запрацювало і що ні.

Під час виступу Микита поділиться досвідом Solidgate у побудові високопродуктивної фінтех-платформи з таргетом на високий аптайм, використовуючи SaaS рішення від AWS. Він розкриє еволюційний шлях масштабування від однієї RDS Postgres до 100+ RDS/Aurora з безшовними оновленнями для кінцевих користувачів, поділиться нюансами взаємодії з “managed” рішенням та потенційними прихованими витратами на обслуговування, щоб відповідати вимогам продукту і надавати краще технічне рішення.

Уявіть, що ви проєктуєте B2B-сервіс, який має обслуговувати мільйони компаній. Цей сервіс матиме десятки різних мікросервісів зі своїми даними, де можуть бути мільйони записів. Як спроектувати таку базу? Чому шардинг не завжди вихід? Які ще можливі варіанти такого архітектурного рішення? Розповім про те, як ми в Uspacy прийшли до обслуговування тисяч дрібних баз замість декількох великих, з чим зіштовхнулися і з чим ще плануємо зіштовхнутися)