"In large Enterprises, you will inevitably be trying to get multiple services and databases to work together. The old style for dealing with this was the ESB (Enterprise Service Bus) or SOA (Service Oriented Architecture)"
You write "SOA has nothing to do with ESB" yet both are attempts at "you will inevitably be trying to get multiple services and databases to work together" which was literally the sentence before the one you are reacting to.
As to this:
"SOA has nothing to do with ESB/distributed logs/event sourcing, and none of that has to do with MongoDB or document-stores"
The point of my comment is that MongoDB is so flexible it can replace other approaches to the problem of "get multiple services and databases to work together" including ESB and SOA.
At this point, I can not think of any reason to ever use an SQL database. Either your canonical data will be in Kafka, or it can go in MongoDB. There is no need for SQL databases, ever.
About this:
"MongoDB is not a good event-sourcing system"
Obviously, which is why I included a link to the Jay Kreps essay. Kafka is better for an event-sourcing system. I'm not sure how you misread that part.
About this:
"The last part about treating a database as a cache has nothing to do with databases"
It feels like you are almost deliberately trying to misread what I wrote. My whole point was that MongoDB is so flexible, it can work as a cache, and also as a store for canonical data (in those circumstances when you are not storing your canonical data in something like Kafka).
Is that more clear?
