Concurrent Bookings

Concurrent bookings measures the number of simultaneous booking operations the system can process without latency degradation exceeding 20% above the single-booking baseline. A 'booking operation' includes the full pipeline: intent extraction, venue availability check, reservation creation, confirmation message delivery, and (for A2A bookings) ClawPulse envelope round-trip.

The 50-concurrent ceiling is governed by two bottlenecks: the LLM concurrency semaphore (capped at 30 simultaneous Claude API calls) and the A2A gateway connection pool (capped at 20 concurrent outbound envelopes). Since not every booking requires both an LLM call and an A2A hop simultaneously, the system can sustain 50 concurrent bookings by interleaving these resources. Beyond 50, queue wait times push booking latency past the 20% degradation threshold.

In practice, we've never seen more than 12 concurrent bookings in production — peak load occurs during Friday evening 6-8 PM Bali time when users are booking dinner reservations. The 50-concurrent figure comes from load testing with realistic booking patterns, giving us 4x headroom above observed peak. We plan to increase this to 100+ by introducing a dedicated booking queue with priority scheduling in Q3 2026.