Discrete Event Simulation: Build a Queue You Can Check by Hand

An event changes what the model knows

Imagine one reviewer and a first-in, first-out queue. A job arriving changes the queue. A review finishing frees the reviewer. The clock jumps to the next relevant event instead of recalculating every millisecond.

The entities are the jobs. The resource is the reviewer. The state includes who is waiting, who is being reviewed and the current time. The rules decide whether a ready job can take the reviewer and what happens when the review finishes.

This model begins empty at time zero. It has no breaks, rework, priority overrides or missing inputs. Those omissions are deliberate teaching boundaries, not claims about how an actual team works.

Three jobs, checked without a simulation package

Fictional inputs use minutes on one clock. A arrives at minute zero and needs four minutes. B arrives at minute one and needs two. C arrives at minute five and needs three. Jobs cannot interrupt a review already in progress.

Build the smallest model that answers the question

The Excel worksheet calculates arrival, start, finish and waiting times for this three-job, single-server example. Edit the arrival and service inputs to check the queue. It does not model random arrivals or several resources.

When a model needs several resources, parallel routes or more complex event interactions, a specialist library can handle that code. SimPy is a free Python library for process-based discrete-event simulation with shared resources. Its documentation explains how processes wait for events. The modeler must still check the process assumptions.

The five steps below are a practical sequence for this exercise, not a required industry-wide step count. Keep verification and validation separate even when a small project combines other activities.

1. State the decision

   For example, test whether an extra review window could reduce waiting without moving the delay elsewhere.

2. Collect and declare the inputs

   Keep arrivals, service times, resource calendars, priorities and starting work visible.

3. Build the event rules

   Implement arrival, queue entry, resource use and completion. Define what happens when events share a time.

4. Verify a tiny run

   Check each event against hand calculations and confirm that every arrived job has one consistent state.

5. Validate before comparing changes

   Compare recorded waits, completions and unfinished work over a matching real period. Then test a changed scenario with its uncertainty.

Random sampling does not define a separate rival method

The three-job example is deterministic: the same inputs produce the same output. If arrivals or review times vary, a DES model can sample them randomly. That use of Monte Carlo sampling sits inside the event model; DES and Monte Carlo are not mutually exclusive choices.

A continuous model represents quantities that evolve continuously, such as temperature under a specified physical equation. Some problems combine continuous behavior and discrete changes. Choose the model for the question rather than ranking one type as universally best.

The local example also includes a seeded teaching experiment that multiplies each service time by a sampled factor between 0.8 and 1.2. It repeats that finite three-job scenario 100 times. Those factors are invented, not fitted to a real reviewer. The results demonstrate repeatability and variation, not a staffing recommendation.

Warm-up and repeated runs answer different problems

An empty-start, finite three-job exercise needs no artificial warm-up deletion: all three jobs belong to the stated question. A model of an ongoing service may need realistic initial work or a justified warm-up to avoid the bias from starting empty.

Use independent random streams across repeated scenarios and report uncertainty, not only a favorite run. If comparing changes, keep the input assumptions and comparison design consistent. One deterministic run cannot describe a distribution of possible outcomes.

Match the output boundary too. A stop at a fixed time can leave unfinished work; reporting only completed jobs can hide their long waits. Record the queue left at the end and explain whether arrivals stop before the system is allowed to drain.

Know when a model is ready for a decision

Verification asks whether the code follows the intended rules. Validation asks whether those rules and inputs represent the real process well enough for the intended decision. The hand calculation here verifies a small algorithm; it does not validate a company workflow.

Use the simulation validation guide for credibility checks. The method comparison helps choose the approach; the VSM guide connects a proposed model to an observed current state.

Vrolen uses simulation as a capability of the value-stream map. An article example is not a claim that this standalone local script is a product feature or a forecast from the private pilot.

Free tools for operational process simulation

SimPy is a Python discrete-event library under the MIT license. JaamSim is a graphical discrete-event simulator whose current source is under Apache 2.0. Both can be used without buying a commercial simulator license. They still require modeling effort, input checks and validation; free software does not mean a model is ready to support a live decision.

The small JavaScript example supplied with this article is another free learning route. It is deliberately limited and already includes a checked output. Choose a tool from the actual flow question and your team’s skills. General drawing tools and process-mining products do not automatically simulate queues, resource contention or time.

Why simulation lists have different counts

A three-item list often names discrete-event, continuous and Monte Carlo simulation. A four-item list may add agent-based simulation. These are useful distinctions, not four mutually exclusive boxes. NIST describes time-based discrete-event and continuous paradigms, their combination in a hybrid model, and Monte Carlo sampling that can also occur inside either one.

Use discrete events for arrivals, queues and resource release; continuous models for quantities changing through time; Monte Carlo for uncertainty across repeated draws; and agent-based rules when individual interactions drive the result. A hybrid can combine them. Select the method needed to answer the question, then validate its assumptions rather than choosing a label by count.