Get under the hood of Couchbase’s architecture
A cache temporarily stores an application’s recently or frequently accessed data, and is often used to improve the performance of a mainframe or legacy database. The caching layer can be repopulated by its application or from data stored elsewhere, and is used to improve responsiveness, lower access times, support higher levels of concurrency, and reduce the cost of scaling the backend system.
The requirements of a good caching layer are simplicity and low latency, with less regard for durability to disk or varied access methods. A caching layer is typically not seen as “mission critical” since the application is still able to function if the cache is unavailable, albeit in a degraded manner.
Data Layer Examples: Couchbase, Redis, Oracle Coherence, Gemfire, Hazelcast, Memcached
Source of truth
A source of truth (SoT) refers to a data storage layer fed or populated by other sources, and is often deployed as a “single view” across siloed systems to provide one or more access patterns not otherwise available, and/or to improve performance and reduce cost.
Compared to the simpler caching layer, an SoT must have higher levels of durability and reliability as well as performance and scalability because it typically supports an aggregate of data and traffic previously shared by other systems. Schema flexibility is also important because the data is often varied in structure and must adapt readily to new or changing data sources.
Unlike a caching layer, the application built on top of an SoT is only aware of the data exposed by that layer and cannot function if this data is not available, making the SoT “mission critical.” However, unlike a system of record (below), the SoT is not the “golden master” of data and therefore not “business critical.”
The SoT is typically read-only for its applications, but must take writes either in stream or batch from the systems feeding into it. Deploying an SoT can improve customer experience, increase operational visibility, make it easier to migrate to new versions of applications, and consolidate independent applications or lines of business.
Examples: Couchbase, MongoDB™, Cassandra, DynamoDB
System of record
A system of record (SoR) very broadly refers to the storage of data that is critical to an application or entire business. From a database perspective, the SoR is the authoritative storage location for a dataset and, in order to maintain data integrity, must be the only storage location where writes are allowed.
In the past, systems of record have typically referred to mainframes or relational databases. More recently, however, those legacy database systems haven’t been able to meet the flexibility, performance, and cost requirements of modern applications. This has ushered in an era of deploying caching layers and sources of truth to mitigate these shortcomings.
The concept of a system of record is still essential, though, as an authoritative location for data to be stored and updated. An SoR must equally support reads and writes, be highly durable, and be easily scaled, replicated, and backed up. Organizations rarely use a single SoR for their entire range of data, so the SoR often doesn’t need to manage data across a wide range of formats or structures, and may not need to provide the highest levels of performance or scalability.
An SoR is, by definition, the most “business critical” of systems. Without the SoR, an application or business couldn’t function and so it must be treated with the highest level of attention possible.
Examples: Couchbase, Oracle, MySQL, Db2, SQL Server
Have an existing application and want to speed it up?
Start with Couchbase as a cache.Click to get started
Looking to create a new layer to aggregate data silos?
Add Couchbase as your source of truth.See how Comcast did it
Creating a brand new application and need a database?
Couchbase can serve as your cache, source of truth, and system of record, all in one.See How Amadeus Did It