Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Audit and Compliance Platform: triggered by 'Compliance audit finding that audit records were modified af'. 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. Audit and Compliance Platform: triggered by 'Compliance report generation taking > 5 minutes against Post'. 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. Audit and Compliance Platform: triggered by 'SIEM consumer lag causing it to fall behind retention window'. Healthcare Records Platform: triggered by 'Facility acquisition or merger; compliance requirement for d'.

PostgreSQL write p99 > 20ms with low connection count; pg_stat_activity showing transactions serialized on the same partition's chain-tip read; ingestion throughput plateauing well below hardware limits; auto_explain showing sequential scan on audit_events for "SELECT hash FROM audit_events ORDER BY id DESC LIMIT 1"

Tier 1: Integrity Chain Write Serialization: Per-partition chain-tip read before each insert serializing concurrent audit writers. Recommended evolution: Introduce partition-level chain sequence tables: a single row per partition tracking the current chain tip with an advisory lock, eliminating the full table read. Alternatively, shard the integrity chain by source system or tenant, accepting per-shard chains rather than a single global chain. Use PostgreSQL INSERT ... RETURNING with sequence-assigned IDs to eliminate the pre-insert read entirely, deferring chain hash computation to an async integrity sealer that appends hashes in order without blocking the write path. .

Compliance investigator queries returning in > 30s; PostgreSQL showing high sequential scan counts on audit_events partitions; investigator-facing API p99 > 10s; pg_stat_statements showing actor_id-scoped queries without partition pruning in the query plan

Tier 2: Actor Query Full-Partition Scan: Missing secondary index table for actor_id and resource_id lookup paths across time-partitioned audit data. Recommended evolution: Build a secondary index table audit_events_by_actor(actor_id, event_time, event_id) populated synchronously on insert. Accept the additional write per event as the cost of O(log n) actor-scoped queries. Alternatively, route actor-scoped queries to ClickHouse where columnar storage makes actor_id filters efficient without a secondary B-tree index. .

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 .