How to Serve Thousands of Databases from One Microservice Without Losing Your Mind
summary
The talk examines designing a B2B microservice architecture to serve millions of tenant companies and millions of records, comparing many small per-tenant databases versus a few large ones. It explains why sharding isn't always the right choice, describes Uspacy’s decision to manage thousands of small databases in a single microservice, the challenges they encountered, and issues they expect going forward.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:06Separate databases early
- 3:17Scalability to millions
- 6:05Geo-separation laws
- 7:48MySQL on Aurora
- 9:17Database architecture options
- 12:32Rejecting sharding NewSQL
- 17:13Multi-tenant benefits
- 19:04Multi-tenant implementation
- 22:42Space DB creation
- 24:51Request routing context
- 26:40Migrations automation
- 27:44Monitoring load balancing backups
- 28:50Multi-tenant advantages
- 30:57Multi-tenant challenges
- 32:25Future automation plans
- 33:30Q&A
related talks
30mDatabases in the Microservices World
58mDatabases in the Microservices World
47mHow to Choose a Right Database for Your Microservices?
51mData management in a Microservices world
57mBuilding Microservice Architectures
31mHarness the Power of a Single Database for Microservices
36mDo Proper Monoliths before You Do Microservices!
25mFrom Millions of Customers to Petabytes of Data: A Journey to Microservices