Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Search-Heavy Content Platform: triggered by 'Search query p99 > 500ms on full-text queries; faceted navig'. 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. Search-Heavy Content Platform: triggered by 'Application write latency increasing due to Elasticsearch in'. 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. Search-Heavy Content Platform: triggered by 'High write throughput (> 10k documents/min) causing segment '. API Gateway Platform: triggered by 'First Redis instance crash causing 100% gateway error rate f'.

Elasticsearch index CDC consumer lag > 10s; search results showing items that no longer exist or missing recently published items; CDC connector health dashboard showing processing rate below write rate

Tier 1: Index Freshness Degradation: CDC consumer or Elasticsearch bulk indexer not keeping pace with PostgreSQL write rate. Recommended evolution: Increase Elasticsearch bulk indexer thread count; tune bulk index batch size and flush interval; profile CDC connector bottleneck (network vs Elasticsearch write throughput vs mapping complexity) .

Elasticsearch JVM heap usage > 75% sustained; GC pause events visible in cluster logs; query p99 latency spikes during GC; cluster health showing yellow (unassigned shards during GC recovery)

Tier 2: Search Cluster Heap Pressure: Large aggregation queries or high document count per shard exceeding JVM heap budget. Recommended evolution: Increase Elasticsearch heap to 50% of node RAM (max 30GB for ZGC); reduce shard count to keep per-shard document count < 50M; disable dynamic mapping and explicitly define all field types; move to doc values for all non-analyzed fields .

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 .