Category: av

For a prank in July, a group of 50 people ordered Waymos to same location in San Francisco:

The plan? At dusk, 50 people went to San Francisco's longest dead-end street and all ordered a Waymo at the same time.

The world's first: WAYMO DDOS pic.twitter.com/DEDH0tdMKP

— Riley Walz (@rtwlz) October 12, 2025

Although this was meant as a statement on the prevalence of Waymos going through our city, it could actually be treated as a valuable learning experiment.

This is exactly the scenario AVs will have to deal with at the end of a concert or sporting event: Big bursts of requests to the same location.

Uber and Lyft already do this, but Waymo is a significant variation of the problem. Waymos are fungible; any car can go anywhere within the service area. Uber and Lyft are heterogeneous. Some drivers will only go to some destinations.

When vehicles are fungible, you shouldn’t have to wait to match up to “your” car to arrive. Just climb in, scan a QR code and accept the ride with your destination pre-programmed. Waymo just dispatches based on the number of cars requested to the site.

And if you’re thinking, “you just described a taxi line”: you’re right. Some things are the way they are because they work. You don’t have to reinvent all the wheels.

But this will be a much smarter taxi line. Because Waymos all “work” for the same entity, dispatch can be optimized. The system knows how many vehicles are going short distances versus how many are going long distances. That can be used to predict replenishment rates.

Next time someone tries to prank your system, see what you might be able to learn from it.

Here’s an extended conversation I had with ChatGPT on the topic. My prompts are in blue.

Yes — that absolutely counts as a valid use-case simulation, just not a customer-facing one.

Here’s why, framed like a product or systems-engineering analysis:

🧠 1. Nature of the test

It’s essentially an unscripted load test — a “real-world denial-of-service” simulation on a physical mobility network.
In software terms, you stress the dispatching layer (scheduling, routing, capacity throttling) to reveal how gracefully it handles sudden demand spikes in a constrained geography.

---

⚙️ 2. Why it’s equivalent to a real scenario

• Big concerts, sports events, parades, fireworks, or evacuations can easily produce the same burst pattern: 50–500 simultaneous ride requests from one location.
• The fact that Waymo’s system:
  • accepted the requests,
  • held them for ~10 minutes,
  • then triggered a $5 no-show,
  • and finally geo-fenced the area until morning,
    shows an intentional fail-safe behavior — basically, rate-limiting at the fleet-ops level.
• That’s almost textbook “load shedding.”

---

🚦 3. Why it matters (and what it tested)

It exposed how Waymo handles:

• Dispatch saturation (fleet availability vs. request queue)
• Pricing fairness under congestion
• Dynamic service throttling (auto-suspending requests within a radius)
• Edge case recovery (do vehicles idle, circle, or reroute?)

That’s the mobility equivalent of a DDoS → graceful degradation test.

---

🧰 4. In system-design language

Dimension	Digital Analogue	What Was Tested
Concurrent requests	API call surge	Dispatch queue resilience
Geo-local clustering	Server region overload	Routing algorithms
No-shows	Request cancellation spam	Billing and trust models
Service blackout radius	Rate limiter / circuit breaker	Containment strategy

---

🧩 5. Conclusion

Yes — it’s a valid “use case” in the sense of operational resilience testing.
It’s not a consumer use case (no normal user would order 50 cars at once), but it’s exactly the kind of chaotic event a robust system should survive.

It was, unintentionally, a crowdsourced stress test — a real-world equivalent of fuzzing a transportation API.

---

my analysis. But this is not something you can write off entirely as an edge case. A concert letting out would have similar dynamics: 100 people ordering a car to the same highly congested place at roughly the same time.

Though in general, concerts should have cars picking up first come, first serve for Waymo. When vehicles are fungible, you shouldn’t have to wait to match up to “your” car to arrive. Just climb in and accept the ride. Waymo just dispatches the number of cars requested to the site.

This is different from Uber/Lyft, where each driver might only be willing to accept some rides.

---

Your analysis is spot on. A “flash crowd” at a concert is not an edge case—it’s a design target. Here’s how I’d frame it and what Waymo (or any AV fleet) should do.

Why this isn’t an edge case

• Concerts, games, parades, festivals, airport surges = predictable burst loads (100–1000 simultaneous requests in a tight geofence).
• The pattern (short time window, constrained curb space) stresses dispatch, curb management, billing, and safety—core, not fringe.

“Any-car boarding” when vehicles are fungible

You’re right in principle: if cars are identical, don’t force 1:1 rider↔car matching. Do queue-based boarding:

1. Virtual queue + staging
   • Riders join a first-come virtual line; vehicles stage in a nearby lot.
   • System meters cars to the curb like an airport taxi stand.
2. Gate/zone boarding
   • Curb split into Zones A–F. App assigns you “Zone C, Gate 2.”
   • The first free car at that gate takes the first rider in that sub-queue.
3. Tokenized boarding (safety/identity)
   • Rider gets a one-time QR/NFC token; car verifies at the door before it unlocks.
   • Solves “just climb in” without impersonation or destination mix-ups.
4. Destination capture
   • Rider’s destination is already bound to the token; car loads it on scan—no driver needed to confirm.
5. Batch dispatch
   • Fleet sends N cars based on queue length + curb capacity, not raw request count (prevents street clogging).

How this differs from Uber/Lyft

• Human drivers are heterogeneous (preferences, cancellations, route knowledge). AVs are homogeneous and centrally scheduled → queueing works better, cancellations vanish, and assignment can be purely algorithmic.

Policies to make it robust (and abuse-proof)

• Geo-no-show rules: During events, waive or alter no-show fees; instead, auto-expire tokens after X minutes so cars don’t idle.
• Throughput > fairness when jammed: Prioritize curb dwell time targets (e.g., <30s per pickup) over strict “your exact car” promises.
• Crowd control UX: Big on-site signage: “Open Waymo → You’re in Zone D → Have QR ready.” Staff or cones if needed.
• Predictive staging: Use tickets/venue calendars to pre-position vehicles; start trickling cars in before end of show.
• Dynamic geofencing: Expand pickup perimeter when congestion spikes; app walks late riders to less busy gates.
• Pooling lanes (opt-in): Offer pooled rides to the top 5 destinations; massive efficiency gain post-event.
• ADA & priority lanes: Dedicated gate for wheelchair-accessible vehicles and vulnerable riders.

What to measure

• Queue wait time (p50/p90), curb dwell per car, aborted pickups, re-route time, blocked-lane minutes, and rider NPS in surge windows.

Bottom line: Treat concert let-outs as normal operating mode for a city AV network. With tokenized “any-car” boarding, zoned curbs, and batch dispatch, an AV fleet should outperform human ride-hail precisely in these moments.

---

And if you’re thinking, “you just described a taxi line”: you’re right. Some things are the way they are because they work. You don’t have to reinvent all the wheels.

---

Exactly — that’s the insight most product people miss when trying to over-optimize transportation UX.

“Some things are the way they are because they work.”

The taxi line is the canonical example of distributed load balancing via physical queueing.

Why taxi-line logic endures

• Human throughput: The average person can process “next car in line” faster than any app-based re-matching algorithm.
• Fairness: FIFO feels equitable; no surge pricing math to justify.
• Predictability: Riders see progress in front of them—no uncertainty penalty.
• Parallel scaling: You can add cars or lanes instantly without software changes.

Where digital can help without reinventing

• Digitize arrival prediction (so users know wait time before walking to the queue).
• Add tokenized boarding (QR/NFC) to avoid destination confusion.
• Use dynamic lane allocation based on event size and curb length.
• Integrate fleet telemetry to keep staging optimized and streets clear.

So yes—Waymo (and any AV network) could evolve toward a smart taxi-line rather than pretending the entire system must be personalized. Sometimes the best product design isn’t disruption; it’s rediscovery of what already solved the coordination problem elegantly.

---

And unlike taxis, with the networked fleet, you can predict how quickly a vehicle can be recycled. Dispatch more if destinations are far away, fewer if all the destinations are close by.

---

Exactly — that’s the breakthrough: a taxi line with telemetry.

Classic taxi stands operate on visible depletion — you only know you’re running low on cars when the line gets long.
A networked AV fleet, by contrast, has full recycling awareness:

---

♻️ Predictive Recycling = Dynamic Supply Elasticity

Each completed ride isn’t just a release — it’s an input into a rolling forecast:

• Destination distance & dwell time → determines “return-to-availability” delay.
• Traffic density → informs congestion-based throttling.
• Queue depletion rate → signals when to pre-stage reinforcements.

So the dispatch layer can do what human taxi dispatchers wish they could:

Dynamically modulate fleet allocation based on real-time turn-around velocity.

---

🧮 Example

Say a concert ends with 200 riders:

• If half of those trips are long-haul to suburbs, your local queue will empty slowly → dispatch more cars.
• If they’re all short downtown hops, most cars recycle in under 10 minutes → hold off on replenishment.

That feedback loop keeps streets clear without starving demand.

---

⚙️ Architecture Implications

Signal	Used for	Result
Mean trip length	Fleet staging	Fewer idle vehicles clogging the curb
Mean curb dwell	Pickup cadence	Improved curb throughput
ETA variance	Queue smoothing	Riders perceive fairness
Fleet congestion map	Dynamic pricing & staging	Load balancing by zone

---

🧭 Conceptual shift

Instead of dispatching to riders, dispatch to the system’s depletion curve.

That’s what AVs make possible — a closed-loop logistics model for urban mobility.
It’s not “ride-hailing” anymore; it’s real-time fleet orchestration at the level of aircraft gate scheduling or warehouse robotics.