Week Preview
Week 6 Preview: Designing a Notification Platform
🎯 One System, Five Days, Complete Mastery
Week 6 Philosophy
Unlike Weeks 1-5 where each day covered a new concept, Week 6-8 are immersive practical weeks. We take ONE complex real-world system and spend the entire week designing it end-to-end.
┌────────────────────────────────────────────────────────────────────────┐
│ WEEK 6-8 APPROACH │
│ │
│ WEEKS 1-5: Learn concepts │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Day 1│ │Day 2│ │Day 3│ │Day 4│ │Day 5│ │
│ │Topic│ │Topic│ │Topic│ │Topic│ │Topic│ │
│ │ A │ │ B │ │ C │ │ D │ │ E │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │
│ │
│ WEEKS 6-8: Apply concepts to ONE real system │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ NOTIFICATION PLATFORM │ │
│ │ Day 1 Day 2 Day 3 Day 4 Day 5 │ │
│ │ Problem Core Advanced Scale & Operations │ │
│ │ & Design Flows Features Edge Cases & Interview │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
Why Notification Platform?
A notification platform is the perfect teaching system because it touches EVERYTHING:
CONCEPTS FROM WEEKS 1-5 APPLIED:
Week 1 (Data at Scale):
├── Partitioning notification queues
├── Replication for delivery guarantees
├── Rate limiting per user/channel
├── Hot key handling (celebrity notifications)
└── Session management for push tokens
Week 2 (Failure-First Design):
├── Timeout management with external providers
├── Idempotency for duplicate prevention
├── Circuit breakers for failing providers
├── Retry strategies per channel
└── Dead letter handling
Week 3 (Messaging & Async):
├── Queue vs stream for notification pipeline
├── Transactional outbox for reliable publishing
├── Backpressure from external providers
├── Dead letter queues for failed notifications
└── Audit logging for compliance
Week 4 (Caching):
├── User preference caching
├── Template caching
├── Device token caching
├── Rate limit counter caching
└── Provider health caching
Week 5 (Consistency & Coordination):
├── Consistency for preference updates
├── Saga for multi-channel notifications
├── Workflow orchestration for complex flows
├── Conflict resolution for preference sync
└── Leader election for batch processors
The Problem Statement
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ Design a Multi-Channel Notification Platform ║
║ ║
║ You're building the notification infrastructure for a fintech ║
║ super-app (like Revolut, Cash App, or PayTM). Users receive ║
║ notifications about: ║
║ ║
║ • Transactions (payments, transfers, refunds) ║
║ • Security alerts (login, password change, suspicious activity) ║
║ • Marketing campaigns (promotions, new features) ║
║ • Reminders (bills due, low balance, scheduled payments) ║
║ • Social (friend requests, splits, payment requests) ║
║ ║
║ Channels: Push, Email, SMS, In-App, WhatsApp ║
║ ║
║ Scale: ║
║ • 50M users ║
║ • 500M notifications/day ║
║ • 10M notifications/hour during campaigns ║
║ • 99.9% delivery SLA for critical notifications ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
Week 6 Daily Breakdown
Day 1: Problem Understanding & High-Level Design
Theme: "Before you solve it, understand it deeply"
WHAT WE'LL COVER:
1. INTERVIEW APPROACH
├── How to clarify requirements (with sample dialogue)
├── Functional vs non-functional requirements
├── Asking the RIGHT questions
└── Establishing constraints and priorities
2. DOMAIN DEEP DIVE
├── Notification types and their characteristics
├── Channel comparison (push vs email vs SMS vs...)
├── User preferences and consent management
└── Regulatory requirements (GDPR, CAN-SPAM, etc.)
3. BACK OF ENVELOPE ESTIMATION
├── Traffic patterns (steady state vs campaigns)
├── Storage requirements
├── Provider costs and limits
└── Infrastructure sizing
4. HIGH-LEVEL ARCHITECTURE
├── Component identification
├── Data flow design
├── Technology choices with justification
└── API design (ingestion, preferences, status)
5. SCHEMA DESIGN
├── Notification schema
├── User preferences schema
├── Delivery status schema
└── Audit log schema
WEEK 1-5 CONCEPTS APPLIED:
• Partitioning strategy (Week 1)
• Queue vs stream decision (Week 3)
• Consistency model for preferences (Week 5)
Day 2: Core Notification Flow
Theme: "The happy path must be bulletproof"
WHAT WE'LL COVER:
1. NOTIFICATION INGESTION
├── API design for sending notifications
├── Validation and enrichment
├── Priority classification
└── Idempotency handling
2. ROUTING AND CHANNEL SELECTION
├── User preference lookup
├── Channel eligibility rules
├── Fallback channel logic
└── Time-zone aware delivery
3. QUEUE ARCHITECTURE
├── Topic/partition design
├── Priority queues
├── Per-channel queues
└── Ordering guarantees
4. PROVIDER INTEGRATION
├── Provider abstraction layer
├── Push: FCM, APNs integration
├── Email: SendGrid, SES integration
├── SMS: Twilio, SNS integration
└── WhatsApp: Business API integration
5. DELIVERY TRACKING
├── Status state machine
├── Delivery receipts and callbacks
├── Bounce handling
└── Read receipts (where available)
6. IMPLEMENTATION
├── Complete code for notification service
├── Provider integration code
├── Database operations
└── Unit and integration tests
WEEK 1-5 CONCEPTS APPLIED:
• Transactional outbox (Week 3)
• Idempotency patterns (Week 2)
• Rate limiting (Week 1)
• Timeout management (Week 2)
Day 3: Advanced Features
Theme: "The features that separate good from great"
WHAT WE'LL COVER:
1. TEMPLATE SYSTEM
├── Template storage and versioning
├── Personalization and variables
├── Localization (i18n)
├── A/B testing support
└── Template preview and validation
2. BATCHING AND DIGESTS
├── When to batch (trading notifications)
├── Digest generation (daily summary)
├── Smart batching algorithms
└── User-configurable digest preferences
3. SCHEDULING AND DELAYED DELIVERY
├── Scheduled notifications
├── Time-zone aware scheduling
├── "Best time to send" algorithms
├── Reminder workflows
└── Cancellation handling
4. MULTI-CHANNEL ORCHESTRATION
├── Saga pattern for multi-channel
├── Fallback chains (push → SMS → email)
├── Escalation workflows
└── Channel coordination
5. USER PREFERENCE MANAGEMENT
├── Preference hierarchy (global → category → channel)
├── Quiet hours / Do Not Disturb
├── Frequency capping
└── Unsubscribe handling
6. REAL-TIME FEATURES
├── In-app notification center
├── WebSocket delivery
├── Read/unread state sync
└── Notification grouping
WEEK 1-5 CONCEPTS APPLIED:
• Saga pattern (Week 5)
• Workflow orchestration (Week 5)
• Caching strategies (Week 4)
• Conflict resolution for preferences (Week 5)
Day 4: Scale, Reliability & Edge Cases
Theme: "What breaks at scale? Everything."
WHAT WE'LL COVER:
1. SCALING CHALLENGES
├── Campaign mode (10M notifications in 1 hour)
├── Hot user problem (celebrity with 1M followers)
├── Provider rate limits
└── Database bottlenecks
2. RELIABILITY PATTERNS
├── Circuit breakers per provider
├── Retry strategies with backoff
├── Dead letter queue processing
├── Provider failover
└── Graceful degradation
3. EDGE CASES (THE HARD STUFF)
├── User uninstalls app mid-notification
├── Phone number/email changes
├── Device token rotation
├── Duplicate device registrations
├── Time zone edge cases (DST)
├── Provider outages
├── Partial delivery (multi-channel)
└── Race conditions in preferences
4. FAILURE SCENARIOS
├── Database failure
├── Queue failure
├── Provider failure (all channels)
├── Network partition
└── Cascading failures
5. DATA CONSISTENCY
├── Exactly-once delivery (is it possible?)
├── At-least-once with deduplication
├── Preference consistency across devices
└── Status consistency
6. COST OPTIMIZATION
├── Provider cost comparison
├── Batching for cost reduction
├── Smart channel selection
└── Reducing unnecessary notifications
WEEK 1-5 CONCEPTS APPLIED:
• Circuit breakers (Week 2)
• Backpressure handling (Week 3)
• Dead letter queues (Week 3)
• Hot key mitigation (Week 1)
• Leader election for processors (Week 5)
Day 5: Operations, Monitoring & Interview Mastery
Theme: "Ship it, run it, ace the interview"
WHAT WE'LL COVER:
1. OBSERVABILITY
├── Key metrics (delivery rate, latency, cost)
├── Distributed tracing setup
├── Log aggregation
└── Custom dashboards
2. ALERTING STRATEGY
├── SLOs and SLIs definition
├── Alert hierarchy (critical/warning/info)
├── On-call runbooks
└── Incident response
3. OPERATIONAL TOOLING
├── Admin dashboard features
├── Notification search and debugging
├── Manual retry interface
├── Provider health dashboard
└── Cost monitoring
4. DEPLOYMENT & ROLLOUT
├── Canary deployment
├── Feature flags for new channels
├── Database migrations
└── Rollback procedures
5. INTERVIEW WALKTHROUGH
├── Complete 45-minute interview simulation
├── Common interviewer questions
├── How to handle curveballs
├── Trade-off discussions
└── What NOT to say
6. REAL-WORLD CASE STUDIES
├── How Uber built their notification platform
├── How Slack handles notifications
├── How WhatsApp scaled messaging
└── Lessons from production incidents
7. COMPLETE SYSTEM SUMMARY
├── Architecture diagram (final)
├── Component interaction matrix
├── Decision log with rationale
└── Future improvements roadmap
WEEK 1-5 CONCEPTS APPLIED:
• All concepts integrated
• Full system thinking
• Production readiness
What Makes This Week Different
1. Interview-Focused Approach
Each day includes dialogue showing HOW to present in an interview:
EXAMPLE FROM DAY 2:
**Interviewer**: "Walk me through how a notification gets sent."
**You**: "Let me trace a transaction notification end-to-end.
First, when a payment completes, the payment service publishes a
PaymentCompleted event. I'd use the transactional outbox pattern
here — we write the event to an outbox table in the same transaction
as the payment, then a separate process publishes to Kafka.
The notification service consumes this event and..."
2. Production Reality
We don't just design — we discuss what ACTUALLY breaks:
EXAMPLE FROM DAY 4:
EDGE CASE: Device Token Rotation
Problem:
iOS rotates device tokens periodically
Old token stored in our database
Push notification fails with "InvalidToken"
If we just retry:
Same failure, wasted resources
User never gets notification
Production solution:
1. Detect InvalidToken response
2. Mark token as invalid in DB
3. Route to fallback channel (email/SMS)
4. When app opens next, register new token
5. Have background job to clean stale tokens
3. Complete Implementation
Not pseudo-code — production-ready patterns:
# Example from Day 2: Provider abstraction
class NotificationProvider(ABC):
"""Base class for notification providers."""
@abstractmethod
async def send(self, notification: Notification) -> DeliveryResult:
"""Send notification through this provider."""
pass
@abstractmethod
async def check_health(self) -> HealthStatus:
"""Check provider health."""
pass
@abstractmethod
def get_rate_limit(self) -> RateLimit:
"""Get current rate limit info."""
pass
class FCMProvider(NotificationProvider):
"""Firebase Cloud Messaging provider."""
async def send(self, notification: Notification) -> DeliveryResult:
# Full implementation with error handling,
# retries, token validation, etc.
...
4. Edge Case Exhaustiveness
Every edge case you might face in production OR interviews:
EDGE CASES WE'LL COVER:
Notification Creation:
├── Duplicate notification requests
├── Invalid user ID
├── User doesn't exist
├── Missing required fields
├── Template not found
└── Invalid channel specified
Delivery:
├── Invalid device token
├── Expired device token
├── User unsubscribed
├── Provider timeout
├── Provider rate limited
├── Provider returns unknown error
├── Partial multi-channel delivery
└── Network failure mid-delivery
User State:
├── User deletes account mid-notification
├── User changes email during send
├── User in multiple time zones
├── User preferences change during send
├── User blocks sender
└── User marks as spam
System:
├── Database failover during write
├── Kafka partition rebalance
├── Worker crashes mid-processing
├── Clock skew between services
├── Memory pressure
└── Provider certificate expiry
Concepts Mapping
Here's how Week 1-5 concepts map to Week 6:
┌─────────────────────────────────────────────────────────────────────────┐
│ CONCEPT APPLICATION MAP │
│ │
│ CONCEPT │ WHERE APPLIED IN NOTIFICATION PLATFORM │
│ ────────────────────────────┼─────────────────────────────────────────│
│ │ │
│ WEEK 1: DATA AT SCALE │ │
│ Partitioning │ Kafka topics by priority/channel │
│ Replication │ PostgreSQL replicas for reads │
│ Rate Limiting │ Per-user, per-channel, per-provider │
│ Hot Keys │ Celebrity notifications fan-out │
│ Session Store │ Device token management │
│ │ │
│ WEEK 2: FAILURE-FIRST │ │
│ Timeouts │ Provider API timeouts │
│ Idempotency │ Deduplication keys │
│ Circuit Breakers │ Per-provider circuit breakers │
│ Retries │ Exponential backoff for failures │
│ │ │
│ WEEK 3: MESSAGING │ │
│ Queue vs Stream │ Kafka for notifications pipeline │
│ Transactional Outbox │ Reliable event publishing │
│ Backpressure │ Provider rate limit handling │
│ Dead Letter Queue │ Failed notification handling │
│ Audit Log │ Notification audit trail │
│ │ │
│ WEEK 4: CACHING │ │
│ Cache Patterns │ User preferences cache │
│ Invalidation │ Preference change propagation │
│ Thundering Herd │ Template cache warming │
│ Multi-Tier │ Local + Redis + DB │
│ │ │
│ WEEK 5: COORDINATION │ │
│ Consistency │ Preference read-your-writes │
│ Saga │ Multi-channel delivery │
│ Workflow │ Complex notification flows │
│ Conflict Resolution │ Preference sync across devices │
│ Leader Election │ Batch processor coordination │
│ │ │
└─────────────────────────────────────────────────────────────────────────┘
Expected Outcomes
By the end of Week 6, you will:
✓ Design a notification platform from scratch in 45 minutes
✓ Handle ANY edge case interviewer throws at you
✓ Explain trade-offs with confidence
✓ Write production-quality code for key components
✓ Debug notification delivery issues
✓ Understand real-world notification systems (Uber, Slack, etc.)
✓ Size infrastructure correctly
✓ Design monitoring and alerting
✓ Handle multi-provider failover
✓ Implement preference management correctly
Ready to Start?
Day 1 begins with understanding the problem deeply and creating the high-level design.
We'll approach it exactly as you would in an interview — clarifying requirements, estimating scale, and making initial architecture decisions.
Let's build a world-class notification platform! 🚀
Week 6 of the System Design Mastery Series