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 '. 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. E-Commerce Order Platform: triggered by 'Product search p99 > 1s; faceted navigation (category + pric'. 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. E-Commerce Order Platform: triggered by 'Email/push notification provider timeouts causing checkout l'. Gaming Backend Platform: triggered by 'PostgreSQL event log table approaching 100B rows; reconnect '.

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. .

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 .