Read-heavy versus write-heavy workloads

01A ratio needs a cost model

A feed receives many page reads and fewer reactions. Calling it “99% reads” counts requests, but does not tell us how much work each causes.

• A read-heavy workload reads much more often than it changes records.
• A write-heavy workload spends much of its work accepting or changing records.
• One page request may load 20 profiles; one reaction may update several display totals, indexes and replicas.
• One broad scan can cost more than thousands of keyed reads. One viral article can overload one partition while other machines are mostly idle.

For every important operation, name the records examined, bytes transferred, required completion time and failures the saved result must survive. Then measure which resource is full.

Caching, indexes and read replicas can help some read loads. Efficient appends, partitions and batching can help some write loads. They are possible responses to measured work, not mandatory templates inferred from the ratio alone.

02Count amplification on both paths

Follow both sides of the article feed:

1. A reader requests a page. If the application loads 20 profiles, that one user operation causes 20 profile lookups. This extra underlying read work is read amplification.
2. A writer edits a post or adds a reaction. The source record may also require updates to indexes, copied display views, logs and replicas. This extra work is write amplification.
3. Count the logical storage operations first. Physical disk work can differ because the storage engine buffers, compresses or rewrites data.
4. Measure popular keys and partitions. Cluster-average spare capacity does not help a single record whose updates must pass one saturated owner.

A copied display result is often called a projection. Name its original records and how it is rebuilt; it is not another independent way to change the source facts.

03Worked example: reactions and article reads

Assume 100,000 article reads/s and 1,000 edits/s. At an assumed 98% cache hit rate, about 2,000 reads/s still need the source, plus refresh work.

Follow an edit to popular article 42:

1. Save the new article version and pending work for required display copies.
2. Retain the new version as the minimum allowed cache version, even if removing the value. A fill compares its loaded version with that minimum in the same cache operation that saves it; an older delayed reader then cannot restore the previous article.
3. Readers now missing that article share one compatible source fetch where possible, instead of all loading it separately.
4. Measure the hit rate under these edits. Frequent invalidation can defeat the original 98% reuse assumption.
5. Test cache failure. Up to 100,000/s could reach the source: 50 times the normal 2,000/s miss rate. Limit that fallback workload before it overloads storage.

Now accept 20,000 reactions/s and update four display views for each. That is 80,000 logical view updates/s before source writes, replicas and retries. Removing one unused view saves 20,000 updates/s. A queue can delay these writes, but sustained processing must still catch arrivals or waiting work grows.

If each account may react only once per article, enforce a unique account/article record in the reaction store. The display count may update later if allowed. Splitting or approximating that count must not permit duplicate saved reactions. The source rule and the display's delay answer different questions.

04Choose a bottleneck-specific response

Optimize the demonstrated bottleneck:

• For reads: inspect the query, page size and batched lookups before adding copies. Cache only where reuse is useful; for an edit confirmation, pass the saved edit version and use a source whose query-visible version is at least that number.
• For writes: remove unused indexes or views, batch only within the allowed delay, and spread genuinely independent records.
• For a popular single key: explain why spare machines can or cannot share that exact operation. Adding unrelated partitions is not automatic relief.
• For recovery: returning workers must process old work alongside current traffic. Limit catch-up concurrency and track the oldest pending update.
• For every comparison: test normal, burst and failure loads, with the same correctness rules.

In an interview, count the storage work behind one page and one reaction. Then change popularity or disable the cache. A read/write percentage becomes useful only when attached to this concrete cost and failure model.