TweakCode
Design Method lessons

Interfaces

Read path and write path are different contracts

Before you start

  • Requirements

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

    Open lesson

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

0123456
p10
p9
p8
p7
p6
p5
p4
↑cursor
A new post p10 lands at the top. Page 2 starts after p7 and returns p6, p5, p4: nothing skipped, nothing repeated. Page numbers would have shifted by one.

Pro

The rest of this is on Pro

The idea above is free. The walkthrough, the cost, and the practice are on Pro.