In addition to what other people said, the arguments under You should consider using this pattern if are all basically "you currently have a shared database and don't feel like splitting it apart."
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 reason to split it is that as soon as you give your BI dept. free reign to query the tables for users, user_widgets, widgets, widget_metrics, widget_metrics_metadata, and half a dozen other things with one query, they will do it and lock up your production database by running some atrocious 12 hour query composed completely of select * from window_functions that you’ll be back at square one in no time.
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.
In the first paragraph, that doc echoes exactly what I explain.
> 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.
At that point it's just an argument about "what is a service"? But people typically find that using the database as an API ends up with the services so coupled that they might as well be one even if they technically run as different binaries.
It's nuanced, but it's not because there is no single owner.
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.
Depends on the use case but all physical resources are finite in some limit so you may want to distribute that load so the different domain processes can scale appropriately. When/where/how is dependent on the application you’re building.
I bailed on Noteplan when the author doubled the annual subscription price to $120. I switched from Obsidian to Noteplan because I greatly preferred the native app to Electron, but it’s not that much better to justify costing $70 per year more.
I do love how Noteplan handles daily notes, and used Shortcuts to script up my replacement app of choice to emulate my favorite bits of it.
Seems like a pretty commonly accepted pattern:
https://docs.aws.amazon.com/prescriptive-guidance/latest/mod...