4 ms·
> As any good architect will say in response to a design question, “It depends.” I absolutely agree with that. However I don't like being strawmanned. I never
by taffer 8y ago
> As any good architect will say in response to a design question, “It depends.”
I absolutely agree with that. However I don't like being strawmanned. I never said linux configuration "should be in a relational database". I said I'd like to have my data in one place to reduce complexity and decoupled from the layers above.
- gcufhg 8y agoYou can for the start use a single database as long as the different services don't use / know about each others tables. Then again you could just use separate db's.
- taffer 8y agoSure, but as I said, if you split your database, you have to deal with transactions, joins, consistency, over- / underfetching. All this leads to complexity and performace issues you wouldn't have otherwise.
- ChicagoDave 8y agoReliable messaging and eventual consistency eliminates the need for transactions. Performance can be a mitigating factor. Joins are for reporting. In the cloud, performance is just a cost factor.
- taffer 8y agoEventual consistency makes everything even more complicated and I am by far not the only one who says so [1]. [1]: https://cloud.google.com/blog/products/gcp/why-you-should-pick-strong-consistency-whenever-possible https://cloud.google.com/blog/products/gcp/why-you-should-pi...
- tyldum 8y agoAgreed. One DB to focus resiliency on, but every table or database is owned by a single service and managed using migrations. You can optimize that away later if necessary.