Notification Platform: Junior → Architect Evolution
The mandated interactive flow. Step through each rung, ask what breaks FIRST, weigh the options, and defend the chosen architecture. This is how architectural thinking is learned — not by reading a fixed design, but by tracing how it evolves under growth pressure.
Scale Evolution Timeline
Step through 6 architectural rungs, from 10K RPS to 1B RPS. At each rung, ask: what will break FIRST? Why? What options exist? Which one do we pick — and what are we accepting?
This is the reasoning cycle that separates a Junior developer ("here's an architecture") from an Architect ("here's why this architecture, why now, and what breaks next").
10K RPS — SES + SendGrid direct + Redis dedup
1. Current architecture
Where we are before growth pressure
3 apps + Postgres + Redis + AWS SES for email + Twilio for SMS + Firebase Cloud Messaging for push. Direct API calls per notification. Redis 24h dedupe key. No rate limiting, no templating, no analytics.
2. Growth trigger
What changed — the traffic/data force
MVP. 100K users. Peak 10K notifications/sec (mostly transactional: order confirmations, password resets). Each triggered by an app event.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — direct SES/Twilio/FCM works
10K notifications/sec well within SES ceiling (14/sec baseline but easily raised to 100K/sec with warm-up). Twilio 100 msg/sec baseline. FCM effectively unlimited. Redis dedup prevents obvious duplicates. p99 send: 200-800ms (external API-dominated).
SES send rate 10K/sec, Twilio 500/sec, FCM 5K/sec, dedup Redis hit rate 5% (rare duplicates), external API failure rate 2%
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Zero new infrastructure
- + Familiar SES/Twilio/FCM SDKs
- + Fast iteration
- − SES throttle can surprise (default 14/sec until you warm up)
- − No unified template management
- − No cross-channel orchestration (email + SMS + push for same event)
5. Chosen
The specific decision we're making
Do nothing — direct SES/Twilio/FCM is right at MVP
6. Trade-offs
What we're explicitly accepting to move forward
- Accept per-provider API management
- Accept no unified analytics (bounce rate, click-through per provider)
- Accept SES throttle surprises without warmup discipline
- Accept notification code scattered across services (each service calls SES directly)
7. New architecture
The system after this decision — headroom for the next 5-10x
3 apps → SES/Twilio/FCM direct + Redis dedup + Postgres for audit. Total cost: $1K/mo infrastructure + variable per-message provider fees.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS with multi-channel campaigns (email + SMS + push for same event), rate limits per provider + unified templating + orchestration become mandatory. Also deliverability: bounce rate climbs, some emails go to spam. L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Notification Platform evolution. Now try the same reasoning cycle on a system you don't know yet — pick from the Systems catalog and answer the same questions: current arch → growth trigger → bottleneck → options → chosen → trade-offs → new arch → next bottleneck. That is architecture.