Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Content read API p99 > 100ms during peak traffic; PostgreSQL'. API Gateway Platform: triggered by 'PostgreSQL hot path query p99 > 2ms under sustained request '.

Migration Step 2

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Full-text search p99 > 500ms; inability to implement faceted'. API Gateway Platform: triggered by 'Rate limit enforcement allowing requests above the configure'.

Migration Step 3

Both scenarios define a migration step at this stage. Content Management Platform: triggered by 'Month-end content performance reports generating sequential '. API Gateway Platform: triggered by 'First Redis instance crash causing 100% gateway error rate f'.

PostgreSQL pg_stat_statements showing > 10 distinct query patterns with high call counts from the content list API path; database queries per second growing linearly with API request rate for content list endpoints (should be sub-linear with proper batch fetching); p99 for content list API > 200ms during moderate traffic

Tier 1: N+1 Query Amplification: ORM-level N+1 patterns in content relationship traversal: author fetch, category fetch, related content fetch as independent queries per article. Recommended evolution: Audit every content API response with query logging enabled and count queries per request for each content type; implement eager loading for all included relationships (JOIN for 1:1, IN-clause batch for 1:N); validate that content list endpoints produce a fixed number of queries regardless of list size (O(1) queries, not O(N)); add a query count assertion to integration tests for content list endpoints to prevent regression .

PostgreSQL read replica CPU spike correlated exactly with publish events; Redis cache hit rate dropping to near 0% immediately after publish for popular content; content API p99 spiking from < 20ms to > 500ms during the 1–3 second window after a high-traffic content item is published

Tier 2: Cache Invalidation Thundering Herd: Cache key deletion on publish triggering simultaneous cache miss stampede for all concurrent readers of popular content. Recommended evolution: Implement cache-aside with probabilistic early expiration (PER): before the cache TTL expires, a fraction of reads proactively refresh the cache value while other reads continue serving the cached value; this eliminates the hard expiry boundary that causes simultaneous misses; alternatively, on publish, write the new content value directly into the cache key before invalidating the old one (update-in-place rather than delete-and-miss) to eliminate the invalidation gap .

Redis command latency p99 > 0.5ms; gateway hot path p99 exceeding 2ms with Redis as the bottleneck (not upstream service); Redis CPU > 60% sustained; Lua script execution visible in SLOWLOG at > 0.1ms frequency

Tier 1: Redis Rate Limit Throughput: Single Redis instance processing all rate limit Lua scripts serially for all tenants across all gateway replicas. Recommended evolution: Shard rate limit counters across Redis Cluster nodes by hashing tenant_id to a cluster slot; this distributes Lua script execution across nodes proportional to tenant count; ensure tenant_id-keyed counters use hash tags ({tenant_id}) so all keys for a tenant land on the same slot and Lua scripts can operate on them atomically; do not use Redis Cluster without testing Lua script compatibility against your cluster topology first .

Tenant reports that rate limit increase takes > 30 seconds to take effect across all gateway replicas; configuration change audit log shows primary PostgreSQL write completing, but gateway replicas still routing to old backend endpoints beyond the expected cache TTL window

Tier 2: Configuration Propagation Latency: Local in-process cache TTL too long, or cache invalidation signal (Redis pub/sub or Kafka) not reaching all replicas. Recommended evolution: Implement configuration change notification via Redis pub/sub: PostgreSQL configuration writes also publish a config_invalidated event to a Redis channel; each gateway replica subscribes to this channel and flushes the affected local cache key on receipt; this reduces propagation latency from TTL duration to sub-second pub/sub delivery without eliminating the local cache that protects Redis from per-request configuration lookups .