Design the Pins and Boards Data Model
Design the storage for pins, boards, and saves: users save pins to boards, follow boards and users, and browse a board's pins in order. Billions of pins, hundreds of millions of users, high availability.
This is really "do you know how to shard a relational model" — Pinterest's signature public engineering story. Cover: the id scheme, where objects and relationships live, how "pins on board B" and "boards of user U" stay single-shard queries, what happens transactionally on a save versus asynchronously, and the hot cases (moving pins between shards, boards with millions of pins).
Hints
Hint 1
Pinterest's actual scheme: a 64-bit id packing 16 bits of shard, 10 bits of type, and 36 bits of local id — the id itself tells you where the row lives, so routing needs no lookup service.
Hint 2
Mapping tables (from_id, to_id, sequence) live on the shard of the 'from' object, making one-to-many reads single-shard range scans ordered by sequence. No cross-shard joins, no foreign keys; the app fetches ids then batch-fetches objects through a cache.
Hint 3
Decide what's transactional: the pin insert and board→pin mapping share the board's shard and commit together; user→pins, follower fan-out, and search indexing ride a job queue afterwards.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.