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