Question #33 of 60•Databases•Hard• ~3 min read

How do you design a Real-Time Metrics & Alerting Monitoring System (Datadog/Prometheus)?

Executive Takeaway

Explore time-series metrics ingestion, downsampling, sliding window aggregations, and high-cardinality label storage.

Architectural Breakdown & AnalysisFAANG Aligned

Monitoring systems process millions of time-series data points per second for real-time alerting and historical dashboards.

Architecture Components

  1. Data Collection (Pull vs Push): Prometheus pulls metrics from /metrics HTTP endpoints. Datadog agent pushes metrics via UDP/StatsD.
  2. Time-Series DB Engine (TSDB): Stores timestamps, metric names, and labels using delta-of-delta compression.
  3. Aggregations & Downsampling: Background jobs aggregate raw second-level metrics into 1-minute and 1-hour rollups, moving cold metrics to object storage.
WARNING — High Cardinality Warning

Avoid putting unique IDs (like user_id or order_id) into metric labels. High cardinality explodes TSDB memory usage.

Key Architectural Comparison

Telemetry Ingestion ModelCommunication DirectionNetwork / Firewall ConfigurationResource Consumption on Worker
Pull Model (Prometheus)Central server scrapes target /metrics.Requires open inbound ports on all targets.Minimal (Worker serves simple text HTTP endpoint).
Push Model (Datadog)Agent pushes metrics to central collector.Inbound ports closed; only outbound egress needed.Moderate (Agent runs background batching daemon).
Previous QuestionHow does a Service Mesh (Istio / Envoy) simplify microservice traffic management?Next Question How do Database Connection Pools (HikariCP) prevent thread starvation?

Continue Learning on Being SDE

Explore deep-dive system architecture modules, low-level object-oriented designs, and interview cheat sheets.