|
Latest articles
If you’re not a subscriber, here’s what you missed this month.
 |
A Detailed Guide to Idempotency, Delivery Semantics, and Deduplication
A Beginner’s Guide to Clocks, Causality, and Ordering in Distributed Systems
To receive all the full articles and support ByteByteGo, consider subscribing:
Every application built on stored data performs two kinds of operations against it.
A write operation records a fact, such as a new order, a changed email address, or a deleted comment. On the other hand, a read operation answers a question, such as which orders were placed this week or what should appear on a profile page. A single database on modest hardware can handle both types of operations without much trouble, and a developer need not be bothered about which operation is more common in the application’s context.
However, high traffic can change things. Let’s say a page starts to load slowly. A fix is identified, which is creating an index on the column being filtered. Now, several months later, the same page is slow again under higher load. This time the fix is a cache in front of the query. A year after that, the database saturates during peak hours. This time the fix is a read replica with reporting traffic routed to it. In principle, each fix works, but each one is needed at a different time and for a different reason.
Now, let’s assume that a user updates a profile, reloads the page, but still sees the previous value. The bug does not reproduce locally, and it disappears on its own before anyone can investigate its root cause. However, this behavior can be a direct consequence of some of the other fixes. This is because each of the previous fixes placed a copy of some data somewhere other than its source. But the copy is not updated in sync with the source update. In other words, a seemingly simple fix on the read path can impact how things appear to work on the write path.
In this article, we will look at read path and write path operations and techniques in detail. Here’s what we will cover:
Why fast reads and correct writes require opposing data structures
Precomputation and duplication, the single operation underneath every read optimization
Two different definitions of consistency, and the bugs caused by treating them as one
Indexes, denormalization, caching, read replicas, materialized views, purpose-built read stores, fan-out on write versus read, and CQRS
For each strategy, its sync mechanism, staleness window, and characteristic failure mode
Write-heavy systems, where the ratio inverts and the decisions reverse with it.
 |