Queue Wait Time Little's Law Estimator
Estimate queue wait times using Little's Law. Calculate average wait time, queue length, and arrival rates for any service system. Free operations tool.
Worked Examples
Example 1: Call Center Staffing
Problem: Call center receives 100 calls/hour. Average call lasts 3 minutes. Currently 2 agents. Target: <30 second wait. How many agents needed?
Solution: Current State:\n- Arrival rate (λ): 100/hour = 1.67/min\n- Service rate (μ): 1 call / 3 min = 0.33/min\n- Servers (c): 2\n- Utilization: 1.67 / (2 × 0.33) = 2.5 → OVERLOADED!\n\nProblem: Arrival rate exceeds capacity\nCapacity: 2 agents × 20 calls/hour = 40 calls/hour\nDemand: 100 calls/hour\nShortfall: 60 calls/hour\n\nServers Needed:\n100 calls/hour ÷ 20 calls/hour/agent = 5 agents minimum\n\nWith 5 agents:\n- Capacity: 100 calls/hour\n- Utilization: 100%\n- Wait time: STILL INFINITE (at capacity)\n\nWith 6 agents:\n- Capacity: 120 calls/hour\n- Utilization: 83%\n- Wait time: ~45 seconds (still high)\n\nWith 7 agents:\n- Capacity: 140 calls/hour\n- Utilization: 71%\n- Wait time: ~15 seconds ✓ (meets target)\n\nRecommendation: 7 agents to meet 30s target
Result: Need 7 agents | Currently 2 (overloaded) | Target wait: 30s → Actual: 15s
Example 2: API Server Capacity
Problem: API receives 50 requests/second. Each request takes 100ms to process. Currently 10 servers. Is this sufficient? What's average wait?
Solution: Queue Analysis:\n- Arrival rate: 50 req/s\n- Service time: 0.1s per request\n- Service rate per server: 10 req/s\n- Servers: 10\n- Total capacity: 100 req/s\n\nUtilization:\nρ = 50 / 100 = 50%\n\nM/M/10 Wait Time Calculation:\nUsing Erlang C formula:\n- Probability of waiting: ~2%\n- Average wait (for those who wait): ~0.05s\n- Average wait (overall): ~0.001s\n\nSystem Time:\n- Wait: 0.001s\n- Service: 0.1s\n- Total: 0.101s\n\nLittle's Law Verification:\nL = λ × W = 50 × 0.101 = 5.05 requests in system\n\nConclusion:\n- 10 servers is sufficient\n- Low utilization (50%) provides headroom\n- Wait time negligible (<1ms average)\n- Could handle 2× traffic spike\n\nRecommendation: Current capacity adequate; monitor for growth
Result: 50% utilization | ~1ms wait | Sufficient capacity | Can handle 2× spike
Example 3: Support Ticket Queue Optimization
Problem: Support receives 200 tickets/day. Agents resolve 25 tickets/day each. Currently 10 agents. Average resolution time 2 days. How to reduce to 1 day?
Solution: Current State (using Little's Law):\n- Arrival rate: 200 tickets/day\n- Current agents: 10\n- Capacity: 10 × 25 = 250 tickets/day\n- Utilization: 200/250 = 80%\n- Observed time in system: 2 days\n\nLittle's Law:\nL = λ × W\n400 tickets = 200/day × 2 days ✓\n\nTarget:\n- Reduce W from 2 days to 1 day\n- Keep λ = 200/day\n- New L target: 200 × 1 = 200 tickets\n\nOptions:\n\n1. Add Agents:\n To achieve 1-day resolution:\n - Need lower utilization (~60%)\n - Capacity needed: 200 / 0.6 = 333 tickets/day\n - Agents: 333 / 25 = 14 agents\n - Add 4 agents\n\n2. Improve Agent Productivity:\n - Current: 25 tickets/day\n - Target: 30 tickets/day\n - New capacity: 10 × 30 = 300\n - New utilization: 67%\n - Would achieve ~1.2 day resolution\n\n3. Hybrid:\n - 12 agents at 27 ticket
Result: Current: 2 days, 10 agents | Target: 1 day | Need: 14 agents OR +20% productivity
Frequently Asked Questions
What is Little's Law?
Little's Law states: L = λ × W, where L is the average number of items in a system, λ is the arrival rate, and W is the average time in the system. It applies to any stable system: queues, inventory, work-in-progress. Example: if 10 customers arrive per hour and each spends 0.5 hours, there are 5 customers in the system on average.
What is an M/M/1 vs M/M/c queue?
M/M/1 is a single-server queue with random (Poisson) arrivals and exponential service times. M/M/c has c servers. M/M/1 is simple to analyze but limited. M/M/c models real systems better: multiple cashiers, multiple support agents, multiple API servers. As c increases, wait times decrease but with diminishing returns.
Why do wait times explode near 100% utilization?
Queuing theory shows wait time = service time / (1 - utilization). At 50% util, multiplier is 2×. At 80%, it's 5×. At 90%, it's 10×. At 99%, it's 100×. Small increases in load cause exponential wait time growth. This is why systems must operate below capacity.
How do I apply Little's Law to software systems?
Examples: (1) API requests: if 100 req/sec arrive and average response is 0.5s, 50 concurrent requests. (2) Support tickets: if 50 tickets/day arrive and avg resolution is 2 days, 100 open tickets. (3) Manufacturing: if 1000 units/day and 5-day cycle time, 5000 WIP units. Little's Law applies universally.
What assumptions does Little's Law require?
Little's Law assumes: (1) system is stable (arrival rate < service rate), (2) average arrival rate exists, (3) average time in system exists. It does NOT require: specific arrival distribution, service time distribution, or queue discipline (FIFO, LIFO, priority). It's remarkably general and robust.
How do priority queues affect wait time?
Priority queues serve high-priority items first. High-priority wait times decrease; low-priority wait times increase. Overall system metrics (average) remain similar per Little's Law, but distribution changes. Use priority queues when some items are more time-sensitive. Model each priority class separately.