Getting Ready: Notification System

Every modern application sends notifications. When you receive a password-reset email, a shipping-status push alert, or an SMS two-factor code, a notification system is orchestrating the delivery behind the scenes. Companies like Twilio, Amazon SNS, Firebase Cloud Messaging, and OneSignal have built entire businesses around notification infrastructure.

The scale is staggering. Amazon SNS alone delivers billions of messages per day across email, SMS, push, and HTTP endpoints. Slack processes over 1.5 billion push notifications daily. Any platform with users -- from a food-delivery app to a banking portal -- needs a notification engine that can route messages through multiple channels, respect user preferences, throttle delivery to avoid spam, and prioritize urgent alerts over marketing blasts.

As an LLD interview problem, the Notification System is a pattern goldmine. It naturally requires Strategy (channel selection), Observer (event-to-notification mapping), Factory (creating channel-specific messages), and Chain of Responsibility (filtering and rate-limiting pipeline). It also introduces the Priority Queue data structure and rate-limiting algorithms -- concepts that bridge LLD and system design. This makes it one of the richest Hard-tier problems for demonstrating breadth of design knowledge in a 45-minute interview.

By the end of this design problem, you will be able to:

• Model multi-channel delivery using the Strategy Pattern -- email, SMS, and push notifications through a single unified interface
• Design a filtering pipeline with Chain of Responsibility -- rate limiting, deduplication, quiet-hours enforcement, and user-preference checks as composable filters
• Build a priority queue that dispatches critical notifications (security alerts, payment confirmations) before low-priority ones (marketing, recommendations)
• Apply the Observer Pattern to decouple event sources from notification triggers -- so adding a new event type never requires changing the notification engine
• Use the Factory Pattern to construct channel-specific notification payloads from a generic template
• Create UML diagrams -- Use Case, Class, and Sequence -- that capture the full architecture
• Implement production-quality code in Python and Java with full type safety and realistic driver examples

Before starting this problem, make sure you're comfortable with:

• OOP Relationships -- especially Composition and Association (Fundamentals S4). The notification system has deep ownership hierarchies (NotificationService owns its channel senders) and loose associations (a Notification references a User).
• Strategy Pattern -- swapping algorithms at runtime (Fundamentals S12). Each delivery channel is a strategy.
• Observer Pattern -- reacting to events without tight coupling (Fundamentals S12). Events like "order shipped" trigger notifications without the order service knowing about notification logic.
• Chain of Responsibility Pattern -- building processing pipelines (Fundamentals S12). Filters are chained to decide whether a notification should be sent.
• Factory Pattern -- constructing objects without exposing creation logic (Fundamentals S10). Different channels need different payload formats.
• UML Class Diagrams and Sequence Diagrams -- reading and interpreting them (Fundamentals S5).
• Queue data structures -- basic understanding of priority queues and FIFO ordering.

If you've completed the Logging Framework (DP5) and Pub-Sub Messaging System (DP13), you'll find familiar concepts here -- but the Notification System introduces priority ordering, rate limiting, and multi-channel routing that those problems don't cover.

We will design: The core notification engine -- domain classes for notifications, channels, templates, user preferences, a priority queue for ordering, a filter pipeline for rate limiting and deduplication, and a service layer that ties everything together.

We will NOT design: Database schemas, REST APIs, distributed message brokers (Kafka, RabbitMQ), push notification vendor integrations (APNs, FCM), actual SMTP/SMS gateway calls, or horizontal scaling. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

In scope:

• Multi-channel delivery (Email, SMS, Push)
• Notification templates with placeholder rendering
• User notification preferences (opt-in/opt-out per channel)
• Priority-based queuing (CRITICAL, HIGH, MEDIUM, LOW)
• Rate limiting per user per channel
• Deduplication of identical notifications within a time window
• Quiet-hours enforcement

Out of scope:

• Delivery receipts and retry logic (system-level concern)
• Vendor-specific API integration
• A/B testing of notification content
• Analytics and click tracking
• Batching and digest emails

Before we start designing, let's understand what happens when a real application sends a notification:

1. Event occurs -- A user places an order, a payment fails, or a friend sends a message. The originating service emits an event.
2. Event-to-notification mapping -- A notification rules engine determines which notification template to use and who the recipients are. A single event (e.g., "order shipped") may trigger notifications to the buyer (push + email) and the seller (email only).
3. Template rendering -- The generic template ("Your order {{orderId}} has shipped") is populated with event-specific data to produce the final message body.
4. Filtering pipeline -- Before sending, the system checks: Has the user opted in to this channel? Is the user within their rate limit? Is it quiet hours? Has an identical notification been sent recently? Each check can suppress the notification.
5. Priority queuing -- Notifications that pass all filters are enqueued with a priority. Security alerts ("suspicious login detected") jump ahead of promotional messages ("50% off today").
6. Channel dispatch -- A dispatcher dequeues and routes each notification to the appropriate sender: an SMTP client for email, an SMS gateway for text, or a push service (APNs/FCM) for mobile alerts.

This pipeline architecture -- event capture, template rendering, filtering, queuing, dispatch -- is the backbone of every production notification system from Twilio Notify to Amazon SNS to in-house solutions at companies like Uber, Airbnb, and Stripe.