Is Disney's FastPass Valid and/or Useful Queue Theory

At Disney World, they use a system called Fastpass to create a second, shorter line for popular rides. The idea is that you can wait in the standard line, often with a wait longer than an hour, or you can get a FastPass which allows you to come back during a specified time block (usually a couple hours later) and only wait for 10 minutes or less. You can only be "waiting" for one ride at a time with a FastPass.

I have been trying to figure out the queue theory behind this concept, but the only explanation I have found is that it is designed to get people out of the lines and doing things that will bring in additional revenue (shopping, eating, etc).

Is this why FastPass was implemented, or is there a real visitor efficiency problem that it solving? Are there software applications that have applied similar logic? Are there software applications that should apply similar logic?

Part of the problem I see with implementing something similar in software is that it is based on users choosing their queue. Do to the faster wait cycles in software, I think a good application of this theory would require the application to be smart enough to know what queues to place people in based on their needs without requiring end-user choice.

UPDATE

12 years (and two major updates to FastPass later), Disney's FastPass: A Complicated History gives the in-depth, definitive answer of "it's complicated"

It's about accumulation, not queue efficiency.

Fastpass works because it makes the individual items in the queue more efficient in "consuming" something. It's not so much a queue like a processor waiting for instructions to execute as it is people waiting in line for food.

In the case of people at Disneyland, it allows them to maximize their fun.

Think about a processor accepting instructions. Each instruction is waiting to get executed in the queue, to perform its task. Now change it up – imagine each instruction is waiting in line not to execute an instruction, but to get something from the processor – each time it hits a processor it is rewarded with a gold star, and its job is to accumulate as many of these as possible.

Fastpass is like allowing the instruction to go somewhere else, to a different processor, to get a gold star there, before returning back to the main processor to get the golds star from it.

In the case of users at Disneyland, they're interested in having fun – accumulating ride experiences. The Fastpass allows for a maximization by allowing the user to find a different ride with a shorter line, so they can accumulate more in a shorter time.

The fast pass line is obviously not going to increase total throughput on a given ride queue, but it does help in resource scheduling and resource assignment where people and rides are the resources.

Like I said, you aren't going to create any more total throughput for said ride, but there may be rides being underutilized elsewhere. If you are now able to ride these rides as well as the rides you have to wait on, then you can increase the overall efficiency of the park. What I mean by that is minimizing the amount of rides that are running below passenger capacity.

If you have computer resources sitting idle, waiting to perform a task that might take a long time, it makes sense to utilize this resource for something else in the meantime right? It's simple from that perspective.

I've tried FastPass, and this is how I see it:

Let's say you go to a ride with 1h expected waiting time, if you go to FastPass, you will get an assigned time period where you are guaranteed immediate entry. It's usually after more than 1h.

We got FastPasses for the popular rides, and during that time,queued in 10-15m queues allowing us to queue and go to 3 rides while being in the FastPass virtual queue. They also gave us extra uncounted FastPasses to some very unpopular rides, if we used those we would get some load off the more popular rides and fill the very unpopular ones.

Here's a graphic comparing the time we spent vs the non-fastpass option:

It seems to me as a valid queuing theory, it allows resources with less expected wait times to be executed while delaying one with a higher expected wait time even more.

The FastPass basically implements non blocking visitors with some kind of priority queue. They don't block, they don't sleep, they spend money. It works because john uses it at 11:00 AM, joe uses it at 11:15 AM (or 11:01 am). Now, if everyone had a fast pass, the regular line would be much faster while most visitors spent more money on food and gifts. For Disney, this is the desired effect, to a degree.

The pass makes some assumptions and has some limitations. It assumes that fastpass holders are the minority .. if that changed, they would have to make the pass work on multiple rides, or fastpass holders would spend money while seeing very few people in the regular line .. counterproductive. Since only one ride is supported, no two fastpass holders will ask for the same ride at once.

Now, considering that Joe might leave the park prior to taking his turn, you would have to come up with some kind of visitor 'futex' to make the system efficient. If joe left, and john arrived early, john could ride. Moreover, John would wonder why his fast pass did not notify him that he could ride nn minutes sooner. That's where it really gets fun, what if Joe left just to get some sunscreen from the car and returned? After all, his turn is two hours away, unless 200 more people before him left the park while he was blocking (while getting sunscreen), a task that can't be interrupted. So in that instance, we put Joe in some kind of disk sleep, or sleep that can not be interrupted or killed. He gets no signals, he's not polling anything, he's out of the park.

This is the kind of theory that drives practical lock free programming. Its as interesting as the dining philosophers problem, in fact more.

As far as Disney goes.. this is not a bug, its a feature, people are less inclined to leave the park while being more inclined to spend money.

In an ordinary queue you can't really estimate how fast you get your ride. You're nervous and sometimes think about just dropping the idea.

With FastPass you "know" that the ride will happen in a precisely defined time period. You are "sure" about when this happens and think about quitting less often. You go shopping and eating and return when needed. You are likely to return since you have applied for the ride in advance and feel commitment. Joel Spolsky describes a similar commitment idea used at Starbucks queues.

So FastPass is a kind of convenience for both the park and the visitors. Visitors are more delighted and the park can sell them more while they are waiting.

Just an example of good social engineering.

I think in a way you could compare this with asynchronous programming model.

You ask the system to execute an action and you'll come back later for the result.

The big difference is that you either specify which event/callback to call when done or are required to enter the wait at a time when your ready to wait. I haven't seen a mechanism which would tell you to come back at a later time and be guaranteed lower waiting times.

To me this seems like a priority queue.

When first taking a SpeedPass one achieves a higher priority. Then when popping off the general line queue the SpeedPass has greater priority in the queue.

And if we're in agreement that this is a priority queue, then the most obvious software implementation is OS scheduling

Modified from the scheduling wiki article:
> The Disney Land scheduler is concerned mainly with:
>

• Ride utilization - to keep the ride as busy as possible.
  >
• Throughput - number of people that complete their ride per time unit.
  >
• Turnaround - amount of time to execute a particular ride.
  >
• Waiting time - amount of time a person has been waiting in the ready queue.
  >
• Response time - amount of time it takes from when the line was queued until the first response is produced.
  >
• Fairness - Equal ride time to each person.
  

The FastPass idea to me looks like a solution for systems where I need to perform tasks 1 through N and based on some knowledge I have about myself (at Disney, I might know that my kids would be plenty happy riding Test Track while waiting for the Soarin' FastPass time slice to arrive) I could schedule myself to go into 'FastPass' queue for task N and also get into the standard queue for task M. This would work where the order of task isn't necessarily important and where queue time was known and I could estimate how long it would take to do task M or N. Not sure I've got a good real-world programming example though - much of our thinking is linear in nature and so our workflows tend to be that way.

FastPass allows you to wait in multiple lines at the same time. It allows you to avoid waiting, but increases the average wait time because the lines effectively get longer.

But most people don't spent their entire time going on rides. Some events, like the parades, don't really have a waiting time. By using a fast pass you can go to more of these no-line or short-line events without sacrificing as many long-line rides.

There are two places that come to mind that have similar behavior in software development for me. However, neither is an exact analogy, since they both require

The first is asynchronous programming. As mentioned before, there are some differences between the async model and the fastpass model, in terms of how you wait. However, some other programming models (such as Message Passing Interface) give you some other options, which probably get a little closer to the FastPass model.

In particular, I was thinking of the MPI_Gather methods in MPI - they use a model that's probably a little bit closer. Every function is passed out around the cluster, and then you can call gather from the root to get the currently processed data. The goal is the same (keeping everyone waiting less [not blocking on the user] and walking around, spending [or processing data]).

The other place I can see a similarity is in advanced threaded programming models, such as the new scheduler in the TPL. One of the main advantages of the TPL coming in C# 4 is that the scheduler will allow work stealing, which to me seems like a clear implementation in software of trying to shift around the lines dynamically - which ties back to FastPass. One of the nice things with fastpass is that you sit in line less, and ride more, and move around more. With TPL, there is (hopefully) less blocking and waiting, since a thread who has finished its queue can steal tasks from other queues.

One interesting aspect of FastPass is that it introduces a feedback channel for Disney. By having a single line that almost always waits for attraction to become available there is not much you can do except somehow measure how long the line is at fixed time intervals during the day. Using FastPass Disney collects demand and traffic data per attraction in real time and already digitized - it should go to their data warehouse for mining right away.

I tend to agree that those who qualify FastPass as a resource allocation system more than a resource queueing system. Another analogy would be to treat every Disney customer as OS process that is a single-threaded until a customer picks up a FastPass. This makes customer a 2-threaded process that keeps cycling throughout the park as before and is running another thread that waits its turn for designated resource (FastPass attraction). Allowing multiple FastPasses to users (processes) will make such processes more multithreaded. Thread synchronization takes place when customer finally gets to FastPass attraction to enjoy it.

The only software analogy I can see is that this method avoids overflowing the queue buffer - if many clients all try to add to a queue at roughly the same time it could quickly fill up that queue. If clients are asked to wait a given length of time then they have to buffer their (relatively) fewer items locally before adding to the queue.

In most other cases however this leads to less efficient throughput as it could lead to the queue becomming starved if the wait times are poorly chosen.

Try writing a test application that uses queueing both with and without 'FastPass' under various metrics and comparing the results - and let us know if you find anything interesting! :)

Don't know about how it would be applied in software. But the system definitely has its advantages for visitors: you can have a Fastpass for one ride, and meanwhile go to another ride whose line isn't as long (or, as you say, go shopping, eating, etc.). It was quite the lifesaver when I and my family were there (though admittedly, it was the off-season).

Given that it's being exploited, you'd have to trust the queue users ;-)

From my supply chain class, the aspect of queuing that came to me immediately is that is reduces your perceived wait time, so people don't mind waiting at all. I don't think it shortens the main lines, but it does ease somebody's anxiety about waiting in the regular line, since they know that as soon as they get off the ride, they can get right back on a second time (if their fastpass time is up, anyway).

I know that perceive that I can ride way more rides with the fastpass, though I don't know if it's actually the case or if it's just a clever re-framing of my wait time.

> the only explanation I have found is that it is designed to get people out of the lines and doing things that will bring in additional revenue (shopping, eating, etc).

I think you've hit on the main point there, but you make it sound more corporate-evil than perhaps it deserves. I'd certainly rather “virtually queue” whilst shopping and eating than physically queue in a line.

Theoretically, FastPass could try to schedule more people at times when natural demand was lower; that's what you'd do to get more throughput out of a real scheduled queue. But in practice, I suspect the rides are operating pretty much at capacity for most of the day, so there is little productivity to be gained from this.

It is about resource scheduling for popular rides as well as a way to generate additional revenue by selling merchandise. If you are waiting in a line, it means that you aren't afforded the opportunity to spend more money.

It is in Disney's best interest to satisfy their customers. While merchandising is surely significant revenue, getting repeat customers is many times more valuable.

If I pay $150 for a 1 day park-hopper ticket and only get to go 10 rides because the lines are so long I would question whether those rides are really worth $15 dollars a piece. If, however, there is a way for me go on 30 rides then I will have a better experience, be less likely to question the value of that experience and be more likely to return and give Disneyland another $150 + food + merchandise.

Prior to FastPass, the only differentiator between my riding 10 rides and 30 rides was how crowded the park was. This is a common problem that other desirable attractions have attempted to address in other ways. For example, Northstar ski resort at Tahoe will limit the number of lift tickets they sell on a given day (or at least they used to). This also addresses the problem, but in a way that more negatively impacts revenue.

In software, a similar paradigm would be loading a web page. In ancient times this process was single threaded: get all the content, render all the content and display the page. As traffic and data increased (specifically the incorporation of images) this model faced the same problem as Disneyland. If there were a lot images on the page and it took a long time to load, I wouldn't wait around for the content and might not bother ever coming back to that site.

Now days web pages are loaded differently. The content is loaded, rendered and displayed first while another thread loads, renders and displays the images. This vastly improves the user experience and, provided there is desirable content, I will continue to come back to the site and it can turn my repeated page views into $$$.

This resembles a real-time OS in some regard.

Some processes has a fast pass, and are marked as real-time.

They have a guarantee that they will get the resource within a certain time period. They don't get to jump the queue, but they can push in! While they are not using the ride, other non real-time guests can use it.

-Alex

This is great stuff. Disney is essentially making two queues, with linearly lower service rates depending on the number of FASTpass's distributed.

The short FASTpass queue can be modeled as a queue that's always in equilibrium for a short wait. Keeping the queue short minimizes feedback between the two queues -- which is good for stochastic modeling. The other queue is a typical queue, with a slower service rate.

Of course, if the FASTpass quota ever got too large, feeback between the two queues would ensue, making the system Chaotic, and minimizing the effect of queueing models to describe the results.

Another strategy is to minimize user waits would be strictly to schedule rides by appointment, in which case it's a pure batch queue, and easy to optimize. I don't think that would work in the USA. :-)

You do not get on more rides. The lines for unpopular lines are longer now, because more people are killing time on them while waiting for their popular-ride passes to mature. Capacity is capacity.

"Twitter is currently really busy. Please come back between 15:00 and 15:15 and we guarantee to get you your tweets in 5 seconds or less."