Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Read-Heavy SaaS API: triggered by 'Connection pool exhaustion or p99 read latency > 200ms under'. Notification Delivery Platform: triggered by 'Notification provider latency (SendGrid, FCM) adding 200–500'.

Migration Step 2

Both scenarios define a migration step at this stage. Read-Heavy SaaS API: triggered by 'Primary CPU > 70% during peak read hours'. Notification Delivery Platform: triggered by 'Product requirement to add mobile push notifications and SMS'.

Migration Step 3

Notification Delivery Platform has a defined migration; Read-Heavy SaaS API does not at this stage.

p99 database latency rising; connection wait queue growing; requests timing out with "too many connections" or pool queue full errors

Tier 1: Connection Exhaustion: Database connection pool saturated or max_connections exceeded. Recommended evolution: Add PgBouncer connection pooler in transaction mode.

Database CPU > 80% sustained; read query p99 rising; cache miss rate stable but overall latency increasing

Tier 2: Read Throughput Ceiling: Single PostgreSQL primary saturated with read traffic. Recommended evolution: Add one or more streaming read replicas; implement lag-aware replica routing.

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 .