Shared Database Integration

Shared database integration is an approach in which separate applications work together by reading and writing the same database. The Enterprise Integration Patterns catalog lists it as one of four integration styles, alongside file transfer, remote procedure invocation, and messaging, and states the idea in one line: integrate applications by having them store their data in a single shared database.

Why it is attractive

The catalog is fair about the benefits. If a family of applications all rely on the same database, they are consistent with each other all the time; simultaneous updates are handled by the database’s transaction management; and because there is no delay between one application writing and another reading, errors are easier to find and fix. No interface has to be designed, no messages defined, no copies kept in sync.

Why it becomes expensive

The same page names the central difficulty: finding a schema that meets the needs of several applications is very hard, and the result is often a schema that application programmers find difficult to work with. It adds a political one. If a critical application would be delayed by having to work with the unified schema, there is strong pressure to separate — and conflicts between departments make it worse.

Underneath both is coupling. The catalog’s general criteria for integration warn that tightly coupled applications make many assumptions about how the others work, and when a change breaks those assumptions, the integration breaks. With a shared database, the assumptions are the tables themselves: every column name, status code, and nullability rule is an interface, whether anyone intended it to be or not. Common symptoms:

• A team cannot rename or restructure its own table without finding and coordinating with every reader.
• Business rules enforced in one application’s code are bypassed by another that writes to the same table directly.
• A heavy query from one consumer slows transactions for the owner.
• Nobody can say with confidence who uses a column, so nothing is ever removed.

The form it takes in data platforms

A data pipeline can recreate this coupling without anyone proposing a shared database. An extraction that queries another team’s operational tables, or captures changes from them through their database log, depends on those internal tables exactly as a second application would — it just reads a copy a little later. The source team has made no promise about those tables, and may not know the pipeline exists.

The remedy is to replace an accidental interface with a deliberate one:

• a view or export the owning team maintains as its published shape;
• events the owner publishes when data changes, for example through a transactional outbox;
• a data contract stating what consumers can rely on and how changes are announced.

Reading internal tables is still sometimes the only practical option, such as for a packaged application its owners cannot change. In that case it is worth treating as a known risk: the source team informed, the tables read listed, and changes to them watched.

How this fits among the choices for moving data between systems is worked through in Moving Data Between Systems: Copy or Call, Transform Where, and How Often.

References: Enterprise Integration Patterns, Shared Database; Enterprise Integration Patterns, Introduction to Integration Styles.