Shared-Data Pattern
In the shared-data pattern, multiple components access data through a common data store. No single component is entirely responsible for the data or data store. This pattern is particularly useful when multiple components require a large amount of data. With shared-data systems, data and the data source is the primary medium of interaction. Compare this to event-based systems in which components communicate via procedure calls or message passing. See the table.
Category | Component & Connector |
Elements |
Data store—holds the data shared among accessors. Choice of the data store and the constraints placed on it determine the quality attributes achieved with the pattern. Data accessor component—components that use the data in some way. |
Relations |
Reads—indicates that a data accessor component may read data from the shared-data store. Some read relations might require specific protocols or place limits on the amount or types of data that can be read. Writes—indicates that a data accessor component writes data to the shared-data store. Write relations can be transactional, throttled, protected, or otherwise constrained in a variety of ways. |
Rules for Use | Only data accessors may interact with the shared-data store. |
Strengths | Promotes reliability via data consistency, security, and privacy. Scalability and availability are also promoted when the data store is tuned well and data accessors are thoughtfully partitioned. |
Weaknesses | The shared-data store creates a single point of failure, which can harm availability and performance. Maintainability can be harmed if the data store changes, since all data accessors may be required to change as well. This pattern is simple to implement and prone to abuse. Sharing data can solve many problems, but depending on the context other architecture patterns could be a better fit. |
The following diagram shows an example of a shared-data pattern.
The shared-data pattern blends well with other patterns. Many large information systems will use this pattern somewhere within the architecture.