Design Feeds Knowing They Are Assembled

Systems & Architecture · real-time, personalization, scale

Updated 2026-08-04

Understand that a feed is built, not stored. A post is written once and then either fanned out into every follower's feed in advance or gathered on demand when someone opens the app, and each choice produces different visible behavior.
Expect the author to see their own post before anyone else does. Delivery to millions of feeds takes time, so the author's view is instant and a follower's view is not.
Give the author confirmation that does not depend on delivery. Posted should mean the post exists, not that it has reached every feed.
Design for accounts with enormous audiences separately. Their posts arrive later and their notification volume is different, so the same interface has to work at both ends of that range.
Never promise chronological order unless the system actually guarantees it. Items assembled from several sources arrive out of order, and a user who notices will trust the whole feed less.
Handle the new-items case explicitly rather than shifting content under the reader:

Expect duplicates and gaps at page boundaries, and de-duplicate on the client. A feed changing while it is being paged through will otherwise show the same item twice.
Keep engagement counts approximate and let them settle. They are gathered from many places, and a number that ticks backwards for a second is normal and looks like a bug.

A feed is a view assembled at the moment someone asks for it, and the interface should never imply it is a fixed list.