As far as peak load is concerned, there are 2 things to consider:
To render charts, we rely heavily on edge caching (by Amazon CloudFront). All JS, HTML and CSS is served by a CDN. We only hit our own servers to fetch the chart and the seat statuses for the event - which are cached in memory. 60k renderings per minute is a load we can handle comfortably.
When booking we hit our database (Postgres) to persist the data. CDNs or in-memory caching don't help much in that respect. Still, we can handle about 30k bookings per minute with our current setup - and we can easily scale up the infrastructure with the push of a button if needed.
the first statusChange of a seat (or GA available space) in an event. All subsequent statusChanges for that seat for that event are included in the same single count. Sole exception is temporary reservation of a seat by use of “reserveOnSelect”, which does not trigger count if it is the only statusChange used.This means that the whole process of one end customer actually using one seat (normally resulting in a booking for a specific event), regardless of the number of status changes necessary to achieve that, is counted as one use.