2 ms·
If you do it that way, you don't get the famed scalability; it's still limited by the scalability of the mysql backend.
by perlgeek 11y ago
If you do it that way, you don't get the famed scalability; it's still limited by the scalability of the mysql backend.
- skrebbel 11y agoThe codebase is, however, very well structured to make that change later on. You don't need to do a lot of CQRS to make future scalability a relatively simple redesign.
- Terr_ 11y agoNot sure exactly what capability you're referring to with the "famed" scalability, but my point is that CQRS in no way requires Event Sourcing, and offers its own set of benefits. (It's also a helluva lot easier to do, or un-do.) In particular, CQRS helps you make a sane architecture for "read models", where certain features (say, a homepage showing a hard-to-calculate leaderboard) are simple queries against a data-source designed specifically for that feature. The backing data-source is kept up to date by application code as a side-effect of your "real work". This means you can substantially reduce the runtime load on the database as well as reducing how much application-logic "leaks across" in triggers/procedures/views. Since your database is often the "bottleneck of last resort", this means better scalability.