Like most other architecture-level software problems, it comes down to baking the right layer cake. Small, focused applications at the top that integrate using a shared data access and communication infrastructure is the best of both worlds.
I've never seen a great reason to create multiple databases that support different apps, unless the applications' data access patterns are completely different and/or their data is completely unrelated (and will remain so). It's dangerous to not have a single source of truth, because read/write replication problems are a special kind of hell.
For example, at Adzerk, our delivery system (that actually renders the code that displays ads) is driven by a read-only, in-process, in-memory database because we need to maximize performance performance during ad requests. In contrast, our user interface uses a traditional RDBMS. But, the former is generated from the latter, meaning we have a single source of truth.
I think if you start writing a gossip API between your services, you're essentially re-solving database clustering. I'd rather leave that up to someone smarter than me.
I've never seen a great reason to create multiple databases that support different apps, unless the applications' data access patterns are completely different and/or their data is completely unrelated (and will remain so). It's dangerous to not have a single source of truth, because read/write replication problems are a special kind of hell.
For example, at Adzerk, our delivery system (that actually renders the code that displays ads) is driven by a read-only, in-process, in-memory database because we need to maximize performance performance during ad requests. In contrast, our user interface uses a traditional RDBMS. But, the former is generated from the latter, meaning we have a single source of truth.
I think if you start writing a gossip API between your services, you're essentially re-solving database clustering. I'd rather leave that up to someone smarter than me.