What is wrong with sharing a single database between services?
Seems like a pretty commonly accepted pattern:
https://docs.aws.amazon.com/prescriptive-guidance/latest/mod...
Seems like a pretty commonly accepted pattern:
https://docs.aws.amazon.com/prescriptive-guidance/latest/mod...
The only bullet on the list which isn't related to "it currently works this way and you can't change it" is the one that says
> You want to maintain and operate only one database.
Which is frankly a terrible bullet point because the next question is "Why would someone want to do that?"
The whole list is basically just "if you have constraints that make a better design impossible then I guess you can do this"
Because for example you have BI reporting queries that need to join across schemas, and it's the most cost effective way to do that. I've seen that kind of thing both through ETL and going through normal service APIs, and both are way more expensive (in developer time and compute resources) than e.g. doing a normal db query against the slave.
A shared database will also make me effective use of resources than if you try to manually assign them to split databases.
If you need cross service transactions, it's easier to have the db do that than to implement 2pc.
The real question is why split it? If you can fit on one machine, there's not much reason not to. Like the previous poster said, you can use separate schemas or table permissions with service accounts to keep logical separation.
The other (more serious) problem is that if multiple services can edit the same data independently, eventually they will, and it will cause data loss or degradation that will be catastrophic. And, although you CAN isolate things with permissions, the chances of this reliably getting done without a lot of time put into DBA (a role which simply doesn’t exist at startups), is very low in my experience.
> You need to carefully assess the application architecture before adopting this pattern, and make sure that you avoid hot tables (single tables that are shared among multiple microservices).
Using the same database table with multiple services (micro or not) is an absolute disaster.
Are other services also restricted in the same way?
If microservices share a database, it's not clear who migrates the schema and coordinating it is nearly impossible because another piece of code in another service may be reading the old schema and break.
Sharing the database means you have a distributed monolith - you lose all independent deployability. It is the worst of both worlds.
The exception may be if you share a database instance, but each service has its own schema and only has authorization to read and write to its own schema.
That doesn't make the single database a service - it would make it shared infrastructure, however. This may bring its own maintainenance challenges but it doesn't violate any principles.