Cache the venue place map: VenueMapBuilder loads every place of a venue on every request, inside an uncacheable form

VenueMapBuilder::build() queries and loads every place of a venue with no range and no caching, then filters each one through PlaceAvailability::placeOpen(). It renders inside a FormBase, so no page cache absorbs the result. For a 3,000-seat hall that is 3,000 entity loads per visitor per page view, precisely during the booking rush this module exists to survive.

This is a scaling limit rather than a defect, and everything around it is careful, which is why it stands out: the listing queries use pagers or ranges, the availability feed is a cacheable response with slot and category tags and deliberately clamps its month parameter against cache amplification, the capacity queries push counting into SQL, and the placement storage schema adds the composite indexes these lookups need.

The build splits cleanly in two. Geometry (each place's coordinates, angle, grade, section, row, printed label) changes only when a venue or its configuration is edited. The availability overlay (which places are taken, which are the visitor's own) changes on every booking. Today both are recomputed together on every request.

Proposed resolution. Cache the geometry in the default bin, keyed by venue and configuration, tagged with the venue, section, grade and place list tags so an edit invalidates it. Compute only the overlay per request, from the aggregate queries PlaceAvailability already runs, and let the composite slot/place/state index serve it. That turns thousands of entity loads into one cache get plus two indexed aggregate queries.

One caveat worth designing for: the cache item for a very large venue should be a compact packed array rather than the render-ready structure, or the memory saved on queries is paid back in cache size.