# One Checkout Line or Three? — Plain-English Summary

## The question
A store has 3 identical checkout counters. Is it better to have **one shared
line** feeding all 3 counters, or **three separate lines** where each new
customer picks the shortest line and stays in it?

## How we answered
We simulated a fictional shop on a computer. To be fair, we used **exactly the
same customers for both layouts** — the same people showed up at the same times,
and each specific customer took the same amount of time to check out. The only
thing that changed was how the lines were organized. That way, any difference
we measure is caused by the line design, not by luck of who happened to show up.

We ran **30 independent 8-day shop streams** per scenario (each run = ~5,000–6,000
customers) and counted wins. "Very slow customers" = 3% of people take around
70 minutes (price checks, card declines, missing barcode); their share was sized
so the *average* checkout time stays 6 minutes — the tail, not the workload, changed.

## What we learned

1. **The shared line is faster, always.**
   - Typical case: average wait **4.6 min vs 5.0 min** (shared vs separate).
   - With slow customers: **15.3 vs 16.9 min** — the gap roughly doubles in
     absolute terms.
   - Busier store (90% busy): shared still wins, by even more.

2. **The shared line is much kinder to the unluckiest customers.** The 10% of
   customers who wait the longest:
   - Typical case: wait **21.7 min vs 26.1 min** on average.
   - With slow customers: **78 min vs 106 min** — a ~28-minute penalty for
     choosing separate lines.

3. **It is not a fluke.** Repeated the whole experiment many times with fresh
   random streams: the shared line won on average wait in **30/30** typical
   streams, **26/30** and **25/30** in the harder scenarios — and won on the
   slowest-10% metric in essentially every one (30/30, 29/30, 30/30).

4. **Why the separate lines lose.** In a separate line, if you stand behind one
   slow customer, you are *stuck* — nobody ahead of you is being helped and you
   are not allowed to move (our rule). In one shared line, a slow customer only
   blocks 1 of 3 counters; the other two keep pulling people out of the queue.
   We verified this directly: customers who arrived during a slow (>30-min)
   checkout waited **44 min in the shared setup vs 53 min in separate lines.**

5. **The one honest caveat.** One shared line has a single "point of failure":
   when a slow customer is at the head of the one line, *everybody* sees it.
   That slightly raises the wait of the *typical-but-not-extreme* customer and
   occasionally (about 1 run in 6–8 in the hardest scenarios) flips a short
   head-to-head stream in the separate setup's favor. The shared line still
   never loses on the average, and almost never on the unluckiest customers.

## Bottom line for the reader
> One line feeding several counters is the better design — slightly faster on
> average, much better for the people who end up waiting longest, and the gap
> widens exactly when it matters most: when the store is busy and when slow
> customers show up. (Banks and airport security use this design for good
> reason.) It loses almost no coupons: a bit more customers get zero wait in
> the separate design, at the price of much worse worst cases.

## Assumptions (be honest about these)
- Customers arrive at random, like a Poisson process (typical for walk-in traffic).
- Checkout times vary widely (exponential, average 6 min). "Slow customers"
  variant: 3% take ~70 min on average, with the *average* checkout time unchanged.
- Everyone joins at the back and is served first-come, first-served. In the
  separate-lines variant, people pick the shortest visible line (counting the
  customer being served as occupying it) and then must commit — no jockeying.
- No one abandons the line; counters are identical; queue space is unlimited.
- Caveats: exponential service exaggerates very long services slightly; real
  stores' results depend on impatient customers, express lanes, and jockeying,
  all of which shrink the separate-lines penalty but don't reverse it.

## Files kept for reuse
- `queue_sim.py` — the simulator as a small program with command-line knobs
  (`--rho` how busy, `--service-mean` average checkout time, `--slow-share`
  fraction of slow customers, `--streams` how many trials, `--seed`).
  Example: `python queue_sim.py --rho 0.9 --slow-share 0.03 --streams 50`
- `results_summary.json` — scenario table behind the chart (all four scenarios).
- `results.json`, `results_heavytail.json` — the first two experiments
  (baseline paired simulation; heavy-tail variant with mechanism checks).
- `queue_comparison.png` — the summary figure.

## Try it yourself ideas
- Busier store: `--rho 0.95`
- Only slow checkouts matter: `--slow-share 0.10`
- A store that's fast on average: `--service-mean 3`
- More counters: `--counters 5`
