Протягом багатьох років наша платформа для корпоративних клієнтів працювала на великому, надійному моноліті. Але з часом технічний борг, повільні релізи та залежності між модулями почали гальмувати розвиток. Настав час для переосмислення. Це історія еволюції для 150 тис. клієнтів: від паралельної роботи моноліту та мікросервісів — до Domain-Driven Development із понад 20 платформеними та продуктовими командами, від JSP до мікрофронтендів і дизайн-системи, від IBM до Open Source. Ключові інсайти: Чому стабільного моноліту вже недостатньо для сучасного банкінгу Як переходити без шкоди бізнесу і клієнтам Паралельна робота моноліту та мікросервісів — практичні уроки Domain-Driven Development у масштабі 20+ команд (платформені та продуктові) Мікрофронтенди та дизайн-система для швидших релізів Коли Open Source — правильний вибір, а коли варто купити

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