queueing-theory: the textbook symbols, repurposed for engineering teams

A repository that is one README and one PDF

The tree is short enough to list in full. There is a `README.md`, a `CITATION.cff`, a `CODE_OF_CONDUCT.md`, a `cspell.json` spelling dictionary, and a vendored PDF named for seven insights into queueing theory by Bob Wescott. That is the whole project. There is no code directory, no build system, no release history and no issue backlog worth speaking of.

A `CITATION.cff` in a repository like this is a small signal about intent. It means the author wants the document treated as a citable work rather than a blog post that will be lost, which is consistent with the whole approach of taking established notation and giving it a stable written form. The spelling dictionary is a small hint about the author's habits too, since queueing theory has a genuine orthography problem and the two spellings in circulation are not interchangeable in practice for anyone who reads this document as normative.

The repository is not archived and its last push was on 2026-06-07. No license file is present in the repository, and the metadata records no license, so there is nothing here to tell you what you may do with the text beyond the ordinary default.

The description reads as an introduction for software development, and that framing is the entire pitch. This is the textbook content of an operations research course, reorganised around the four situations a software team runs into.

Four situations, and the products that implement them

The introduction does something that makes the rest of the document make sense: it grounds the mathematics in four concrete cases rather than starting with an abstract customer. Customer service responsiveness is the case where you want to analyse how customers request sales help and support help and how fast the team responds, with Salesforce, LiveChat and Zendesk named as the tools that record it.

Project management kanban planning is the case of tracking lead times and progress times as a feature idea moves from design to delivery, with Asana, Jira and Microsoft Project listed. Inter-process communication message queues is the throughput case, one program sending requests to another, with RabbitMQ, ActiveMQ and ZeroMQ. DevOps continuous deployment pipelines is the capacity case, ensuring the CI server has room to test and deploy, with Jenkins, Bamboo and Azure DevOps.

Naming the products is a deliberate move. Queueing theory is usually taught with a customer standing in a line, and that abstraction is exactly what makes it feel irrelevant to a developer. Substituting a build queue or a support queue makes the arrival rate and the service rate measurable things that already exist in a system the team owns, which is what makes the notation worth learning.

The examples inside each section then use the customer waiting in line, so the document switches back and forth between the concrete framing and the traditional illustration.

Queue disciplines named in plain language

Before any formula, the document establishes what a queue chooses to serve next, and it does it with definitions rather than jargon. First In First Out serves the customer who has been waiting the longest. Last In First Out serves the one who has been waiting the shortest, which reads as perverse until you notice it describes a stack.

Priority serves customers based on a priority level, and the document notes those levels could be based on status, urgency or payment. Shortest Job First serves the customer needing the smallest amount of service, and Longest Job First serves the one needing the largest. Time Sharing serves everyone at the same time, with capacity distributed evenly among everyone waiting.

That list is the classic queue discipline set, and the value here is having it in one place with a software reading attached to each entry. When a team argues about whether a build queue should be LIFO, priority or FIFO, this is the vocabulary for the argument.

The document also notes that queue terminology is a big topic, and this section covers some of the common terms rather than all of them. That hedge is worth keeping in mind, since the standard terminology runs to dozens of named models beyond the disciplines listed here.

Greek letters, and the two additions that matter for software

The notation section is the core of the document and it introduces three standard symbols before diverging. Count is kappa, with a nice three-way distinction: kappa equals 100 means there are 100 items in the queue, kappa greater than 100 means more than 100, and kappa much greater than 100 means many more. Arrival rate is lambda, measuring how fast new items enter. Service rate is mu, measuring how fast items are handled.

The relationships between lambda and mu are stated three ways: equal means the queue stays the same size, arrival greater than service means it grows, and arrival less than service means it shrinks. The single number that summarizes this is rho, the utilization ratio, defined as lambda divided by mu, with the same three cases restated.

Then come the additions that make this a software document rather than a notes file. Total rate is chi, how many items per time exit the queue for any reason including success, failure and skip. Success rate is alpha, items per time period that turn out right, such as correct, complete or accepted. Failure rate is beta, items that turn out wrong. Skip rate is sigma, items per time person skips the queue, such as dropouts, abandonments or losses.

The document closes this part with two warnings that are easy to miss and matter a lot. Some practitioners define service rate differently, and service rate may be different in practice due to failures such as errors or skips such as dropouts. It also notes that for typical queueing theory, total rate equals service rate, which is precisely the assumption that stops holding once a queue handles imperfect work.

Counting outcomes separately from counting throughput is the single most useful idea in the document, because a pipeline that ships fast and ships broken is not fast.

Throughput rates, error ratio, and the time families

Once throughput is split into its components, the document derives an error ratio from them, and the table of contents shows the full arc: lead time, step time, work time and wait time, then standard notation.

The split of lead time into work time and wait time is the practically useful part for a delivery team. A feature that takes long is doing one of two very different things, and the ratio between waiting and working suggests a different intervention in each case. Queueing theory supplies the vocabulary for that distinction and the observation that waiting time is often the larger term.

The service metrics section names a family of mean times that are frequently conflated: Mean Time To Respond, Mean Time To Repair, Mean Time To Recover, and Mean Time To Resolve. Keeping four separate names for four different clocks is useful precisely because teams routinely report one and mean another. Respond is the first human acknowledgement, while recover concerns getting service back after an incident.

DORA metrics appear in the same section, which connects the queueing vocabulary to the four numbers most engineering organisations already track: deployment frequency, lead time for changes, change failure rate, and time to restore. The document's contribution is not restating those but showing that they are queue measurements, which reframes them from scorecards into diagnostics.

The insights and epilog sections follow, along with a see also list and thanks, and the epilog credits the Wescott PDF that sits in the repository root.

A queue of queues, because a pipeline is not one line

The last structural idea in the table of contents is the queue of queues, and it is the part that most directly addresses a limitation of the standard textbook picture. A traditional model has one queue and one server, so a pipeline with several stages and handoffs between them does not fit.

Two arrangements are named. The double diamond queue of queues describes a flow that splits and rejoins, where work diverges into parallel paths and comes back together. The funnel queue of queues describes a narrowing flow, where successive stages filter rather than fan out, each one taking a subset of what the previous stage passed on.

Neither pattern is developed with equations in what is available here, which is a fair thing to note. The value is that they are named and drawn, so a team can point at their deployment pipeline and say which shape it is rather than forcing a M/M/1 model onto something that is neither single-server nor homogeneous.

The activity tracking section in between covers what to log, gives activity examples, and introduces Little's Law and key performance indicators. Little's Law is the relationship that ties a count to a rate and a time together, and in this document it sits inside activity tracking rather than in the notation section, which is a placement that reflects how the author uses it: as a check on whether the numbers you are tracking are internally consistent, not as a formula to compute waiting time from scratch.

The repository has no releases, so there is no version history to read and no changelog to interpret. It is a document that is either current or quietly out of date, and its state is best judged by reading it.

Editorial conclusion

What this repository offers is not new mathematics but a vocabulary bridge. The arrival and service rates, the utilization ratio and the queue discipline names are standard, and any operations research textbook covers them. The additions are the ones a software team will actually argue about: success, failure and skip rates as distinct quantities rather than one throughput number, an error ratio that keeps quality separate from speed, the MTTR family split into respond, repair, recover and resolve, and a queue of queues that describes a pipeline honestly. Where it stops short is equally clear, since there is no code, no exercises and no worked M/M/1 solution. Read it as a shared glossary first, then decide whether to reach for a textbook. The notation only does work if the whole team uses it, and agreeing the symbols in one sitting is cheaper than inventing three different meanings for the Greek letter over a quarter.

Frequently asked questions

Official sources

1. Issues
2. joelparkerhenderson/queueing-theory on GitHub
3. README