Problem Statement: A Timezone-Correct, Privacy-First Celebration Engine
Frames the birthday system as a daily, timezone-aware fan-out problem over a social graph, not a trivial cron job.
Problem statement
Design a birthday reminder and celebration system for a large social network. The product must store each member's birthdate with per-field privacy controls, determine every day — correctly, in every member's local timezone — which of a member's friends has a birthday, deliver a timely reminder or celebration prompt, and let the friend act: post on the timeline, send a private message, send an e-card, or buy a gift. Monetization is in scope: promoted e-cards and paid gifts ride on the same reminder.
The trap is to treat this as "run a cron at midnight and email everyone." That collapses under four realities. First, birthdays are anchored to the birthday person's local calendar date, while reminders must land during a reasonable morning window in each friend's local timezone — two different clocks. Second, the social graph is enormous: hundreds of millions of members and tens of billions of friendship edges, so computing "friends with birthdays today" must avoid a full graph scan. Third, birthdate is personal data: the year is often hidden, some members hide the date entirely, and GDPR-style erasure must propagate. Fourth, the workload is a massive, idempotent, once-per-day write burst — tens of millions of notifications — that must never double-fire and must survive a scheduler crash mid-batch.
Why this problem is distinctive
A notification system can retry a push. A birthday cannot be retried: if we notify a day late, or twice, or on the wrong date because of a DST bug, the product fails in a way users notice emotionally. The design therefore separates the computation of truth ("whose birthday is it, where, and who may see it") from the act of delivery ("fan out a reminder at the right local moment"). Truth is derived, rebuildable, and idempotent. Delivery is at-least-once with a durable deduplication key so a retry can never produce a second celebration for the same birthday and the same friend.
The four architectural planes
- Identity plane: birthdate capture, storage, privacy visibility, timezone registration, and erasure.
- Truth plane: a per-day birthday index answering "who has a birthday on date D" and "which of user U's friends are in that set."
- Delivery plane: timezone-aware scheduling, notification fan-out, deduplication, throttling, and provider fallback.
- Celebration plane: timeline posts, direct messages, e-cards, gifts, and monetization attribution.
A strong answer keeps these planes separate. Truth must remain correct even if delivery is degraded, and delivery must never corrupt truth or leak a hidden birthdate through a reminder. The brief's functional requirements — store birthdates, generate daily birthday lists per user, send reminders, and prompt for gifts — map onto identity, truth, delivery, and celebration respectively, and its non-functional requirements — privacy, timezone correctness, daily-notification scale, and monetization — are the constraints that force the architecture.
Key Highlights
- •Birthdays anchor to the birthday person's local date; reminders land in each friend's local morning — two clocks per event.
- •The social graph is too large for per-day full scans; we need a precomputed, day-sharded birthday index.
- •Delivery is at-least-once with a durable dedup key: one birthday, one reminder per friend, ever.
- •Birthdate is PII with per-field visibility; a reminder must never leak a hidden date or year.
- •The four planes are identity, truth, delivery, and celebration; degrade delivery, never truth or privacy.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate computing whose birthday it is from delivering reminders, because they have different consistency and failure needs."
- "Before choosing databases, let me define which plane owns truth, delivery, and privacy."