Interfaces
Read path and write path are different contracts
Before you start
- Open lesson
Requirements
Estimates and APIs start from an agreed list of what the system must do.
Why it matters
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.
Example
Write the feed API
A user publishes a text post. A follower opens home and sees recent posts from people they follow.
Mental model
The idea
Keep one example in view
Write the feed API
A user publishes a text post. A follower opens home and sees recent posts from people they follow.
Keep this exact scenario and its constraint in view while you build the model.
For a text post, make POST /posts durable before 201, make POST /follows create the relationship, and make GET /home?cursor=p7 read one precomputed page so a new p10 cannot shift page two.
POST /posts inserts the text and returns 201 once that row is durable. POST /follows records the follower–author pair. Neither response waits for every reader’s home data; that work may finish within the agreed freshness window.
GET /home?cursor=p7 reads one newest-first page from the reader’s precomputed timeline and returns the next cursor. If p10 arrives before page two, starting after p7 still yields p6, p5, and p4. A numeric page offset would shift and repeat or skip an item.
Visual anchor
Write the feed API
timelines[reader] after p10 arrives
Pro
The rest of this is on Pro
The idea above is free. The walkthrough, the cost, and the practice are on Pro.