Delivery agent assignment in LLD - Scalability & System Analysis

Scalability Analysis - Delivery agent assignment

Growth Table: Delivery Agent Assignment System

Scale	Users (Orders/Day)	Delivery Agents	Key Changes
Small	100	20	Simple assignment logic, single server, direct DB queries
Medium	10,000	2,000	Introduce caching, load balancing, asynchronous assignment
Large	1,000,000	200,000	Microservices, sharded DB, geo-partitioning, message queues
Very Large	100,000,000	20,000,000	Global distributed system, advanced sharding, AI-based assignment, CDN for static data

First Bottleneck

At small to medium scale, the database becomes the first bottleneck. This is because the system needs to quickly find available delivery agents and update their status for each order. The database handles many read and write queries per second, and as orders grow, it struggles to keep up.

Scaling Solutions

• Database Read Replicas: Use replicas to handle read queries, reducing load on the primary database.
• Caching: Cache delivery agent availability and location data to reduce frequent DB hits.
• Load Balancing: Distribute incoming assignment requests across multiple application servers.
• Asynchronous Processing: Use message queues to decouple order intake from assignment processing.
• Sharding: Partition the database by geography or agent ID to spread load.
• Microservices: Separate assignment logic into dedicated services for better scalability.
• Geo-Partitioning: Assign orders to agents within the same region to reduce latency and data scope.
• AI-based Assignment: Use machine learning to optimize agent selection and reduce assignment time.

Back-of-Envelope Cost Analysis

• At 10,000 orders/day (~7 orders/min), assuming each order triggers 5 DB queries, total ~35 queries/min (~0.6 QPS) - easily handled by a single DB.
• At 1,000,000 orders/day (~700 orders/min), queries rise to ~3500 QPS, nearing a single DB instance limit.
• Storage: Each order record ~1 KB, 1M orders/day = ~1 GB/day storage; 100M orders = 100 GB/day, requiring archival strategies.
• Network bandwidth: Assuming 1 KB per request/response, 1M orders/day = ~12 MB/s peak, manageable with standard infrastructure.

Interview Tip

Start by clarifying the scale and requirements. Discuss the current bottleneck and how it changes with growth. Propose incremental solutions: caching, load balancing, then sharding and microservices. Always justify why each step is needed and how it helps scalability.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Introduce read replicas and caching to reduce load on the primary database before considering sharding or adding more servers.

Key Result

The database is the first bottleneck as order volume grows; scaling solutions start with caching and read replicas, then move to sharding and microservices for very large scale.