Eventbookings - Event ticketing platform

Challenge

Event ticketing has one of the harshest failure modes in SaaS: the moment a popular event drops, traffic spikes by orders of magnitude, payments must clear in seconds, and any bug in the checkout flow is visible to thousands of customers simultaneously. Pre-launch testing needed to cover not just happy paths but the edge cases that only surface under contention - oversell prevention, payment retries, partial refunds, currency rounding across regions.

Approach

Built a layered automation strategy:

• API-first regression for the booking core (availability, hold, confirm, refund) so the most critical paths were covered without paying the cost of a browser per test.
• Playwright end-to-end for the customer-facing flows that genuinely need a real browser - Stripe Elements rendering, region-specific payment methods, redirect-based 3DS challenges.
• K6 load profiles modelled on real event drops, so we could see how the system behaved before the actual drop did.

Test data was generated deterministically per run so cross-environment parity stayed clean - same fixture in dev, staging, and the smoke layer against production.

Outcome

Pre-launch checks for new event types went from a multi-day manual cycle to a CI-gated run that finished inside an hour. Confidence around payment edge cases rose enough that the team shipped a refund-handling refactor without a rollback window - something they wouldn’t have attempted before.

What I’d do differently

Mocked Stripe earlier in the API layer. Going against the real Stripe test environment for every assertion was correct for E2E but ate CI minutes - should have stubbed at the boundary for the unit-style billing tests from day one.