In this blog post, we will discuss how to maintain transactional read guarantees on an async standby configured through cross cluster replication. This feature has bearing on any user who runs a transactional application in a distributed setup. We think that may apply to many people reading this blog.
MongoDB’s “schemaless” JSON data modeling was initially attractive to web app developers looking to escape the constraints of traditional relational databases, but issues with data durability and ACID transactions have been a consistent challenge. While the recent MongoDB 4.0 release includes multi-document transaction support, this post explores where the platform falls short for transactional, high performance apps.
First-generation NoSQL databases dropped ACID guarantees with the rationale that such guarantees are needed only by old-school enterprises running monolithic, relational applications in a single private data center. And the premise was that modern distributed apps should instead focus on linear database scalability along with low latency, mostly-accurate, single-key-only operations on shared-nothing storage (e.g. those provided by the public clouds).
Application developers who blindly accept the above reasoning are not serving their organizations well.
…
ACID transactions are a fundamental building block when developing business-critical, user-facing applications. They simplify the complex task of ensuring data integrity while supporting highly concurrent operations. While they are taken for granted in monolithic SQL/relational databases, distributed NoSQL/non-relational databases either forsake them completely or support only a highly restrictive single-row flavor (see sections below). This loss of ACID properties is usually justified with a gain in performance (measured in terms of low latency and/or high throughput).
…