A ticket reaches a buyer as a page, a QR code and a PDF. All three are pictures of the same thing: a ticket record that the platform holds. Producing those pictures has very different needs from serving a web page, so in eventOS it runs on its own.
Why not render inside the web request
Rendering a document is slow next to an ordinary request, and it arrives in bursts when a sale opens. If it shares a process with checkout, the moment the platform is busiest is the moment checkout has the least room.
It also needs less access than the web application has. A renderer has to know what one ticket looks like. It does not need to be able to read organisers' data, change inventory or touch payments.
What the renderer is allowed to know
The service that owns tickets decides that a ticket exists. It then hands the renderer a narrow request: this ticket, this design, produce the document. The renderer answers with the finished file and nothing else.
That narrowness is the point. If the renderer fails, the ticket still exists and the document can be produced again. If the renderer were ever compromised, it would hold very little worth taking.
The PDF is not the ticket
This is the distinction I care about most. The document is a representation of a record the server holds. It is never the source of truth.
Keeping that explicit is what makes the awkward cases simple. A ticket can be re-sent without creating a second ticket. A cancelled ticket stops working at the door even though the PDF still exists on someone's phone. An organiser can change the artwork for future tickets without altering the ones already issued, because each issued ticket remembers the design it was issued with.
What I check
Rendering can fail and be retried without issuing anything twice. A re-rendered ticket carries the same identity as the original. A ticket that has been cancelled is refused at the door whatever document is presented.