Mother’s day weekend 2026 marks 20 years since I asked the question “Why should collaboration require centralised control of ticket inventory and surrender of control of your inventory to a ticket agent. Could we not flip it so the Fringe box office aggregated all the inventory available from all the venues that participate in the Fringe?”

This one idea then became the key feature of the VIA Ticketing System from Red61, shaping both the company and the business relationships their clients could form.

This enabled the inventory owners to both regain full control of their inventory, eliminate the single point of failure that was outside of your company’s control, while simultaneously allowing an unlimited number of other organisations to sell tickets on your behalf, using either allocations or full real-time access to your availability

Initally this was just the larger venues being able to cross-sell and run their own ticket agency, then also adopted by the Edinburgh Festival Fringe Society (EFFS) in 2009. This has allowed the Fringe to massively increase both the number of tickets sold by their box office agency as well as the total number of tickets sales grow. Red61’s solution has also been able to scale far futher than the old system to allow many more venue operators to be able to have this control of their ticketing and sales opertunities, so there are now more than tripple the numbers of connected systems. This ties in closely with the EFFS mission to facilitate any one to be part of the festival, no matter how big or small your venue.

This came many years ahead of attempts to allow the London West End theatres to move away from fixed allocations of seats and is still more advanced than the current solutions used.

This system has now sold tens of millions tickets! When your browse sites like edfringe.com, you experience a unified set of shows to purchase from, for the whole festival, with most tickets for sale right up to the start if the show - great for those last minute inpluse buys after being given a flier for a show starting in 15 mins!

By designing the system with this concept of realtime aggregation, rather than replication, this required leaning into performance and resilience as key aspects of the system. This gives benefit not only to when using this distributed approach, but also as part of a more traditional box office setup.

Cache, cache and cache some more! The fastest code is the code that doesn’t run at all. If you can fetch data from a cache, this both makes the system more responsive, but critically WAY more scalable. One of the questions I got asked by box office staff was “why is the ticketing system faster when we are really busy, than in the morning when there isn’t much happening” - this was due to the cache warming up as the day progressed. Fundamentally computers can’t really multitask, just switch between tasks quickly, the more they have to switch, the worse they perform. For example, trying to read two different files from different parts of the hard disk, the read head can’t be in two places at the same time, so you lose a lot of time moving back and forth between the two conflicting positions. Other operations suffer too, like the very small caches inside the CPU, so it’s only only physical items that lead to the concurrency performance hit.

So the magic of correctly implemented caching is that instead of your load growing with the number of requests and response times rising exponentially with concurrency, you load will only rise until you are doing the number of computations to calculate each value of the time period of the cache period. For example, if you have a cache of 15mins then you will never run this code more that 4 times in a hour, whereas a busy website might be requesting that data many times per minute or even second. No matter how well you optimise that code, if you are running for each request, the more requests, the more concurrency, so the slower you run, so the more likely you are running concurrently … etc

For resiliency, it’s critical that the customer arriving at the theatre can always get their ticket or scan their e-ticket to see the show, so even when the systems can’t talk to each other, they need to gracefully degrade while still meeting operational needs. This does require some level of data duplication, but only immutable data, so no worries about replication.

It’s all too easy to gloss over architectural decisions in software design, I especially worry that the rise of AI coding will means less attention is given to it - the AI (currently) always says yes and will try and work around the limitations, rather than suggesting that this is going to be a nightmare bloat of code that would take a human weeks or months to write and perhaps you need to go back to the drawing board and come up with a more elegant solution.