3 ms·

Highly recommend reading Designing Data-Intensive Apps [1] and Monolith to Microservices [2]. I can't remember which (maybe both?) but I definitely took away th

Highly recommend reading Designing Data-Intensive Apps [1] and Monolith to Microservices [2]. I can't remember which (maybe both?) but I definitely took away the idea that if services share a DB, that DB's schema is now a public interface and becomes much more difficult to evolve with new requirements. [1] https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321 https://www.amazon.com/Designing-Data-Intensive-Applications... [2] https://www.amazon.com/Monolith-Microservices-Evolutionary-Patterns-Transform/dp/1492047848 https://www.amazon.com/Monolith-Microservices-Evolutionary-P...

JamesBarney 8mo ago
The old school solution to this is have different schema in your database, and have views as the cross team public interface.
__turbobrew__ 8mo ago
The way I think of it is that a DB should only be accessed by a single replicaset in k8s. Only processes of identical code should share the DB. Everything else is through RPC interfaces. This is how large scale systems are built, but the pattern makes less sense the smaller your footprint is.