In the spirit of software analogies to everyday things, and continuing ramblings on software security, lets consider a fast-food restaurant in a software engineering context.

The fast-food restaurant’s basic feature is the ability to go in, order some food, pay for it, and receive the order (preferably within a short period of time).

The fast food drive-through

At some point this wasn’t enough. Cars got popular, people were in a rush, and a new interface was dreamt up which could allow this workflow to be executed without having to park your car and enter the restaurant — the drive-through was born.

Presumably the naïve drive-through interface would mimic the user experience of the in-store interface: There are several windows with individual queues, you pick one and join the queue with your car, drive up to the window, place your order, pay, and receive food all at the same window, then leave.

This presents some problems because cars are not as small and agile as humans, so trying to mimic the same layout for cars as humans isn’t going to work very well. (You’d need a massive amount of room to let the car from each window drive off independently.)

Given the amount of room available at a typical restaurant, the drive-through would need to only have a single queue. You would join the back of the queue, eventually reach the window, place and order, pay, and receive food all at the same window.

Optimising throughput at the drive-through

This design is still as secure as the in-store experience, but because there is only one window and one queue it is a lot slower than the in-store experience, where there are multiple restaurant employees serving multiple customer queues concurrently.

So how do we make a multi-stage process at the lone drive-through window more efficient? We introduce parallelism through pipelining (as seen in most processor architectures these days). We split the multi-function order/payment/deliver window up into three separate windows (or a microphone and two windows) and specialise each window to a single task. (Fast-food restaurants are already good at efficiency through task specialisation.)

Now the order window (or microphone) can be ready to take the next order as soon as it is done taking the current one. The payment window can be taking payment for the first order whilst the second order is being dictated. Then the third window can be delivering the order whilst the second window is taking payment for the next order, and the order window (or microphone) is taking yet a third order.

Genius! We’ve improved the efficiency by allowing three customers to be served at once, whilst keeping to the space constraint of only having a single queue of cars at the drive-through.

Can you spot the security hole we’ve opened up with this optimisation?