Skip to content
Software Architecture Guide

Shared Database

Explanation

Section titled “Explanation”

A shared database is an integration style. Applications built separately, even in different languages and on different platforms, store their data in one common database. Each application reads what the others wrote. This shares information rapidly and consistently.

It is one of four integration styles: file transfer, shared database, remote invocation and messaging. See the article Integration Styles for the overview. Each style is defined by what the applications exchange. Here they exchange data in a common database. Messaging goes further. It exchanges data and also invokes behavior through a common messaging system.

The schema is the hard part. The schema is the structure of the shared data. One schema must meet the needs of many applications. Designing it is a very difficult exercise. There are also political difficulties. Conflicts between departments make agreeing on a shared schema worse.

Coupling. Martin Fowler warns that the database becomes a point of coupling between all applications that access it. The coupling is deep. It makes changing those applications riskier. See Coupling and Cohesion for background.

Microservices. Microservices take the opposite view. Each service manages its own database. Enterprises, by contrast, often prefer a single database across applications. See Microservices Architecture.

Example

Section titled “Example”

A company has an order application, a billing application and a reporting tool. All three keep customer data in one common database. When a clerk updates an address in the order application, billing and reporting read the same data. If the team wants to restructure the customer data, it must involve all three applications.

Trade-offs

Section titled “Trade-offs”

Benefits

  • Applications on different languages and platforms can share information rapidly and consistently.

Costs

  • Designing one schema for many applications is very hard.
  • Agreeing on it can be political, especially when departments conflict.
  • All applications are deeply coupled through the database, so changing them is riskier.
  • Microservices avoid this by giving each service its own database.

Several applications store and read data in one common database.

Diagram source 
flowchart LR
  A[Order application] --> DB[(Shared database)]
  B[Billing application] --> DB
  C[Reporting tool] --> DB

Checks

Section titled “Checks”
  • The document names which applications share the database and states that all of them are coupled to its schema.
  • Ownership and agreement of the shared schema across teams or departments is addressed.
  • The risk of changing applications that use the shared database is acknowledged.
  • The choice of a shared database over file transfer, remote invocation, messaging or database-per-service is justified.
Section titled “Related”

Sources

Section titled “Sources”