Read/Write Path Split & Cursor Pagination

Foundations

So far, each interface had one main call. Now, what if writes and reads carry different promises, a write that must be durable fast and a read that must stay stable while new data keeps arriving?

Write the write path and the read path as separate contracts. A write returns once its data is durable and lets slower derived work, such as copying into indexes, finish within a stated freshness window. A read pages through precomputed results with a cursor, a position after the last item returned, rather than a page number: when new items arrive at the front, a cursor stays put while page offsets shift.

Take a list served newest first, [i9, i8, i7, i6, i5, i4]. Page 1 returns i9, i8, i7 and cursor i7. If i10 arrives before page 2, an offset of 3 would return i7 again; starting after cursor i7 returns i6, i5, i4, with nothing skipped or repeated.

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Case Scenario

To see how separate read and write contracts work, consider a news feed like Instagram's: a user publishes a post, and followers open home to see recent posts from accounts they follow. POST /posts returns 201 once the post is durable, while GET /home?cursor= reads one page of a precomputed timeline, so a new post cannot shift page two.

Publishing and opening home are different product promises. An author needs confirmation that a post will not disappear, while a follower needs a stable page even as newer posts arrive. Treating both as one generic feed call hides those guarantees. The post call must return after durability, and home must paginate without scanning every post in the system.