Notification System

Airbnb's "Notification System" interview question focuses on designing a scalable, reliable system for delivering notifications at massive scale, often tagged with data engineering, system design, backend, event-driven architecture, batch processing, web, notifications, and machine learning elements. No single official full problem statement exists publicly from Airbnb, but aggregated from common interview reports, it typically asks candidates to architect an end-to-end system handling millions of daily notifications across channels like push, email, SMS, and in-app, triggered by events such as bookings or messages. Here's the compiled standard problem scope, examples, and constraints based on consistent descriptions.[4][6]

Problem Statement

Design a notification system for an Airbnb-scale platform (e.g., 500K+ daily bookings generating 1-1.5M notifications/day) that:

• Consumes events from upstream services (e.g., booking.confirmed, message.received, payment.success).
• Supports multiple user types (guests, hosts, employees) with personalized delivery.
• Handles multi-channel delivery (push via FCM/APNs, email via SES/SendGrid, SMS via Twilio, in-app/WebSocket).
• Ensures low-latency real-time delivery (<50ms for critical paths), reliability (99.9%+ delivery rate), and fault tolerance.
• Incorporates user preferences (opt-in/out per channel/type), templates/localization, retries, throttling, and analytics.
• Scales for peaks (e.g., 10x spikes during promotions) using event-driven (Kafka/RabbitMQ) and batch processing.[2][6][4]

Key Requirements

• Event Ingestion: Async processing from event bus.
• Personalization/ML: Use ML for prioritization (e.g., intent detection, user engagement prediction) and channel selection.
• Delivery Modes: Real-time (urgent, e.g., booking confirmations) vs. batch (non-urgent, e.g., weekly summaries).
• Storage/Logs: Metadata/logs (~300 bytes/notification, 300-450MB/day).
• Observability: Metrics for latency, failure rates, open/click rates.[2]

Input/Output Examples

No formal I/O formats like LeetCode, but design discussions use these scenarios:[4][2]

| Scenario | Input Event | User Preferences | Expected Output | |----------|-------------|------------------|-----------------| | Booking Confirmation | {event: "booking.confirmed", user_id: 123, booking_id: "ABC", timestamp: now} | Push/email on, SMS off | Push to mobile + email with template: "Hi {name}, your booking {ABC} is confirmed for {dates}." | | Host Message Reply | {event: "message.received", from_host: 456, to_guest: 123, content: "Welcome!"} | In-app + email | WebSocket in-app + email; fallback SMS if both fail after 2 retries. | | Batch Digest | Batch of 5 events (e.g., reminders) for user 789 | Batch email on, real-time off | Single email: "You have 2 new messages, 3 reminders" sent hourly. | | Peak Spike | 1M promo events in 1 hour | All channels throttled | Queue/batch 80%, prioritize top 20% urgent via ML score [2]. |

Constraints and Scale

• QPS/Volume: 1-2K QPS average, 10-20K peak; 500M+ users, 1.5M+ notifications/day.[2]
• Latency: <100ms end-to-end; <50ms for ML intent/routing.[1]
• Reliability: 99.99% uptime, no lost notifications (at-least-once delivery), GDPR/CAN-SPAM compliance.
• Data: 100TB+ logs/year; user prefs in NoSQL (DynamoDB/Cassandra).
• Cost: Optimize for $0.001/notification; cold storage for old logs.
• Edge Cases: Offline users, channel failures (retry 3x, fallback), high-volume users (throttle), localization (100+ languages).[6][4][2]