News for hackers. Stuff that matters.

A comment on Is a shared database in microservices actually an anti-pattern?. Parent comment

Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @02:30PM (#19240122)
> 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.

[ Parent | on HN ]
Re:Is a shared database in microservices actually an anti-pa... by gcufhg on Sunday February 24, 2019 @04:05PM (#19240603)
You 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.
[ Parent | on HN ]
Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @05:16PM (#19240981)
Sure, 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.
[ Parent | on HN ]
Re:Is a shared database in microservices actually an anti-pa... by ChicagoDave on Sunday February 24, 2019 @06:26PM (#19241335)
Reliable 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.
[ Parent | on HN ]
Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @07:06PM (#19241559)
Eventual 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-pi...

[ Parent | on HN ]
Re:Is a shared database in microservices actually an anti-pa... by tyldum on Sunday February 24, 2019 @05:18PM (#19240989)
Agreed. 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.

[ Parent | on HN ]