Say what you will about Ticketmaster, but their understanding of how to combine solid engineering with user-centered design is top notch. Take this anecdote from an experience I had recently:

Ticketmaster has super spikey traffic. Most days and times, it’s pretty normal, but if it’s the hour after a huge event opens up for sale, they need to handle an enormous amount of traffic.

In addition, Ticketmaster isn’t primarily a read-only platform like, say, a search engine, or a streaming service. No, if you’re trying to purchase a ticket, Ticketmaster needs to show you the exact seats that are actually available, not let you purchase tickets somebody else just purchased, display dynamic pricing based on purchases in the minutes prior, etc.

How do they handle all of this?

The crudest - and most effective - solution ever: Lines that make people wait.

That’s right. Ticketmaster doesn’t even try to handle the volume. Instead, they just admit they can only service a certain (small) number of customers at a time, and make everybody else wait.

Sounds easy, right? Kind of, but the UX needs to be able to answer some questions which can get tricky:

• Where am I in the line?
• How many people are in front of me?
• About how long do I have to wait?
• Is this information fresh?

Now, it would be super tempting to handle such sophisticated and realtime concerns using a technology like WebSockets. Ticketmaster doesn’t do this. Instead, it uses a simple polling mechanism. That’s right - Every 2 seconds, hundreds of thousands of people are hitting the same HTTP endpoint simply to know whether or not it’s their turn in line. And if not, when it might be.

Isn’t this overkill? Wouldn’t it be far more efficient for all those people to connect using a technology “meant” for persistent realtime communication? Actually, no. WebSockets are really expensive and complicated to run at scale. And they make a lot of sense when you need to solve for literal realtime constraints (like single milisecond chat exchanges). But they make a lot less sense when what one really needs is a simple few-second status check.

Ticketmaster has done an absolutely amazing job understanding their exact constraints, the UX that solves for those constraints, and the simplest, most cost-effective technology that fits the bill for the solution. This is what high quality product and engineering teams do. They don’t solve for product or engineering first, then the other second. They solve them together, concurrently. And they solve those difficult problems in the simplest ways possible.

{
    "isBeforeOrIdle": false,
    "pageId": "queue",
    "pageClass": "queue",
    "QueueState": 2,
    "ticket": {
        "queueNumber": "2588",
        "usersInLineAheadOfYou": "27",
        "expectedServiceTime": "10:13 AM",
        "queuePaused": false,
        "lastUpdatedUTC": "2023-02-15T15:13:00.587845Z",
        "whichIsIn": "less than a minute",
        "lastUpdated": "10:13:00 AM",
        "progress": 0.99,
        "timeZonePostfix": "ET",
        "expectedServiceTimeUTC": "2023-02-15T15:13:49.5878327Z",
        "customUrlParams": "",
        "sdkVersion": null,
        "windowStartTimeUTC": null,
        "windowStartTime": "",
        "secondsToStart": 0,
        "usersInQueue": 0,
        "eventStartTimeFormatted": "10:00 AM",
        "eventStartTimeUTC": "2023-02-15T15:00:00Z"
    },
    "forecastStatus": "InLine",
    "layoutName": "gateway-ui-22321a",
    "layoutVersion": 169309259950,
    "updateInterval": 2000
}