Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Two-Sided Marketplace Platform: triggered by 'Checkout failures from payment provider unavailability causi'. 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. Two-Sided Marketplace Platform: triggered by 'Listing 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. Two-Sided Marketplace Platform: triggered by 'Domain teams stepping on each other's schema migrations; dat'. Gaming Backend Platform: triggered by 'PostgreSQL event log table approaching 100B rows; reconnect '.

Redis cache miss spike visible in monitoring; PostgreSQL query rate spiking for listing reads despite stable write volume; p99 listing API latency > 500ms during traffic spike events

Tier 1: Viral Listing Thundering Herd: Cache TTL expiry on hot listings during peak traffic: all concurrent requests bypass cache simultaneously. Recommended evolution: Implement staggered TTL jitter on listing cache entries; use probabilistic early refresh (refresh before TTL expiry when remaining TTL < 20% and request rate is high); implement single-flight/request coalescing at the application layer to collapse concurrent cache misses into a single database read .

Saga compensation events appearing in order event log; checkout p99 > 2s; pg_locks showing contended rows on inventory_reservations table; idempotency key conflicts increasing in payment service logs

Tier 2: Checkout Saga Contention: Concurrent checkout transactions competing for the same inventory rows; saga timeout thresholds too aggressive. Recommended evolution: Increase inventory reservation table partition count; tune saga step timeout to 2x the observed p99 for each step under load; implement a per-listing checkout serialization queue to prevent N concurrent sagas competing for the same inventory .

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 .