Measurements arrive by time and are read by time range#
timestamp | service | region | metric_name | value
12:01:04 | checkout| us-east | cpu_percent | 72.4The workload is often append-heavy, recent-data focused, and queried as “CPU utilization for checkout in us-east during the last hour.” Time partitioning, dimension/tag indexes, compression, and retention align with that pattern.
Raw resolution is not required forever#
Keep second-level samples for a short operational window, then downsample into minute/hour aggregates and eventually expire or archive old raw data. The policy trades investigation detail against storage and query cost.
| Decision | Risk |
|---|---|
| Time partition size | Too small creates metadata overhead; too large makes retention and scans expensive |
| Dimensions/tags | Unbounded cardinality can explode index/series count |
| Downsampling | Aggregates discard fine-grained evidence |
| Late data | Can require updating older windows |
Infrastructure metrics, IoT telemetry, financial ticks, and application events share timestamped shapes but differ in correctness, latency, retention, and query requirements. A time-series product is not automatically the right primary database for each.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Amazon Timestream conceptsAWS Documentation