Design price alert system for Amazon

Designing a Price Alert System for Amazon involves building a system that allows users to get notified when the price of a product drops to or below a specified threshold.

FR

1.Users can create price alerts for products.

2.Users can update or delete existing alerts.

3.System continuously monitors price changes of tracked products.

4.Price updates are fetched from the Amazon product catalog or frontend APIs.

5.When the product price drops to or below the user-specified target price,notify users abt it

6.Limit the number of alerts a user can set.

7.Avoid sending the same alert multiple times if the price is unchanged.

8.Users can view the list of all active alerts.

NFR

1.The system should be highly scalable to support millions of users and tens of millions of alerts.

2.Notification latency should be minimal — alerts should be sent within a few seconds of detecting a price drop.

3.High availability (99.99%) is required for a consumer-facing service

4.System should be fault tolerant. The system should be resilient to failures of individual services or components.

5.Strong consistency isn't critical, but eventual consistency is acceptable for price data.

Estimates

Active users: 50 million

Avg alerts/user: 5

Total alerts: 250 million

QPS=250M/10^5(86400 approx)=250*10^6/10^5= 2500 QPS=2.5K QPS

Tracked products: 100 million (subset from Amazon catalog)

Alert check frequency: every 10 minutes

Avg notification size: 1 KB

10% of alerts get triggered per day

ach alert stores:

user_id (16 B)

product_id (16 B)

target_price (4 B)

notification_type (e.g., push/email) (8 B)

timestamp (8 B)

metadata (20 B)

Total ≈ 72 B per alert

Storage for 250M alerts =
250M * 72 B ≈ 18 GB

Add metadata, indexes, redundancy → round up to ~50 GB

API’s

1.POST /api/v1/alerts

request {
  "product_id": "B08XYZ1234",
  "target_price": 499.99,
  "notification_type": "email",
  "currency": "USD"
}
response {
  "alert_id": "a1b2c3d4",
  "message": "Alert created successfully"
}

2.GET /api/v1/alerts

response [
  {
    "alert_id": "a1b2c3d4",
    "product_id": "B08XYZ1234",
    "target_price": 499.99,
    "current_price": 525.00,
    "notification_type": "email",
    "is_active": true,
    "created_at": "2025-04-24T10:00:00Z"
  }
]

3.PUT /api/v1/alerts/{alert_id}

request {
  "target_price": 459.00,
  "notification_type": "push"
}
response {
  "message": "Alert updated successfully"
}

4.DELETE /api/v1/alerts/{alert_id}

{
  "message": "Alert deleted successfully"
}

5.PATCH /api/v1/alerts/{alert_id}/status

request {
  "is_active": false
}
response {
  "message": "Alert status updated"
}

6.GET /api/v1/alerts/history

response [
  {
    "alert_id": "a1b2c3d4",
    "product_id": "B08XYZ1234",
    "triggered_price": 479.99,
    "triggered_at": "2025-04-22T08:32:00Z",
    "notification_type": "email"
  }
]

GET /api/v1/user/notifications

POST /api/v1/user/notifications

Databases

🗄️ Database Choice

We’ll use a hybrid approach:

1. Relational DB (e.g., PostgreSQL / MySQL)

• For storing alerts, users, and notification preferences

• ACID transactions help with data integrity

2. NoSQL (e.g., DynamoDB / Redis / MongoDB) — optional

• For fast price lookups or caching product metadata

• Redis could also help with deduping notifications, alert queues

---

🧩 Relational DB Schema

📍 users table

CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

🔔 price_alerts table

CREATE TABLE price_alerts (
    alert_id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(user_id),
    product_id VARCHAR(50),
    target_price DECIMAL(10, 2),
    currency VARCHAR(5),
    notification_type VARCHAR(20), -- e.g., email, push
    is_active BOOLEAN DEFAULT TRUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

💰 products table (Optional - for price caching)

CREATE TABLE products (
    product_id VARCHAR(50) PRIMARY KEY,
    title TEXT,
    current_price DECIMAL(10, 2),
    currency VARCHAR(5),
    last_checked TIMESTAMP
);

📨 triggered_alerts table (for history/logs)

CREATE TABLE triggered_alerts (
    id BIGSERIAL PRIMARY KEY,
    alert_id UUID REFERENCES price_alerts(alert_id),
    user_id UUID REFERENCES users(user_id),
    product_id VARCHAR(50),
    triggered_price DECIMAL(10, 2),
    triggered_at TIMESTAMP,
    notification_type VARCHAR(20)
);

⚙️ user_preferences

CREATE TABLE user_preferences (
    user_id UUID PRIMARY KEY REFERENCES users(user_id),
    default_currency VARCHAR(5),
    default_notification_type VARCHAR(20),
    timezone VARCHAR(50),
    language VARCHAR(10)
);

🔄 Optimization & Indexing Suggestions

• Index product_id, is_active, and target_price in price_alerts for fast price evaluations.

• Use materialized views or caching layer (Redis) for price-to-alert mapping if needed.

• Background job workers can periodically:

  • Fetch prices

  • Match against alerts

  • Send notifications

  • Store in triggered_alerts

HLD