Inkwell Blogs. Readers vastly outnumber writers, and the most popular posts also get edited the most.

What it does

• Read: a reader opens a post.
• Write: an author edits a post.

Workload

A steady 12 000 rps, 95% reads / 5% writes, for 20 seconds, over 100 000 posts. Popularity is skewed (Zipfian).

The rule

In this problem, database nodes go up to the medium tier. That's vertical scaling hitting its ceiling, which every real system eventually does. One medium node serves about 8 000 reads per second here when it's flat out, so this time you can't just buy a bigger one.

Read replicas

A read replica is a copy of the database that serves reads. Every write still goes to the primary, which then copies it to each replica. That copy takes a little while (about 20 ms here): this delay is replication lag.

Set Read replicas on the database to add them. Reads are spread across the replicas, which takes most of the read load off the primary.

Tiers

• Easy: stays up. Almost every request succeeds. Add enough replicas, and remember the app tier needs room for 12 000 rps too.
• Medium: authors see their own edits. Right after saving, an author reloads the post. If that read lands on a replica that hasn't caught up, they see their old text. This is called a read-your-writes violation.

Hints

• The database's Read routing setting can send reads of recently written rows to the primary, which always has the latest version. It costs some primary capacity; check the database's Metrics to see where the load goes.