zaro

What is a Data Access Pattern?

Published in Data Management Patterns 4 mins read

A data access pattern defines the specific strategy or method an application or system employs to retrieve, store, and manage data, particularly concerning its interaction with the original source. The choice of a data access pattern significantly impacts how data is stored and refreshed within a system, such as a case management application.

These patterns are crucial because they dictate the trade-offs between data currency, performance, storage efficiency, and system complexity. Understanding and selecting the appropriate pattern is vital for designing robust and efficient applications.

Key Data Access Patterns

Different scenarios demand different approaches to data handling. Two common and distinct data access patterns are the System of Record pattern and the Snapshot pattern.

The System of Record Pattern

The System of Record (SOR) pattern is a method where an application directly accesses data stored in another system or application that is considered the authoritative source. This means the data is not copied or duplicated within the consuming application.

  • Direct Referencing: The application always references the external system (the "system of record") whenever the data is needed.
  • Always Current Data: A primary benefit of this pattern is that the data is always current. Since the application retrieves data directly from its source, any updates made in the system of record are immediately reflected.
  • No Data Duplication: This pattern avoids the duplication of data, reducing storage requirements and potential inconsistencies that arise from having multiple copies of the same information.
  • Considerations: While ensuring data freshness, this pattern's performance and availability are directly dependent on the external system. If the system of record is slow or unavailable, the consuming application will also be affected.

The Snapshot Pattern

In contrast, the Snapshot pattern involves copying data from an external source into the consuming application or case. This creates a local copy of the data at a specific point in time.

  • Data Copying: Data is duplicated and stored locally within the case or application.
  • Point-in-Time View: The data represents a "snapshot" from when it was copied. This means the data in the case may not always be current if the original source has been updated since the copy was made.
  • Performance and Offline Access: A significant advantage of the snapshot pattern is improved performance, as the application can access data locally without relying on external system calls. It also enables offline access to the data.
  • Use Cases: This pattern is suitable for historical data, auditing, or scenarios where data freshness is less critical than immediate availability or performance.
  • Considerations: Managing data freshness becomes a challenge. Mechanisms (e.g., scheduled refreshes, manual updates) are required to ensure the copied data doesn't become too stale. It also incurs additional storage overhead.

Choosing the Right Pattern

The decision between data access patterns hinges on various factors:

  • Data Freshness Requirements: If real-time, absolutely current data is critical, the System of Record pattern is preferable. If some degree of latency is acceptable, a Snapshot pattern might suffice.
  • Performance Needs: For high-performance read operations where external system latency is an issue, a Snapshot can provide faster access.
  • System Dependencies: Relying on a System of Record means your application's availability is tied to the external system. A Snapshot can decouple this dependency.
  • Storage and Complexity: Snapshots require more storage and introduce complexity related to managing data synchronization and staleness.

The following table summarizes the key distinctions between these two important data access patterns:

Feature System of Record Pattern Snapshot Pattern
Data Location Accessed directly from an external system of record Copied and stored within the local case/application
Data Freshness Always current, reflecting real-time changes Represents data at the time of copying; can become stale
Data Source Referenced directly Copied and independent from the source after copy
Key Benefit Ensures data accuracy, consistency, and real-time access Improves performance, enables offline access, provides historical views
Key Challenge Dependence on external system availability/performance Data staleness, synchronization complexity, storage overhead