Design a Social “Memories” (Lookback) Feature

Problem statement

Design a social “Memories” (lookback) feature that resurfaces a user’s old posts and photos on their anniversary — “X years ago today” — as a daily personal feed, and lets the user share or re-post those memories, while honoring every privacy restriction that applied to the original content and every restriction that exists now.

The product sounds trivial: SELECT * FROM posts WHERE user = me AND month_day(created_at) = today. At social scale it is one of the most deceptively hard read patterns in the industry, because it inverts the normal access pattern of a social network. A feed system reads recent rows for many users; a memories system must read one specific calendar day across ten years of history for hundreds of millions of users, every single morning, and then re-litigate the privacy of each candidate row before a human is allowed to see it.

Why this is distinctive

Four forces collide here. First, historical scanning: the archive is write-once-read-rarely, and each post is touched by this feature at most once per year, so the index must make the daily scan cheap (NFR1). Second, daily generation at scale: bundles must exist by the user’s local morning, which is a precompute-and-cache problem (NFR2, NFR3). Third, privacy is not a filter at write time — it is re-evaluated at surface time, because friendships, blocks, audiences, deletions, and account memorialization all change after the post was created (FR4). Fourth, quality: naïve date matching surfaces painful content (breakups, deceased relatives), so ranking and user controls decide whether the feature creates warmth or backlash (NFR4).

Public operating baseline versus design assumptions

Public evidence shows the category is real and huge. Facebook launched On This Day in March 2015 [[1]]. It evolved from the Lookback video and Say Thanks experiments into a central Memories hub [[3]]. Google Photos stores more than 4 trillion photos with 28 billion new uploads per week and builds the experience on Spanner [[17]], [[21]]. Apple shipped Memories in iOS 10 with fully on-device deep learning, performing roughly 11 billion computations per photo to curate [[35]], [[31]]. Snapchat reports more than 1 trillion Memories saved since its 2016 launch [[73]]. Facebook’s Haystack paper describes 1 billion new photos (~60 TB) per week and over 1 million images served per second at peak [[39]].

For capacity planning this answer explicitly assumes a mature platform with 500M DAU, 1.5B accounts with history, 10 years of archive, 150M posts/day and 350M photos/day created (the 350M figure matches Facebook’s public 2013 disclosure [[45]]). Unless a number is tied to a citation, it is a stated design assumption, target, or budget — not a claim about any company’s private architecture.

The two-plane architecture

1. Generation plane: a timezone-sliced nightly pipeline that scans a month-day-partitioned anniversary index, re-checks privacy, scores candidates with ML, and writes a per-user daily bundle.
2. Serve plane: a read path that fetches the bundle from a hot cache, re-validates privacy fail-closed at render time, and powers view, share, and re-post actions.

A strong interview answer keeps these planes separate: generation may lag or degrade, but the serve plane must never show a memory that fails a privacy check.