Pinterest·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Pinterest system design round focused entirely on building a notification system from scratch. Pretty dense question with a lot of moving parts, and I felt like I was playing catch-up the whole time trying to cover everything they wanted.

Questions Asked (1)

Design an in-app notification system that handles real-time and persistent notifications (mentions, replies, system events), supports read/unread state, badges, and notification history, with requirements around low-latency fan-out, durability, idempotency, deduplication, and graceful degradation.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with the data model which felt like the right call but I spent way too long there.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (scale, latency, consistency) and then present a high-level architecture that separates real-time delivery (WebSocket/SSE) from persistent storage. Dive into data modeling for notifications, read/unread state, and badges, and discuss trade-offs around fan-out, idempotency, and degradation. Conclude with how you'd handle failures and ensure durability.

Pro tip: Emphasize idempotency and deduplication early, as they are critical for exactly-once semantics in notification systems and often overlooked. Also, mention using a hybrid approach: push for real-time and pull for history to balance latency and cost.

1. Clarify Requirements and Scale

Ask questions to understand expected QPS, latency targets, consistency needs, and client types (mobile/web). Define what 'real-time' means (e.g., <1s) and the scale of fan-out (e.g., millions of users).

2. High-Level Architecture

Propose a system with an ingestion service (API), a message queue (Kafka) for decoupling, a fan-out service, and a delivery layer (WebSocket/SSE for real-time, push notifications for offline). Include a persistent store (e.g., Cassandra) for history and state.

3. Data Modeling and State Management

Design schemas for notifications (user_id, notification_id, type, payload, timestamp), read/unread state (separate table or flag), and badges (counters). Discuss using Redis for fast unread counts and caching.

4. Address Key Challenges: Idempotency, Deduplication, Fan-out

Explain how to ensure idempotency (unique notification IDs, dedup cache), deduplication (hash of content+recipient), and efficient fan-out (write to recipient timelines or use pub/sub). Discuss trade-offs between fan-out on write vs. read.

5. Graceful Degradation and Reliability

Describe fallbacks: if real-time fails, fall back to polling; if queue backs up, shed load or prioritize. Ensure durability with replication and retries, and monitor with metrics (latency, error rates).

Key Points to Mention

Use of WebSockets or Server-Sent Events (SSE) for real-time delivery, with fallback to long polling.
Idempotency via unique notification IDs and deduplication using a cache (e.g., Redis) with TTL.
Data modeling: separate tables for notifications, user_notifications (with read flag), and counters for badges.
Fan-out strategies: fan-out on write (precomputed timelines) vs. fan-out on read (query on demand), and hybrid approaches.
Graceful degradation: circuit breakers, rate limiting, and fallback to pull-based retrieval.
Durability: write-ahead logging, replication, and ensuring at-least-once delivery with idempotent consumers.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.