Lesson 22Intermediate56 minAssessment-backed
Publish Subscribe Systems
Design publish subscribe systems using vendor-neutral architecture, real product constraints, and AWS/GCP/Azure implementation mapping.
What you will be able to do
Explain publish subscribe systems 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.
Publish Subscribe Systems 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 publish subscribe systems: 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 |
|---|---|---|---|
| Queue | SQS | Pub/Sub or Cloud Tasks | Service Bus queues |
| Pub/sub | SNS/EventBridge | Pub/Sub | Event Grid or Service Bus topics |
| Stream | Kinesis | Pub/Sub + Dataflow | Event Hubs + Stream Analytics |
| Failure handling | DLQ/redrive policy | Dead-letter topics/subscriptions | Dead-letter queues |
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 publish subscribe systems 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?