Time-Series Metrics
write heavySummary
Timestamped metric, event, and sensor data with extremely high write throughput and sequential read patterns (range scans over time windows). Data is append-only by nature; updates are rare. Compression ratios of 10-50x are achievable with columnar or delta-encoded storage.
Example Systems
- ·Infrastructure monitoring (Prometheus, DataDog)
- ·Financial tick data store
- ·IoT sensor platform (ThingsBoard)
- ·Application APM backend
- ·Energy grid telemetry
Characteristics
Capacity
Access Patterns
Recommended Patterns
Patterns to Avoid
Basis
Time-series storage characteristics are thoroughly documented in Prometheus, InfluxDB, and TimescaleDB engineering documentation
Related Architecture Knowledge
Outbound: this entity affects
Time series metrics workloads benefit from rollup to bound storage growth and maintain query performance for historical dashboards without retaining raw high-frequency data indefinitely.
Full relationship →Time-series metric workloads generate write throughput that can saturate disk I/O: 100,000-1,000,000 data points per second produce continuous sequential write load that exceeds spinning disk capacity and requires NVMe or storage-optimized instances to sustain.
Tradeoffs
- ·NVMe SSDs are 10-20x more expensive than spinning disks per GB but required for high-throughput time-series
- ·Write batching (accumulate 1000+ points before writing) amortizes I/O overhead : increases latency from ms to seconds
- ·Column-oriented storage (ClickHouse, TimescaleDB compression) reduces I/O dramatically but requires columnar query patterns
Used In Architecture Scenarios
Realtime Collaboration
A real-time location tracking platform for moving entities: vehicles, delivery couriers, field workers, and assets: receiving position updates at 1–30 second intervals from thousands of simultaneously tracked objects. Redis geospatial indexes (GEOADD / GEOSEARCH) serve sub-10ms proximity queries against the live position surface; PostgreSQL stores durable entity metadata and historical location records; TimescaleDB stores high-frequency time-series location data with automatic hypertable chunking and retention policies; Kafka streams location events to downstream consumers (dispatch systems, customer tracking apps, analytics pipelines). Geofence evaluation runs at ingestion time: each incoming position update is tested against active geofences for the entity's region, and geofence entry/exit events are emitted as Kafka messages to downstream consumers.
Write-Heavy Application
A high-rate device telemetry ingestion architecture designed for millions of devices emitting metrics at 1–60 second intervals. Kafka absorbs device writes as an ingestion buffer, decoupling device-facing ingest endpoints from the storage write path so that downstream storage pressure never propagates back to devices. TimescaleDB provides time-series storage with automatic chunk partitioning by time range, native compression, and continuous aggregate views for rollup queries. ClickHouse serves as the OLAP layer for device fleet analytics queries. Redis caches last-known device state (current readings per device) for real-time alerting queries that must not scan historical storage. Backpressure on the Kafka consumer side prevents storage write throughput from being overwhelmed by burst ingestion events from device reconnect storms.
Analytics Pipeline
A metrics, logs, and traces ingestion and query platform built to absorb the telemetry output of a production system fleet: including the telemetry volume spikes that accompany the incidents the platform is meant to detect. ClickHouse stores metrics data with automatic time-based rollup via continuous materialized views; TimescaleDB provides complementary time-series storage for high-cardinality alert evaluation; Kafka buffers the ingestion stream against downstream write pressure, decoupling ingest acceptance rate from storage write throughput; Elasticsearch serves log full-text search and structured field filtering; Redis caches dashboard query results and active alert state for sub-100ms alert evaluation latency. The alert engine evaluates threshold and anomaly rules against pre-computed materialized views, not raw data, to bound alert evaluation cost independent of ingestion volume.
Event-Driven System
A video and audio streaming architecture where content ingestion triggers an async multi-variant transcoding pipeline, CDN delivery handles 95%+ of playback traffic, and Cassandra absorbs the write volume of per-user viewing history. Kafka decouples upload events from transcoding workers; MinIO stores raw and encoded assets; Redis maintains playback session state and view counters. The architecture must handle upload spikes without blocking delivery, and cache cold starts without cascading database load.