Alerting thresholds in HLD - System Design Exercise

Design: Alerting Thresholds System

Design covers threshold configuration, alert detection, notification delivery, and dashboard. Does not cover metric collection or storage in detail.

Functional Requirements

FR1: Allow users to define alert thresholds for various metrics (e.g., CPU usage, memory, error rates).

FR2: Support multiple types of thresholds: static values, percentage changes, and rate of change.

FR3: Trigger alerts when thresholds are crossed and notify users via email or SMS.

FR4: Allow users to set different thresholds for different time periods (e.g., business hours vs off-hours).

FR5: Support grouping of alerts by service or application.

FR6: Provide a dashboard to view current alerts and threshold configurations.

FR7: Ensure alerts are generated with low latency (p99 < 1 second after threshold breach).

Non-Functional Requirements

NFR1: System must handle monitoring data from up to 10,000 services sending metrics every minute.

NFR2: Availability target of 99.9% uptime (less than 8.77 hours downtime per year).

NFR3: System should scale horizontally to handle increased load.

NFR4: Alert notifications must be reliable with retry mechanisms.

NFR5: Data retention for threshold configurations and alert history should be at least 90 days.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Threshold Configuration Service

Metrics Ingestion and Processing Pipeline

Alert Evaluation Engine

Notification Service

User Dashboard and API

Database for configurations and alert history

Design Patterns

Event-driven architecture for alert evaluation

Publish-subscribe for notification delivery

Caching for threshold configurations

Rate limiting and backoff for notifications

Time-series data handling for metric trends

Reference Architecture

                    +---------------------+
                    |  User Dashboard/API  |
                    +----------+----------+
                               |
                               v
                +--------------+---------------+
                |   Threshold Configuration     |
                |          Service              |
                +--------------+---------------+
                               |
                               v
+----------------+     +-------+--------+     +----------------+
| Metrics Source | --> | Metrics Ingest | --> | Alert Engine   |
+----------------+     +----------------+     +-------+--------+
                                                       |
                                                       v
                                              +--------+---------+
                                              | Notification      |
                                              | Service          |
                                              +------------------+

Components

Threshold Configuration Service

REST API with database (PostgreSQL)

Manage user-defined alert thresholds and store configurations.

Metrics Ingestion and Processing Pipeline

Kafka + Stream Processing (Apache Flink or Spark Streaming)

Receive and process incoming metrics in real-time.

Alert Evaluation Engine

Stream processing with rules engine

Evaluate metrics against thresholds and generate alerts.

Notification Service

Microservice with email/SMS gateways (e.g., Twilio, SMTP)

Send alert notifications reliably with retries.

User Dashboard and API

Web frontend (React) + backend API

Allow users to view and manage thresholds and alerts.

Database

PostgreSQL for configurations and alert history

Store threshold settings and alert records with retention.

Request Flow

1. User sets or updates alert thresholds via the Dashboard/API.

2. Threshold Configuration Service validates and stores these settings in the database.

3. Metrics from services are sent continuously to the Metrics Ingestion Pipeline.

4. The pipeline processes metrics and forwards them to the Alert Evaluation Engine.

5. The Alert Evaluation Engine compares metrics against stored thresholds.

6. When a threshold is breached, an alert event is generated.

7. Alert events are sent to the Notification Service.

8. Notification Service sends alerts to users via email or SMS, retrying on failure.

9. Alerts and their statuses are stored in the database for dashboard display.

Database Schema

Entities: - User (id, name, contact_info) - Threshold (id, user_id, metric_name, threshold_type, threshold_value, time_period, service_group) - Alert (id, threshold_id, metric_value, timestamp, status) Relationships: - User 1:N Threshold - Threshold 1:N Alert - Alerts linked to specific metric and service group for filtering

Scaling Discussion

Bottlenecks

High volume of incoming metrics causing ingestion delays.

Alert Evaluation Engine becoming CPU-bound with many thresholds.

Notification Service overwhelmed by large alert bursts.

Database write/read bottlenecks for storing configurations and alerts.

Solutions

Partition metrics ingestion by service groups and scale Kafka clusters horizontally.

Distribute alert evaluation across multiple nodes with sharding by metric or service.

Implement notification rate limiting, batching, and use scalable third-party gateways.

Use database sharding, read replicas, and caching for threshold configurations.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Clarify types of thresholds and alerting needs early.

Explain how real-time processing enables low latency alerts.

Discuss reliability in notification delivery with retries.

Highlight database design supporting retention and querying.

Address scaling challenges and horizontal scaling strategies.

Mention user experience via dashboard and API.

Practice

1. What is the primary purpose of setting alerting thresholds in system design?

easy

A. To delay notifications until issues become critical

B. To increase system resource usage

C. To reduce the number of system logs generated

D. To detect problems early before they impact users

Solution

1. Step 1: Understand alerting thresholds role

   Alerting thresholds are set to monitor system metrics and detect anomalies early.

2. Step 2: Identify the main goal

   The main goal is to catch issues before they affect users or cause downtime.

3. Final Answer:

   To detect problems early before they impact users -> Option D

4. Quick Check:

   Alerting thresholds = Early problem detection [OK]

Hint: Alerting thresholds catch issues early to protect users [OK]

Common Mistakes:

• Thinking thresholds increase resource use
• Believing thresholds delay notifications
• Confusing thresholds with log management

2. Which of the following is a valid component of an alerting threshold configuration?

easy

A. User interface color scheme

B. Metric name to monitor

C. Database schema version

D. Network cable length

Solution

1. Step 1: Identify components of alerting thresholds

   Alerting thresholds include metric names, threshold values, comparison operators, duration, severity, and notification methods.

2. Step 2: Match valid component

   Metric name is essential to specify what to monitor.

3. Final Answer:

   Metric name to monitor -> Option B

4. Quick Check:

   Alert config includes metric name [OK]

Hint: Alert configs always include metric names [OK]

Common Mistakes:

• Confusing UI settings with alert configs
• Including unrelated hardware details
• Mixing database schema with alert thresholds

3. Consider this alert rule: CPU usage > 80% for 5 minutes triggers WARNING. If CPU usage spikes to 85% for 3 minutes, then drops to 75%, what happens?

medium

A. WARNING alert triggers immediately at 85%

B. Alert triggers after CPU usage drops below 80%

C. No alert is triggered because duration is less than 5 minutes

D. System shuts down due to high CPU

Solution

1. Step 1: Analyze alert condition

   The alert triggers only if CPU usage stays above 80% continuously for 5 minutes.

2. Step 2: Evaluate given scenario

   CPU usage was above 80% for only 3 minutes, which is less than required 5 minutes, so no alert triggers.

3. Final Answer:

   No alert is triggered because duration is less than 5 minutes -> Option C

4. Quick Check:

   Duration condition not met = No alert [OK]

Hint: Duration must be met before alert triggers [OK]

Common Mistakes:

• Ignoring duration and alerting immediately
• Assuming alert triggers after usage drops
• Confusing alert severity with system shutdown

4. You have an alert threshold: Memory usage >= 90% for 10 minutes triggers CRITICAL. The alert never fires even when memory usage is 95% for 15 minutes. What is the most likely issue?

medium

A. The monitoring system is not collecting memory metrics correctly

B. The comparison operator should be > instead of >=

C. The alert duration is set too low

D. The notification channel is misconfigured

Solution

1. Step 1: Check alert condition correctness

   The condition uses >= 90% for 10 minutes, which is valid and should trigger if memory usage is 95% for 15 minutes.

2. Step 2: Identify why alert doesn't fire

   If alert doesn't fire despite condition met, likely the monitoring system is not reporting memory usage correctly.

3. Final Answer:

   The monitoring system is not collecting memory metrics correctly -> Option A

4. Quick Check:

   Metrics missing = Alert won't trigger [OK]

Hint: Check metric collection if alerts don't trigger [OK]

Common Mistakes:

• Changing valid comparison operators unnecessarily
• Assuming duration is too low when it's sufficient
• Blaming notification without checking metrics

5. You design an alerting system with thresholds for CPU, memory, and disk usage. To avoid alert fatigue, which strategy is best?

hard

A. Use multi-level severity with increasing thresholds and durations

B. Disable alerts during business hours

C. Send alerts for every metric spike immediately

D. Set thresholds too low to catch all minor issues

Solution

1. Step 1: Understand alert fatigue

   Alert fatigue happens when too many alerts overwhelm responders, causing important alerts to be missed.

2. Step 2: Choose strategy to reduce noise

   Using multi-level severity with increasing thresholds and durations helps prioritize critical alerts and reduce noise from minor fluctuations.

3. Final Answer:

   Use multi-level severity with increasing thresholds and durations -> Option A

4. Quick Check:

   Multi-level severity reduces alert fatigue [OK]

Hint: Use severity levels and durations to reduce alert noise [OK]

Common Mistakes:

• Setting thresholds too low causing many false alerts
• Alerting on every spike without filtering
• Disabling alerts during critical times