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'. Developer Tools Platform: triggered by 'First noisy neighbor incident where one tenant's CI burst de'.

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'. Developer Tools Platform: triggered by 'Kafka publish failures rolling back pipeline completion tran'.

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 '. Developer Tools Platform: triggered by 'Log search returning results from other tenants' pipelines d'.

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 job queue depth > 1000 correlated with a single tenant identifier; other tenants reporting p99 job start time > 60 seconds; tenant-level queue metrics showing one tenant holding > 50% of in-flight worker slots

Tier 1: Job Queue Tenant Noisy Neighbor: Shared Redis queue with shared worker pool allowing one tenant to monopolize available capacity. Recommended evolution: Implement per-tenant queue lanes in Redis (separate key namespaces per tenant, e.g., jobs:{tenant_id}:{priority}); implement a weighted fair scheduler at the worker dispatch layer that reads from tenant queues in round-robin order with priority weighting; cap the number of concurrently executing jobs per tenant to the tenant's quota, not to the total available worker count .

DDL migration duration > 10s on pipeline_runs, jobs, or artifacts tables; migration deployment causing timeout errors for active CI pipeline API calls during the deployment window; pg_locks showing AccessExclusiveLock held by ALTER TABLE statement

Tier 2: PostgreSQL Schema Migration Lock: High-volume tables requiring locking DDL changes during deployments with concurrent tenant activity. Recommended evolution: Adopt zero-downtime migration patterns exclusively: add columns with nullable defaults first (no table lock in PostgreSQL 11+), then backfill, then add constraints via NOT VALID followed by VALIDATE CONSTRAINT in a separate transaction; use pg_repack for table rewrites; never run concurrent index creation without CONCURRENTLY on any table with > 1M rows .