Delivery agent assignment in LLD - System Design Exercise

Design: Delivery Agent Assignment System

Includes order intake, agent status management, assignment logic, and notifications. Excludes payment processing and customer support.

Functional Requirements

FR1: Assign delivery agents to new orders automatically

FR2: Support real-time location tracking of delivery agents

FR3: Handle up to 10,000 concurrent orders per hour

FR4: Allow manual reassignment by dispatchers

FR5: Notify agents of new assignments instantly

FR6: Ensure agents are assigned based on proximity and availability

FR7: Support agent status updates (available, busy, offline)

Non-Functional Requirements

NFR1: API response time for assignment should be under 200ms (p99)

NFR2: System availability target is 99.9% uptime

NFR3: Support up to 5,000 active delivery agents simultaneously

NFR4: Data consistency for agent status and assignments must be strong

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Order intake API

Agent location tracking service

Assignment engine

Notification service

Agent status management

Database for orders and agents

Design Patterns

Geospatial indexing for proximity search

Event-driven architecture for real-time updates

Circuit breaker for external notification failures

Caching for agent availability

Load balancing for API endpoints

Reference Architecture

  +-------------+       +----------------+       +---------------------+
  |  Order API  | ----> | Assignment Eng | ----> | Notification Service |
  +-------------+       +----------------+       +---------------------+
         |                      |                          |
         v                      v                          v
  +----------------+    +----------------+         +----------------+
  | Agent Location |    | Agent Status   |         |   Database     |
  | Tracking Svc   |    | Management     |         | (Orders, Agents)|
  +----------------+    +----------------+         +----------------+

Components

Order API

REST API with Node.js or Python Flask

Receive new orders and trigger assignment process

Agent Location Tracking Service

WebSocket or MQTT service

Receive and update real-time agent GPS locations

Agent Status Management

In-memory store like Redis

Track agent availability and status updates

Assignment Engine

Microservice in Go or Java

Assign agents to orders based on proximity and availability

Notification Service

Push notification system (Firebase, APNs)

Notify agents instantly about new assignments

Database

PostgreSQL with PostGIS extension

Store orders, agents, and geospatial data

Request Flow

1. 1. Customer places an order via Order API.

2. 2. Order API stores order in database and triggers Assignment Engine.

3. 3. Assignment Engine queries Agent Status Management for available agents.

4. 4. Assignment Engine queries Agent Location Tracking Service or database for agent locations.

5. 5. Assignment Engine selects nearest available agent using geospatial queries.

6. 6. Assignment Engine updates order with assigned agent in database.

7. 7. Notification Service sends assignment notification to the selected agent.

8. 8. Agent status is updated to busy in Agent Status Management.

9. 9. Agent accepts or rejects assignment; status updates accordingly.

Database Schema

Entities: - Agent (agent_id PK, name, phone, status ENUM('available','busy','offline'), last_location POINT, last_update TIMESTAMP) - Order (order_id PK, customer_id, pickup_location POINT, dropoff_location POINT, status ENUM('pending','assigned','delivered'), assigned_agent_id FK) - Assignment Log (assignment_id PK, order_id FK, agent_id FK, assigned_at TIMESTAMP, status ENUM('accepted','rejected')) Relationships: - One Agent can have many Assignments - One Order has one assigned Agent

Scaling Discussion

Bottlenecks

Assignment Engine CPU overload due to high concurrent assignment requests

Database geospatial query latency with large agent and order volumes

Notification service delays or failures under high load

Real-time location updates overwhelming tracking service

Solutions

Horizontal scale Assignment Engine with load balancers and stateless design

Use geospatial indexes (PostGIS) and cache nearby agents in Redis for faster lookups

Implement retry and fallback mechanisms in Notification Service; use message queues

Batch location updates and use efficient protocols like MQTT; shard tracking service by region

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Clarify assignment criteria and real-time constraints

Explain choice of geospatial indexing and caching

Discuss strong consistency needs for agent status

Highlight event-driven notifications and failure handling

Address scaling challenges with concrete solutions