Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'Notification provider latency (SendGrid, FCM) adding 200–500'. Multi-Tenant SaaS Platform: triggered by 'Adding a second paying customer; first audit or security rev'.

Migration Step 2

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'Product requirement to add mobile push notifications and SMS'. Multi-Tenant SaaS Platform: triggered by 'Database read load growing disproportionately with tenant co'.

Migration Step 3

Both scenarios define a migration step at this stage. Notification Delivery Platform: triggered by 'User complaints about notification volume increasing; spam c'. Multi-Tenant SaaS Platform: triggered by 'Enterprise customer requesting dedicated infrastructure in c'.

RabbitMQ queue depth for email channel growing > 100k messages; SendGrid 429 responses visible in delivery worker logs; email delivery p95 latency > 2 minutes; delivery worker retry thread pool saturated; dead-letter queue receiving messages from retry exhaustion despite provider being available

Tier 1: Provider Rate Limit Backlog: Delivery worker retry policy not aligned with provider rate limit reset window; workers retrying before the rate limit has reset, accumulating failed attempts. Recommended evolution: Implement provider-aware retry backoff: on 429 response, parse the Retry-After header and schedule the next retry attempt at exactly that time, not on a fixed exponential backoff schedule; add per-provider circuit breakers that open after 5 consecutive 429s and attempt a probe request at the retry-after interval; scale email consumer replicas to process the backlog faster when the rate limit window resets .

Kafka consumer lag for notification event consumers growing; notification delivery volume much higher than upstream business event volume (ratio > 5:1); RabbitMQ aggregate message rate across all channel queues elevated; one upstream event type (e.g., new_comment) accounting for disproportionate share of notification volume

Tier 2: Notification Fan-Out Amplification: Upstream event fan-out generating more notification sends per event than expected; or a notification rule misconfiguration triggering notifications for every event regardless of user preference. Recommended evolution: Audit notification fan-out ratio per upstream event type; add fan-out cost metrics (notifications_generated per upstream event) as a monitored SLA; implement notification preference filtering before fan-out: only generate delivery attempts for users with the corresponding notification type enabled; implement a notification aggregation layer that batches multiple low-priority events into digest notifications rather than individual sends .

PgBouncer pool wait queue > 0 during peak hours; application errors reporting "connection pool exhausted" or pool timeout; pool utilization > 90%

Tier 1: Connection Pool Exhaustion: Aggregate tenant connection demand exceeding PgBouncer pool_size. Recommended evolution: Implement per-tenant connection quotas at the application layer before hitting the pool; increase pool_size incrementally; identify top-N connection consumers by tenant and implement connection reuse within tenant request handlers .

pg_stat_activity shows one tenant's queries dominating query runtime; other tenants reporting p99 latency regression while their own query counts are stable; PostgreSQL shared_buffers cache eviction rate increasing

Tier 2: Noisy Tenant I/O Saturation: Single large tenant displacing other tenants' working sets from shared buffer cache. Recommended evolution: Implement pg_cgroups or connection-level resource groups if available; consider database-per-tenant for the top N largest tenants while keeping the shared schema for smaller tenants (hybrid isolation model) .