Shared Database vs. Messaging Architecture

Question

I was down the pub with a friend of mine yesterday and we started discussing the architecture in use at the company he works at. The conversation basically surrounded the pr

Answer 1

I am in the process of making this very case at work. I believe there are very clear cut reasons to use one or the other (and some points that haven't been made yet).

Database integration

Pros

• Single source of truth
• Transactionality
• No new technology or middleware to manage
• Unique keys are easy

Cons

• Does not scale well. You end up with a single DB running various workloads like transactions and reporting or you end up with database replication to distribute the production load.

• Wide area distribution is difficult. Multisite architectures are even more so.

• Technology is fixed and vendor is locked in
• Hard typing in a database (assuming SQL) forces system wide updates for small changes like a changing the size of a column.

Messaging System

Pros

• Load can be distributed and specialized systems used that are optimized for various tasks
• Replacement systems can be deployed in parallel with existing systems.
• Message formats (a.k.a. network datamodel) can be versioned and multiple versions run simultaneously
• Complex wide area toplogies can be supported - e.g. multiple instances with a central hub, multiple instances with all data shared on each instance.
• Relatively easy to retrofit to legacy systems and these systems can then be integrated without a lot of work

Cons

• New system to deploy and manage in production.
• Transactionality is difficult