Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Geospatial Tracking Platform: triggered by 'PostGIS proximity query p99 > 100ms under concurrent fleet t'. 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. Geospatial Tracking Platform: triggered by 'Location update API p99 > 200ms correlated with geofence cou'. 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. Geospatial Tracking Platform: triggered by 'PostgreSQL location_history table exceeding 100GB with query'. Healthcare Records Platform: triggered by 'Facility acquisition or merger; compliance requirement for d'.

Redis used_memory > 75% of maxmemory; Redis evictions appearing in INFO stats; GEOSEARCH returning stale or missing entity positions; Redis OOM errors in application logs during fleet expansion events; proximity query latency increasing above 10ms baseline

Tier 1: Redis Geospatial Memory Pressure: Redis memory exhausted by unbounded geospatial entity growth without entity expiry or cleanup. Recommended evolution: Implement entity-scoped Redis key TTL tied to the last received update timestamp. Entities that have not sent a position update in > 5 minutes are expired from Redis automatically (Redis EXPIRE on the ZSET entry using a per-entity auxiliary key pattern, since ZSET members do not support per-member TTL natively). Alternatively, introduce a background reconciliation job that removes entities from the live position surface after an inactivity threshold. Shard the geospatial index across multiple Redis instances by geographic region using consistent hashing on the region key. .

TimescaleDB write p99 > 50ms; WAL volume > 200MB/minute sustained; disk I/O utilization > 80% on TimescaleDB data volume; chunk creation log entries during fleet expansion events correlated with write latency spikes; TimescaleDB worker queue depth growing during ingestion bursts

Tier 2: TimescaleDB Write Throughput Ceiling: TimescaleDB hypertable chunk write throughput saturated by high-frequency location update volume; chunk creation DDL causing write stalls during expansion. Recommended evolution: Tune TimescaleDB chunk_time_interval to match the ingestion rate: smaller chunks (1-hour intervals instead of 1-day) reduce per-chunk write volume but increase chunk creation frequency. Use timescaledb-parallel-copy for bulk historical ingestion. Move the TimescaleDB WAL to a dedicated NVMe volume. Introduce write batching at the application layer: buffer 500ms of position updates per entity and write as a single multi-row INSERT, reducing the per-update overhead from N single-row INSERTs to N/batch_size batch INSERTs. .

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 .