Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Distributed Job Queue Platform: triggered by 'Background jobs competing with user-facing API requests for '. Gaming Backend Platform: triggered by 'Single game server instance running at connection ceiling; h'.

Migration Step 2

Both scenarios define a migration step at this stage. Distributed Job Queue Platform: triggered by 'High-priority transactional jobs (e.g., payment processing, '. Gaming Backend Platform: triggered by 'Game server instances blocking on PostgreSQL writes at end-o'.

Migration Step 3

Both scenarios define a migration step at this stage. Distributed Job Queue Platform: triggered by 'Multi-step jobs (e.g., ingest file → validate → transform → '. Gaming Backend Platform: triggered by 'PostgreSQL event log table approaching 100B rows; reconnect '.

Worker idle rate > 20% despite queue depth > 10k pending jobs; PostgreSQL pg_locks showing wait events on job table index; worker job claim p99 latency > 50ms (claim should be sub-10ms with correct indexing); CPU on PostgreSQL elevated from index scan overhead on job claim queries

Tier 1: Job Claim Lock Contention: Missing or misconfigured partial index on the job claim query; high worker concurrency driving SELECT FOR UPDATE SKIP LOCKED contention on a narrow hot page. Recommended evolution: Add a partial index on (priority DESC, created_at ASC) WHERE status = 'pending' AND run_at <= NOW(): the WHERE clause reduces the index to only claimable jobs, dramatically reducing index scan range; if contention persists, implement a job dispatch service (single dispatcher process) that batches claim queries and distributes job IDs to workers via an in-memory channel, removing per-worker database claims; tune FILLFACTOR on the job table to 70% to reduce hot page contention on SKIP LOCKED .

High-priority job queue depth growing despite workers available; low-priority batch jobs showing high throughput while transactional job latency (time from enqueue to execution start) p95 > 30s; worker pool metrics showing workers claiming jobs uniformly across priority levels rather than draining the high- priority queue first

Tier 2: Priority Inversion Under Load: Single worker pool consuming from all priority queues with equal weight; no priority-weighted polling implementation. Recommended evolution: Separate worker pools per priority tier (e.g., dedicated transactional workers for high-priority jobs, shared workers for low-priority batch); or implement priority-weighted polling in a unified worker pool (poll high-priority queue N times before polling low-priority queue once, where N is the priority weight ratio); add high-priority job execution latency as a first-class SLA metric with alerting threshold separate from batch job latency .

Game server instance file descriptor count approaching OS limit (typically 65k open connections); WebSocket accept latency increasing; new connection establishment p99 > 200ms; CPU on game server instances > 70% during peak concurrent player count

Tier 1: WebSocket Connection Ceiling per Instance: Single game server instance WebSocket connection count limit; OS-level fd_max or application-level connection accept queue saturation. Recommended evolution: Increase OS fd_max to 512k and application connection accept queue depth; tune SO_REUSEPORT to allow multiple accept threads per socket; add game server instances and update consistent hashing ring; the affinity layer automatically routes new game rooms to the new instances as the ring expands: existing rooms are unaffected .

Redis command throughput > 500k/second; Redis CPU > 60%; per-tick Redis write latency p99 > 5ms (above the acceptable state sync threshold); game tick rate visibly dropping below target (30 ticks/second falling to 20) under load

Tier 2: Redis Game State Write Amplification: Game state serialization to Redis per tick producing more writes than expected; unoptimized state struct serialization writing entire state blob on any field change. Recommended evolution: Implement delta state serialization: only changed fields are written to Redis per tick using HSET with only the modified keys, not full state replacement; profile Redis command distribution per game tick to identify specific state fields with high churn; consider moving ephemeral per-tick state (player positions, projectile states) to local server memory with only durable state (scores, inventory changes) written to Redis .