Lesson 36Advanced1h 4mAssessment-backed
Design a Notification System
Design design a notification system using vendor-neutral architecture, real product constraints, and AWS/GCP/Azure implementation mapping.
What you will be able to do
Explain design a notification system from requirements and constraints.
Identify production trade-offs across scale, reliability, cost, and operability.
Map the vendor-neutral design to AWS, GCP, and Azure services.
Prepare an assessment-grade answer with failure modes and alternatives.
Design a Notification System is part of Mastering System Design. The lesson trains vendor-neutral architecture first, then maps the design to cloud services and production trade-offs.
Core Design Problem
This lesson focuses on the system-design decisions behind design a notification system: what the system must do, how traffic and data grow, what must remain reliable, and where complexity should or should not be introduced.
Real-World Scenario
We will ground the concept in a realistic product case, then walk through read path, write path, storage, caching, asynchronous work, observability, and failure behavior where relevant.
AWS, GCP, and Azure Mapping
| Need | AWS | GCP | Azure |
|---|---|---|---|
| Compute | ECS/EKS/Lambda | Cloud Run/GKE/Cloud Functions | Container Apps/AKS/Functions |
| Data | RDS/DynamoDB/S3 | Cloud SQL/Spanner/Bigtable/Cloud Storage | Azure SQL/Cosmos DB/Blob Storage |
| Messaging | SQS/SNS/EventBridge/Kinesis | Pub/Sub/Cloud Tasks/Dataflow | Service Bus/Event Grid/Event Hubs |
| Observability | CloudWatch/X-Ray | Cloud Monitoring/Cloud Trace | Azure Monitor/Application Insights |
Trade-Off Matrix
| Option | Use when | Risk |
|---|---|---|
| Simple single-service design | Traffic and team size are small | May bottleneck under growth. |
| Managed cloud service | Reliability and speed matter more than custom control | Cost, limits, and vendor coupling. |
| Custom distributed design | Requirements exceed managed defaults | Higher operational burden. |
Failure patternsCommon Mistakes to Avoid
- Starting with provider names before requirements.
- Ignoring write path and operational failure modes.
- Over-designing for imaginary scale.
- Skipping latency, cost, security, and observability.
- Failing to state what data must be consistent.
Execution guardrailQuick-Start Checklist
- Clarify users and core flows.
- Estimate reads, writes, storage, and peaks.
- Choose the simplest architecture that satisfies constraints.
- Name alternatives and trade-offs.
- Map to AWS/GCP/Azure only after the architecture is clear.
- Add failure handling and observability.
Interview signalFrequently Asked Interview Questions
- How would you design design a notification system for 10x traffic growth?
- Which parts should be synchronous and which should be asynchronous?
- What would you monitor, and what failure mode would page the team?