Shared Database
A shared database is used by several modules or services. Common tables can pair changes, permissions, and error sequences across these boundaries.
- WritersExactly one owner changes the status.
- ReadersOthers use a contract.
- EventChange request instead of direct access.
Context
Why this is important
If several modules change the same data, no one knows the valid rules anymore, and changes to the schema affect everyone at the same time. A clear writer holds status rules together. The operating sequences are distributed monolith.
This building block deals with responsibility for shared data. Module boundaries arrange business ownership; distributed monolith considers resulting operational coupling.
At a glance · Common Database as coupling
Writing authority for the order status
In the shop, several modules read order data; the order module remains the sole scribe of the order status. Shipping reports changes through a module contract.
This is how you read the picture
- Writers Box “Order module”: has status and transition rules, arrow “Write status transition” to the “Shop database”.
- Readers Box “Reports” with arrow “Request status view” to the order module.
- Event Arrow ‘Report shipping event’ from ‘shipping module’ to ‘order module’.
Wide diagram · Move laterally if necessary
Read diagram as text
- Ordering module: Possesses status and transitional rules
- Dispatch module: Provides dispatch events
- Reports: Read about released contract
- Shop database: Order status written by the owner
- Dispatch module → Ordering module: Report the shipment event
- Ordering module → Shop database: Write the status transition
- Reports → Ordering module: Status View Requests
Benefits & limitations
Helps if:
- Shared transactions and queries benefit from clear responsibility for data and schema.
- A gradual transition to separate data responsibilities requires visible access and migration rules.
Boundaries
- Unknown readers can make schema changes fail; inventory access and choose transitions with a clear retirement criterion. See Data migration.
- Common locks and loads couple runtime behaviour; measure competing workloads and separate them when bottlenecks occur.
- A module contract does not automatically replace a shared table; Distributed Monolith describes the operational consequences.
In practice
- Inventory access and data areas. Record readers, writers, jobs and migrations for each table and schema. Link each access to a business responsibility. This produces a traceable coupling map.
- Define write ownership. Identify the building block that controls the rules and changes for a business fact. Restrict other components’ direct write permissions and document permitted read contracts. This makes the authoritative data path clear.
- Control changes and load. Test schema changes with known consumers and observe locks, pools and recovery. Plan a gradual transition with a measurable completion criterion. This supports safe handling of coupling and transition.
Read the detailed explanation
A shared database is a store accessed by multiple components. A shared server with separate schemas and permissions differs from unrestricted reads and writes on the same tables. Shared transactions simplify some workflows, while schema, resources and recovery couple consumers. The central design question is Data ownership, especially when planning Data migration.
A designated writer centralises business rules and controls schema changes. Readers can use documented contracts or suitable projections. Database permissions, an access inventory and lock and load metrics expose actual dependencies. A shared database can be a deliberate transitional solution when its consequences and evolution path are clear. Schemas, owners and access rules define which tables and write permissions are shared and how tightly components are coupled.
Database per Service gives each service its own data store and is the counterpart to a shared database.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Who writes the order status in the shop database?
View the solution with justification
Write the order module via the edge “Status transition”. Shipping module and reports do not write.
ApplyingTransferred to a new situation
After dispatch, B-1042 shall be considered as ‘consigned’. How is the change going?
View the solution with justification
The shipping module reports a shipping event to the ordering module. This checks the allowed transition and writes the new status into the database.
EvaluateWeighing an alternative
The shipping module writes the status itself for simplification. What is the advantage and risk of this?
View the solution with justification
It saves the detour through the event. This bypasses the transition rules of the ordering module, and changes to the status field then affect several modules.
Explore further
These building blocks continue the thoughts of this page.
References
- Microservices.io – Shared database (opens in new tab)Describes the benefits and tying risks of a shared database.
- Microservices.io – Database per service (opens in new tab)Explains data sovereignty and alternative access routes between services.
- Microsoft – Data considerations for microservices (opens in new tab)Covers data autonomy, consistency and cross-service data access.