Design a Private Social Network for Families

Medium45 min
1 / 30
understanding10 min read

Problem Statement: A Trust-Bounded Memory Platform, Not a Public Feed

Frames the product as a privacy-first, invite-only family archive whose economics and invariants differ from public social networks.

Problem statement

Design a private, invite-only social platform where families share photos, videos, updates, diaries, event calendars, and genealogical data. Membership is strictly code- or invite-based; there is no public discovery, no advertising, and no third-party data sharing. The platform must protect personal media, moderate appropriately across adult and child accounts, and preserve precious memories with backup and archive guarantees that outlive any single device or account.

This is not a smaller public network. A public network optimizes for reach, growth, and engagement; a family network optimizes for trust, durability, and privacy. The fan-out graph is tiny (a family averages a dozen members, not millions of followers), so the classic public-social bottleneck (feed fan-out at celebrity scale) disappears, and three other problems take its place: exclusive membership and consent, confidentiality of deeply personal media, and multi-decade durability of irreplaceable content.

Why the problem is distinctive

  1. Tiny fan-out, huge durability. A photo may be read by twelve people, but it must remain readable for thirty years. Write-once-read-rarely media dominates storage, while write-rate dominates cost.
  2. Privacy is the product. Every URL, cache, log, and derivative must respect a family boundary. A single leaked media URL is a product-ending event, not a metric blip.
  3. Multi-generation users. Adults, teens, and children share one space with different rights. Moderation is not spam filtering; it is guardianship, consent, and safety policy enforced by the architecture.
  4. Memories are non-recreatable. Loss of a family video is irreversible, so durability, backup, export, and legacy succession are first-class requirements, not ops afterthoughts.

The four architectural planes

  1. Identity and membership plane: invites, codes, roles, guardianship, device trust, departure and memorialization.
  2. Media and memories plane: upload, encryption, derivatives, dedup, tagging, albums, vault, archive.
  3. Family knowledge plane: event calendars, family tree and genealogy, diaries, threads and boards.
  4. Safety and governance plane: child-safety policy, reporting, moderation tooling, audit, compliance, backup and export.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. FamilySearch reports a shared tree with over a billion person profiles and billions of searchable historical records; MyHeritage reports roughly one hundred million users and a 2018 breach that exposed email metadata; Google Photos has publicly described tens of billions of stored photos and billions of uploads per day; WhatsApp serves over two billion users with end-to-end encryption. These are cited, company-reported figures and provide context only. Unless a number is tied to a citation, it is an explicit design assumption for our fictional platform.

For capacity planning this answer assumes 20 million registered members across 2 million family networks, 4 million DAU, 800 thousand media uploads per day, and a 5x event peak around holidays. A strong interview answer keeps the four planes separate, leads with the privacy boundary, and labels every uncited number as an assumption.

Key Highlights

  • Private family networks invert public-social priorities: tiny fan-out, extreme durability, privacy as the core product.
  • Four planes: identity and membership, media and memories, family knowledge, safety and governance.
  • A leaked media URL is a product-ending event; all URLs must be scoped, expiring capabilities.
  • Public figures (FamilySearch, MyHeritage, Google Photos, WhatsApp) are context; all scale numbers here are explicit assumptions.
  • Assumed baseline: 20M members, 2M families, 4M DAU, 800K uploads/day, 5x holiday peak.
Lead With the Privacy Boundary
State in the first two minutes that nothing is public by default and every media access is a scoped, expiring capability. This instantly separates your design from a generic photo-sharing clone.
Do Not Design a Public Feed With a Lock Icon
Candidates often reuse public-social architecture (follower fan-out, public CDN URLs, engagement ranking). Family networks have tiny fan-out and extreme durability; the hard problems are membership, confidentiality, and archival, not viral scale.

Section Rescue Kit

Buzzwords to use:

Trust BoundaryPrivate-by-Default

Safe statements:

  • "Let me separate this from public social networks: our fan-out is tiny, but our durability and privacy obligations are extreme."
  • "Before drawing services, I will define what may never leave the family boundary."
Design a Private Social Network for Families - System Design | WinJob | WinJob