Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Analytics Data Platform: triggered by 'OLTP query p99 degrading during analytics reporting windows;'. Geospatial Tracking Platform: triggered by 'PostGIS proximity query p99 > 100ms under concurrent fleet t'.

Migration Step 2

Both scenarios define a migration step at this stage. Analytics Data Platform: triggered by 'Sub-minute analytics freshness SLA required; ETL scheduling '. Geospatial Tracking Platform: triggered by 'Location update API p99 > 200ms correlated with geofence cou'.

Migration Step 3

Both scenarios define a migration step at this stage. Analytics Data Platform: triggered by 'Dashboard query p95 > 5s on frequently accessed aggregation '. Geospatial Tracking Platform: triggered by 'PostgreSQL location_history table exceeding 100GB with query'.

Kafka consumer group lag (bytes or offsets) growing for the analytics topic group; ClickHouse dashboard timestamps falling behind wall clock by > 60s; ClickHouse insert throughput < Kafka produce rate

Tier 1: Consumer Lag and Freshness Degradation: ClickHouse insert throughput insufficient for Kafka produce rate. Recommended evolution: Tune ClickHouse insert buffer size and async_insert settings; increase consumer parallelism up to the Kafka partition count; batch inserts into ClickHouse using the Buffer engine or materialized views with merge trees .

One Kafka partition offset growing significantly faster than others; one consumer instance CPU/network saturated while others are idle

Tier 2: Hot Partition and Skewed Consumer Load: Skewed partition key distribution: high-cardinality entity routing the same high-volume key to one partition. Recommended evolution: Add a secondary hash suffix to the partition key to distribute load; increase topic partition count (note: keyed ordering breaks for existing messages); re-evaluate partition key selection based on actual cardinality measurements .

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