Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Social Feed Platform: triggered by 'PostgreSQL timeline read query p99 > 500ms; query plan for "'. 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. Social Feed Platform: triggered by 'Fan-out worker queue lag during celebrity post events > 5 mi'. 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. Social Feed Platform: triggered by 'Redis memory utilization approaching 80% of a single node; R'. Multi-Tenant SaaS Platform: triggered by 'Enterprise customer requesting dedicated infrastructure in c'.

Kafka consumer group lag for fan-out worker group growing steadily; feed propagation latency (time from post write to follower feed update) exceeding 30s p95; Redis write rate on feed keys elevated but not saturated; post activity rate normal

Tier 1: Fan-Out Worker Queue Backlog: Fan-out worker pool undersized for burst post activity or a celebrity post creating a sustained high-fan-out event. Recommended evolution: Add fan-out worker replicas; implement fan-out cost routing: route high-follower-count fan-out events to a dedicated high-cost worker pool with separate Kafka consumer group and Redis write quota; use follower count threshold (e.g., >50k followers) as the routing decision. Monitor fan-out cost per post as a first-class metric. .

Redis memory utilization > 75%; eviction rate rising; cache miss rate on feed reads increasing; cold feed read fallback queries appearing in PostgreSQL slow query log; feed read p99 > 100ms despite Redis being online

Tier 2: Redis Feed Memory Ceiling: Redis feed list storage approaching memory limit; feed items being evicted before TTL; or feed list cap set too high for available memory. Recommended evolution: Reduce feed list cap from current value toward 100–150 items; increase Redis cluster capacity or shard feed keys by user_id range across multiple Redis primaries; implement tiered feed storage: hot recent items in Redis, older items fetched from PostgreSQL on demand with explicit product UX affordance .

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) .