Time-Series Store

1. Sensors and telemetry agents emit timestamped measurements (metrics, ticks, IoT readings) at high frequency, each tagged with dimensions like device_id, region, or metric name.
2. A collector/ingest layer (line-protocol endpoint, Kafka bridge, or agent gateway) batches these writes and forwards them append-only to the time-series engine, absorbing bursts without back-pressuring producers.
3. The time-series database persists points into time-partitioned shards, applying columnar compression and delta-of-delta encoding so recent data stays hot and older ranges compact tightly.
4. Continuous aggregation jobs run inside the engine, incrementally rolling raw points into 1-minute, 1-hour, and daily materialized views as data lands—no full rescans.
5. Retention policies automatically expire raw high-resolution data after a defined window while preserving downsampled rollups for long-term trend analysis.
6. Dashboards, alerting engines, and analytics clients query via time-range and tag predicates, transparently reading from the pre-aggregated view that matches the requested resolution.

• Massive ingest throughput and compression vs weaker support for arbitrary updates and complex multi-table joins.
• Native downsampling and retention vs another specialized engine to operate and monitor.
• Fast time-range queries vs limited flexibility for non-temporal access paths.
• Automatic rollups reduce storage cost vs irreversible loss of raw granularity once retention expires.

A renewable-energy operator streams readings from 50,000 wind-turbine sensors, each reporting vibration, temperature, and output every second. Raw one-second data is retained for seven days for fault diagnosis, while continuous aggregates roll it into hourly and daily views kept for five years to model degradation. Operations dashboards query the hourly view for fleet health, and an alerting service compares live one-second points against rolling baselines to flag gearbox anomalies—all served from a single time-series store that a prior PostgreSQL deployment could no longer keep up with.

• Out-of-order and late arrivals: Points arriving after their partition has compacted force rewrites or land in a separate buffer; define a bounded lateness window and decide whether stragglers update rollups or are dropped, since most engines won't retroactively recompute closed aggregates.
• Cardinality is the silent killer: Each unique tag combination creates a distinct series; unbounded tags (raw device UUIDs, timestamps-as-tags, user IDs) explode the index, inflate memory, and slow queries—cap and normalize dimensions before ingest.
• Rollup and retention coupling: Continuous aggregates must be fully materialized before raw retention expires, or you permanently lose the granularity feeding them; stagger expiry so downsampling always leads deletion.
• Idempotent ingest: Writes keyed by timestamp+tag set overwrite on collision, so retried batches are naturally idempotent—but clock skew across producers can silently overwrite or misorder points; sync sources to a common time base.
• Compaction and cost drivers: Background compaction, index rebuilds, and chunk merging compete with query load; bill scales with cardinality, retention depth, and rollup count more than raw ingest rate—monitor compaction backlog, disk write amplification, and per-series memory.
• Schema evolution: Adding tags mid-stream creates new series rather than altering old ones, fragmenting queries across old and new shapes; version measurement names and backfill deliberately.