Single v. multiple data store solutions

This paper is published under the terms and conditions in the footnote.


This paper outlines ways that data representing a system’s state may be replicated in multiple data stores.


Single data store solutions. 1

Multiple data store solutions. 1

Different tiers of one client-server application. 2

Differently structured update (OLTP) and reporting (OLAP) data stores. 2

Data copies in the data storage tier of one client-server application. 2

Different databases at the bottom of different client-server applications. 2


Single data store solutions

A logical data model is a model that describes the data that must persist for the processes of a business system to work.

It is a kind of “domain model” that defines business terms and concepts.

It is a data structure that shows entities and events of importance to a business.


It is easy and natural to build a relational database to hold the data defined in a logical data model.

Many enterprise applications have been built on top of a single relational database.

It is the default data architecture for an enterprise application, and should always be considered.

Query performance can be improved (sometimes dramatically) by enabled by adding indexes and derived data.


You need good reasons to store data in a different way – instead or as well.

And those reasons are usually non-functional requirements rather than functional ones.

Multiple data store solutions

A goal of enterprise architecture is to reduce if not eliminate issues arising because different people see different versions of the same data.

Ideally, every data item important to a business would be stored in one place, or if replicated, then it would have the same value in all locations.

However, the days of the enterprise maintaining a single database appear to be behind us.


You need good reasons to replicate data in several data stores.

And those reasons are usually non-functional requirements rather than functional ones.

Data can be replicated in several data stores in various ways.

This replication creates work for enterprise and solution architects, who must attend to how the data is coordinated.

Different tiers of one client-server application

Usually, in a modern client-server system, data entry fields are checked on the client device.

And to ensure availability, the top-most tier on the server-side is scaled out.

Top-level server-side components are typically stateless or maintain only soft state (cached data).

And they must continue to work, even if lower-level components and data sources are temporarily inaccessible.

In short, the higher-level components in a client-server system may sacrifice consistency of data and responses for the sake of a faster response, and availability.

Differently structured update (OLTP) and reporting (OLAP) data stores

It can be difficult to get management information out of a database that is continually updated by on-line transactions.

The non-functional requirements can drive you to separate data stores for processing of update transactions and reporting.

And they might drive you to using “event sourcing”.

Data copies in the data storage tier of one client-server application.

Sometimes, there is a very large and/or widely distributed population of clients for the same data.

To ensure the availability of data to all clients, that data may have to be may be copied to many nodes.

The nodes may be arranged in a cluster in one location; where nodes can be synchronised with each other in microseconds.

Or else, the nodes may be widely distributed to support dispersed user populations, and synchronised over a longer timescale.

Different databases at the bottom of different client-server applications

There are very often accidental overlaps between data stores used by different business functions

Most substantial enterprises have a long history of application development and package purchases.

An outcome of this history is a messy data architecture; the same and related data is maintained in several applications, some in-house, some in the cloud.

Enterprise architects assume distributed applications, if they maintain the same or related data, should be coordinated.

Synchronisation of data in different database can be addressed by a variety of “master data management” patterns and techniques.



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           20/04/2015 17:16

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see