Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. E-Commerce Order Platform: triggered by 'Payment provider timeout causing full checkout rollback and '. Distributed Job Queue Platform: triggered by 'Background jobs competing with user-facing API requests for '.

Migration Step 2

Both scenarios define a migration step at this stage. E-Commerce Order Platform: triggered by 'Product search p99 > 1s; faceted navigation (category + pric'. Distributed Job Queue Platform: triggered by 'High-priority transactional jobs (e.g., payment processing, '.

Migration Step 3

Both scenarios define a migration step at this stage. E-Commerce Order Platform: triggered by 'Email/push notification provider timeouts causing checkout l'. Distributed Job Queue Platform: triggered by 'Multi-step jobs (e.g., ingest file → validate → transform → '.

PostgreSQL pg_locks showing high RowExclusiveLock contention on inventory_items for specific sku_ids; checkout p99 > 2s for contended SKUs; deadlock errors appearing in application logs during sale events; effective checkout throughput for hot SKUs well below per-request checkout latency would predict

Tier 1: Flash Sale Inventory Contention: Concurrent saga checkout attempts competing for the same inventory row via row-level locking. Recommended evolution: Introduce a per-SKU checkout serialization queue at the application layer : all concurrent checkout requests for the same SKU are queued and processed serially, converting lock contention into queue latency. Alternatively, use PostgreSQL advisory locks with non-blocking trylock: requests that cannot acquire the lock immediately return a "sold out" response rather than queuing. For very high flash sale volumes, pre-allocate inventory slots (reserve N slots per sale event, each slot is a row with one reservation) to spread lock contention across N rows instead of one. .

Checkout p99 tracking payment provider p99 almost linearly; connection pool utilization on the payment service rising during payment provider slowdowns; circuit breaker trip events appearing in payment service metrics; saga timeout events correlated with payment provider latency spikes

Tier 2: Payment Provider Latency Amplifying Checkout Latency: Checkout saga holding a database connection and an inventory reservation open for the duration of the payment provider call: payment latency directly amplifies connection pool pressure. Recommended evolution: Decouple the payment step from the synchronous checkout saga: reserve inventory and create the order record synchronously, then process payment asynchronously. The customer receives an "order confirmed, payment processing" state immediately; the payment step runs as a separate saga step triggered by an event. This reduces the synchronous checkout latency to the inventory reservation time, not the payment provider round-trip time. .

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 .