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'. Healthcare Records Platform: triggered by 'HIPAA audit requirement exposed during external security rev'.

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'. Healthcare Records Platform: triggered by 'FHIR events being published to Kafka but corresponding clini'.

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'. Healthcare Records Platform: triggered by 'Facility acquisition or merger; compliance requirement for d'.

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 .

Audit log table growing at > 500K rows/day; INSERT p99 on audit_log > 20ms; autovacuum unable to keep up with dead tuple accumulation from UPDATE operations on the audit log's index pages

Tier 1: Audit Log Write Throughput: Audit log receiving one row per record access creates I/O contention with clinical record writes on the same PostgreSQL primary. Recommended evolution: Partition the audit_log table by month using PostgreSQL declarative partitioning; child partitions allow VACUUM to operate on bounded table segments without scanning the entire history; index each partition independently to keep index size proportional to partition row count rather than total log size .

pg_locks showing RowExclusiveLock waits on clinical_records or encounter_notes during shift-change peak hours; write p99 > 100ms; occasional deadlock errors in application logs correlated with concurrent addenda writes to the same encounter

Tier 2: Concurrent Encounter Write Lock Contention: Multiple clinical staff members writing addenda to the same encounter simultaneously, or two processes updating encounter status concurrently. Recommended evolution: Implement optimistic locking with an encounter version column; reject concurrent writes with a conflict error and require the client to reload and retry; this eliminates lock waits by failing fast rather than waiting; ensure the application presents a clear conflict resolution UI: in a clinical context, silent overwrites of concurrent edits are a patient safety risk, not just a data integrity issue .