How this is built
Every page on both sites was rendered by Layrel's Tessitura adapter — the same code path a live Tessitura instance drives. Nothing on those pages is hand-authored HTML.
The Tessitura integration
The adapter takes its HTTP transport by injection. That one decision is what lets the identical code run against three things without modification: a live Tessitura instance, a recorded fixture set in the test suite, and the simulator that produced the pages you just looked at. Connecting it to a venue's Tessitura is a base URL and a credential.
The simulator implements Tessitura's published request and response contracts for the
endpoints a public website reads — /TXN/Performances and the single-performance
read — in Tessitura's own field shapes, PascalCase inconsistencies included. It exists so
this demo could be built and shown without a licence, and so the failure paths below can be
provoked on demand rather than described.
Tessitura stays the system of record
The CMS holds editorial content only: voice, imagery, context, tags. It is structurally
incapable of holding anything else — a content document carrying a title, date, venue,
price, availability or on-sale status is rejected at validation, not merely
discouraged by a style guide. Editors select a production; they never retype its data.
The join happens at render time on productionId.
The purchase path hands off to Tessitura Ecommerce (TNEW). The website never takes a payment, which keeps PCI scope out of the web tier entirely.
Surviving an on-sale
Tessitura is the system of record; it is not a CDN and must not be asked to behave like one. Every public read goes through a cache that is fresh inside its TTL, serves stale while it revalidates behind the response, and serves stale if Tessitura is unreachable — so an outage degrades to slightly old seat counts rather than a dead site.
The cache is single-flight: concurrent misses on the same key share one origin call. The first version of it was not, and a 200-reader test made 200 calls to Tessitura — the thundering herd that takes a venue site down the second an on-sale opens. That test is in the suite, and it now proves one call. This build read Tessitura 1 time to render 5 performances across both sites.
Two brands, one backend
Layrel Stage and Layrel Tickets are the same application, the same content store and the same Tessitura connection. What differs between them is a token set — colour, type, voice — and which events each brand publishes. 5 composed events were built once and filtered per brand. Adding a third site is configuration.
Accessibility
The City is subject to Title II. Accessibility here is enforced where it cannot be skipped rather than checked at the end: an image without meaningful alternative text fails content validation and the build stops. Pages are server-rendered and work without JavaScript, headings are ordered, the seat-availability table is a real table with a caption and scope, focus is always visible, hit targets are full-size, colour is never the only signal of status, and reduced-motion is honoured.
What this demo does not do
It reads. It does not write to Tessitura, take payment, or manage constituents — those sit behind TNEW and the Tessitura API by design. Editorial workflow, role-based permissions and media optimisation are described in the proposal; only the read path and the content rules are demonstrated running here.