When learning system design, we are almost always fed the exact same doctrine: start with one API + one Database, then as traffic increases, add a Load Balancer, Redis, a Separate Database Server, and eventually Read Replicas.
The problem is that this standard pattern is built on a single assumption: every user must crowd into the same shared database. However, if your application's data characteristics allow it to be segregated per user from day one, blindly following this pattern becomes a complexity trap that makes your system increasingly fragile.
The Sin of Mainstream Architecture: Compounding New Problems
In conventional architecture, all users share the same database tables. As server load increases, a developer's first reflex is usually to add more infrastructure layers:
[User]
