System requirements

Functional:

Order Placement Tracking:

Customers and businesses can track orders from placement to delivery.
Businesses can update the status of an order (e.g., "Processing," "Shipped," "Delivered").

Real-time Order Status Updates:

Customers can see real-time updates on the order's status.
Support for push notifications on key updates (via WebSockets, for example).

Multi-role Access:

Admin users for businesses to manage orders and updates.
Customers can view the status of their own orders only.

Search and Filter Orders:

Ability to search and filter orders based on status, date, etc.

Notifications:

Push notifications for users who opt-in to receive real-time updates on their orders.
Support for notifications via multiple channels (email, SMS, push notifications).

API Integration:

Provide APIs for third-party integrations (e.g., delivery services, payment gateways).

Non-Functional:

Scalability:

The system should handle millions of users and transactions daily.
Real-time updates and notifications should scale horizontally as load increases.

Availability:

High availability (99.9% uptime) to ensure tracking is available 24/7.

Performance:

Low latency for API responses (<200ms) and real-time updates.

Security:

Authentication and authorization for different user roles (customers, businesses).
Data encryption for sensitive information (SSL, TLS).

Fault Tolerance:

The system should gracefully handle failures, with retries and fallbacks.

Consistency:

Ensure data consistency between orders, status updates, and notifications.

Compliance:

Ensure compliance with data privacy laws (e.g., GDPR, CCPA).

Capacity estimation

Assumptions:

Active Users: 1 million users/day.
Orders per Day: 1 million orders/day.
Status Updates per Order: 10 updates per order.
Real-time Updates: 10 million updates/day.
Peak Transactions: 1-2 million transactions/hour during peak.
Notification Connections: 60% of users opt-in for notifications (600,000 WebSocket connections).

Estimation:

API Requests:
- Order placements: 1 million requests/day.
- Status updates: 10 million requests/day.
- Search/Filter orders: 500,000 requests/day (estimated).
Database Capacity:
- Orders table: Stores 1 million new orders daily.
- Status updates table: Stores 10 million new updates daily.
- Connections: Support 600,000 active WebSocket connections for real-time updates.
Storage:
- Assuming each order record is ~1 KB and each status update is ~500 B:
  - Order data: 1 GB/day.
  - Status updates: 5 GB/day.
  - Total storage per day: 6 GB/day.
Estimate for 1 year: ~2.2 TB of storage for orders and status updates.
Network:
- WebSocket connections for 600,000 users can generate significant traffic. Assume ~1 KB per message per user per update:
  - 600,000 users * 1 KB * 10 updates = ~6 GB of data traffic per update batch.

API design

The following APIs are needed to support the system:

Place Order API
Get Order Status API
Update Order Status API (for businesses)
Search Orders API
WebSocket Connection for Real-time Updates

ws://api.orders.com/notifications

Message Structure:
{
  "event": "order_status_update",
  "data": {
    "order_id": "456",
    "status": "Delivered"
  }
}

Database design

erDiagram
    USERS {
        int user_id PK
        string name
        string email
        string phone
        string role
        datetime created_at
    }

    ORDERS {
        int order_id PK
        int user_id FK
        string shipping_address
        string status
        datetime created_at
        datetime estimated_delivery
    }

    ORDER_ITEMS {
        int item_id PK
        int order_id FK
        int product_id
        int quantity
        float price
    }

    STATUS_UPDATES {
        int status_id PK
        int order_id FK
        string status
        datetime updated_at
    }

    USERS ||--o{ ORDERS : "places"
    ORDERS ||--o{ ORDER_ITEMS : "contains"
    ORDERS ||--o{ STATUS_UPDATES : "has many"

High-level design

API Gateway:

Acts as an entry point for all client applications (mobile, web).
Handles authentication, rate limiting, and request routing to the appropriate backend services.

Order Management Service:

Responsible for managing the entire lifecycle of orders.
Handles placing new orders, updating their status, and retrieving order details.
Stores order data in the database.

Status Update Service:

Manages real-time updates of order statuses.
Processes status changes and updates the database.
Notifies customers about updates via WebSocket connections or other channels (e.g., email, SMS).

Notification Service:

Sends real-time notifications to customers when the status of their orders changes.
Can be implemented using WebSockets for real-time delivery, as well as support for email or SMS notifications.

Database:

Stores data related to users, orders, order items, and status updates.
Optimized for high throughput with indexes and partitioning strategies for scalability.

Search Service:

Provides search and filter functionalities for orders.
Users can search their orders based on status, date, etc.

Authentication Service:

Manages user authentication and authorization.
Ensures that customers can only access their own orders and businesses have access to manage all orders.

graph TD
    A[API Gateway] --> B[Order Management Service]
    A --> C[Status Update Service]
    A --> D[Search Service]
    A --> E[Notification Service]
    B --> F[(Database)]
    C --> F
    D --> F
    E --> F
    A --> G[Authentication Service]
    E --> H[WebSocket Server]

sequenceDiagram
    participant Admin as Admin
    participant AG as API Gateway
    participant SUS as Status Update Service
    participant DB as Database
    participant NS as Notification Service
    participant C as Customer

    Admin->>AG: Update Order Status Request
    AG->>SUS: Forward Update Status Request
    SUS->>DB: Update Order Status in Database
    DB-->>SUS: Status Updated
    SUS-->>AG: Status Update Confirmation
    AG-->>Admin: Status Updated Response
    SUS->>NS: Notify Customer of Status Update
    NS-->>C: Send Real-Time Notification (WebSocket/Email/SMS)

Request flows

Placing an Order

Customer places an order via the API Gateway.
The API Gateway forwards the request to the Order Management Service.
The Order Management Service validates the order, stores it in the Database, and returns a confirmation to the customer.
If real-time notifications are enabled, the Notification Service is informed about the new order to notify the customer about updates (optional).

sequenceDiagram
    participant C as Customer
    participant AG as API Gateway
    participant OMS as Order Management Service
    participant DB as Database
    participant NS as Notification Service

    C->>AG: Place Order Request
    AG->>OMS: Forward Place Order Request
    OMS->>DB: Save Order Data
    DB-->>OMS: Order Saved
    OMS-->>AG: Order Confirmation
    AG-->>C: Order Confirmation Response
    OMS->>NS: Notify of New Order (optional)

Order Status Update

Admin updates the order status (e.g., marks it as "Shipped").
The API Gateway forwards the request to the Status Update Service.
The Status Update Service updates the status in the Database.
The Notification Service is triggered to notify the customer of the status update, which could be delivered via WebSockets, email, or SMS.
If the customer is connected via WebSocket, the real-time update is sent immediately.

sequenceDiagram
    participant Admin as Admin
    participant AG as API Gateway
    participant SUS as Status Update Service
    participant DB as Database
    participant NS as Notification Service
    participant C as Customer

    Admin->>AG: Update Order Status Request
    AG->>SUS: Forward Update Status Request
    SUS->>DB: Update Order Status in Database
    DB-->>SUS: Status Updated
    SUS-->>AG: Status Update Confirmation
    AG-->>Admin: Status Updated Response
    SUS->>NS: Notify Customer of Status Update
    NS-->>C: Send Real-Time Notification (WebSocket/Email/SMS)

Real-Time Notifications

Customer opts in for real-time notifications via WebSocket.
API Gateway opens a WebSocket connection with the customer.
Status Update Service sends notifications about order status changes to the Notification Service.
The Notification Service pushes the updates to the customer in real-time via the open WebSocket connection.

sequenceDiagram
    participant C as Customer
    participant AG as API Gateway
    participant NS as Notification Service
    participant SUS as Status Update Service

    C->>AG: Open WebSocket Connection
    AG-->>C: WebSocket Connection Established
    SUS->>NS: Order Status Updated
    NS-->>C: Push Real-Time Notification via WebSocket

Detailed component design

Order Management Service

The Order Management Service is responsible for the entire lifecycle of an order, from placement to delivery. It ensures that orders are saved, updated, and retrieved efficiently, given the system’s need to handle large volumes of transactions.

Key Responsibilities:

Accept orders and store order details in the database.
Update order statuses based on external triggers (e.g., admin updates).
Provide APIs for retrieving order details and status updates.

Notification Service

The Notification Service is crucial for delivering real-time updates to customers about their order status. It supports different channels like WebSockets, email, and SMS, ensuring that users are informed as soon as there is a change in their order status.

Key Responsibilities:

Push real-time notifications to customers.
Manage WebSocket connections for active users.
Send notifications via alternative channels (email, SMS) for users not connected via WebSocket.

Why These Components Scale Well:

Order Management Service: The stateless nature of the service allows it to scale horizontally without much complexity. Combined with database sharding and caching mechanisms, it can handle millions of orders and status updates without degrading performance.
Notification Service: Managing large-scale WebSocket connections efficiently requires a cluster-based approach with a Pub/Sub system like Redis to broadcast messages across nodes. The use of asynchronous message queues ensures that the system can handle spikes in notification requests without overwhelming any single instance.

Trade offs/Tech choices

Database: Relational DB (PostgreSQL/MySQL) for structured data, with potential future use of NoSQL.

Real-time Updates: WebSockets for immediate communication.

Message Broker: Kafka for handling high-volume event streams.

Caching: Redis for fast access to frequently queried data.

Microservices: API Gateway in front of distributed microservices for scalability and flexibility.

Load Balancing: Distributed load balancing to handle large volumes of traffic.

Asynchronous Processing: Background workers and queues for handling non-blocking updates and notifications.

Failure scenarios/bottlenecks

As the number of users and orders increases, the database could become a bottleneck, especially during peak times when millions of status updates and orders are being processed.
If too many users opt in for real-time notifications, the WebSocket servers may become overloaded, leading to dropped connections or delayed notifications.
Notifications (via WebSockets, email, or SMS) may fail to reach customers due to network issues, external service failures (e.g., email or SMS providers), or internal system problems.
High volumes of API requests, especially during peak times (e.g., flash sales or major events), could overwhelm the system, leading to slowdowns or denial of service.

Future improvements

AI-Powered Predictions:

Integrate machine learning models to predict order delivery times more accurately based on historical data, weather conditions, and traffic patterns.

Service Mesh Implementation:

Adopt a service mesh (e.g., Istio) to manage service-to-service communication more effectively, providing observability, traffic management, and secure communication.

Advanced Analytics:

Develop an analytics service to give businesses insights into order trends, delivery times, and customer satisfaction based on order tracking data.

Graceful Degradation:

Implement more sophisticated mechanisms for graceful degradation, allowing parts of the system to remain functional even during outages of critical components.

Solutions

nectar4678 - 10/22/2024

0

ethereal2186 - 10/19/2026

0