For many years, our corporate banking platform ran on a large, reliable monolith. Over time, however, technical debt, long release cycles, and module dependencies slowed us down. It was time to rethink. This is the story of an evolution for 150,000 clients: from running monolith and microservices in parallel to Domain-Driven Development with over 20 platform and product teams, from JSP to microfrontends and design systems, from IBM to Open Source. Key Takeaways: Why a stable monolith is no longer enough for modern banking Transition patterns that don’t disrupt business or harm clients Lessons from running monoliths and microservices in parallel Domain-Driven Development at scale: 20+ platform and product teams Microfrontends and design systems for faster delivery When Open Source is the right choice vs. when to buy

Imagine you are designing a B2B service that will serve millions of businesses. This service will have dozens of different microservices with their own data, which can contain millions of records. How do you design such a database? Why is sharding not always the answer? What other options are there for such an architectural solution? I'll tell you how we at Uspacy came to serve thousands of small databases instead of a few large ones, what we've encountered and what we plan to face)