Terms library
Working definitions I lean on when thinking and writing about running software.
A
- Acceptance criteria Testable statements that define when a requirement is done and correct.
- Alignment issues Problems caused by accessing memory at addresses that violate alignment requirements, which can trigger faults on some architectures.
- Alignment requirements Rules about which memory addresses are valid for accessing a given type or instruction, affecting correctness and performance.
- AOT compilation Ahead-of-time compilation: compiling to machine code before the program starts, producing an executable artifact.
- Artifact A build output you can store and ship: a concrete file (or set of files) produced by tooling, such as a binary, package, image, or archive.
- Assumption A claim you are treating as true for the design, often about traffic shape or user behavior. Wrong assumptions become risks.
B
- Background process A process running without being the active foreground job of a terminal, often with different I/O and signal behavior.
- Binary A file whose contents are bytes rather than readable text, often produced by compilation and linking.
- Buffer overflow A memory safety bug where writes exceed a buffer’s bounds and overwrite adjacent memory, causing corruption, crashes, or exploits.
- Build The step that turns source + dependencies + configuration into artifacts you can ship, such as binaries, packages, or images.
C
- Compilation The process of translating source code into a lower-level representation (often machine code), checking and optimizing along the way.
- Constraint A fixed rule you must obey in a design, such as a platform choice, compliance rule, timeline, or existing dependency.
- Container An isolated packaging and execution unit built from an image, sharing the host kernel but using OS primitives to constrain processes and resources.
- Contract A shared agreement that defines inputs, outputs, behavior, and guarantees. In system design, contracts reduce ambiguity.
- Cost The money and resources a system consumes, including compute, storage, network, and operational time.
- CPU The general-purpose processor that runs programs, executes machine instructions, and coordinates most system work.
- Crash An abnormal process termination caused by an unrecoverable fault or forced termination, rather than a clean, intentional exit.
D
- Daemon A long-running background service process, typically started by the OS or a supervisor rather than an interactive user.
- Database A persistent datastore used to store and query structured data with defined semantics around consistency and durability.
- Deploy The act of moving an artifact into an environment and making it run (or be available), including configuration, rollout, and verification.
- Deployment wrapper The packaging layer around an app that shapes how it runs in an environment, such as an init system, container/VM, or sidecars.
- Diagnostic dump Structured output captured during failure or termination, such as stack traces, core dumps, thread dumps, or runtime state snapshots.
- DNS The system that translates names (like example.com) into network addresses (like IPs), enabling service discovery and routing.
E
- Error An incorrect or unexpected condition in a system. An exception is one mechanism for representing or propagating errors.
- Error budget The amount of unreliability allowed by an SLO. It is the gap between 100% and the SLO target over a time window.
- Exception A language-level control-flow mechanism for handling abnormal situations by unwinding the call stack to a handler.
- Executable A binary that the operating system can load and start as a running program.
- Executing data as code When the CPU attempts to run bytes that are not intended to be instructions, often due to memory corruption or control-flow hijacking.
- Execution surface The observable boundary of a system where running behavior can be measured and influenced.
- Exit code A small integer a process returns on exit to indicate success (usually 0) or failure (non-zero) to whatever started or supervises it.
F
- File descriptor An OS handle (usually a small integer) representing an open file, socket, pipe, or similar I/O resource owned by a process.
- Firewall A network control that allows or blocks traffic based on rules (IP, port, protocol), enforcing boundaries between systems.
- Forced shutdown An immediate stop where a process is terminated without cooperating, typically via SIGKILL or an equivalent hard stop.
- Functional requirement A requirement about behavior or features: the user-visible flows the system must support.
G
- GPU A processor optimized for massively-parallel numeric work, typically used for graphics and data-parallel computation.
- Graceful shutdown A coordinated stop where a process handles a shutdown request, finishes or safely aborts work, releases resources, and exits cleanly.
- Graceful shutdown timeout The maximum time allowed for a process to shut down cleanly before the system escalates to a forced termination.
I
- I/O Input/output: moving data between a program and the outside world (disk, network, devices), often slower than CPU work and a common source of waiting.
- Idempotency A property of an operation where repeating it has the same effect as doing it once, which matters for retries and duplicates.
- Interface A defined boundary for interaction: the inputs, outputs, and rules a component exposes so others can use it without knowing its internals.
- Interpreter A way of running code by executing its meaning step-by-step, rather than producing a standalone executable ahead of time.
- Isolation The mechanisms that prevent one workload from interfering with another by enforcing boundaries over memory, CPU, files, and privileges.
J
K
L
M
N
O
- Observability The ability to understand a running system from its outputs (logs, metrics, traces) so you can debug and operate it.
- Operability How easy it is to run a system in production: deploy, debug, observe, and recover from failures.
- Operating system The software layer that manages hardware resources and provides safe, stable abstractions (processes, files, networking) for programs.
- Operational budget A defined allowance for time, error, and resource use that constrains design and runtime choices.
- Out of scope Features or concerns explicitly excluded from the design or project, usually to keep v1 tractable.
P
- p99 latency The latency value that 99% of requests complete under. A common tail-latency target for production systems.
- Peak-to-average The ratio between peak traffic and average traffic. It tells you how bursty a workload is.
- Performance How a system behaves under load, usually described by latency, throughput, and resource usage rather than a single speed number.
- Pipe An OS-provided unidirectional byte stream used to connect processes or components, usually represented by file descriptors.
- Pollable event An event indicating an I/O resource is ready (readable or writable), as observed via polling APIs like poll or epoll.
- Process An OS-managed running instance of a program with an identity, virtual address space, permissions, and scheduled execution.
- Process lifecycle The stages a process moves through from creation to termination, including start, running, signals, and exit.
- Process start The moment the OS creates a process and begins executing an executable with a specific identity, environment, and I/O setup.
- Program A running instance of code on a machine: execution plus memory, state, and interaction with the OS and environment.
- Proxy An intermediary component that forwards requests between clients and servers, often adding routing, caching, security, or observability.
Q
R
- Reliability How consistently a system delivers correct results over time, including its ability to handle failures and meet targets.
- Requirement A statement about what a system must do or how it must behave. Good requirements are testable and constrain design choices.
- Runtime The support machinery used while a program runs (libraries, memory management, scheduling hooks), depending on the language and platform.
- Runtime environment The surrounding execution context a program depends on: OS, filesystem, configuration, permissions, network, containers/VMs, and more.
S
- Scalability The ability of a system to handle growth in load or data by adding resources or changing architecture without collapsing.
- Scope The set of problems and features a design or project includes. Being explicit about scope prevents accidental expansion.
- Security Protecting a system’s data and behavior from abuse, including confidentiality, integrity, and availability risks.
- Sidecar A helper process deployed alongside an application to provide capabilities like proxying, logging, metrics, or security without changing app code.
- Signal An OS-delivered notification to a process (like SIGTERM or SIGKILL) used for interrupts, termination, and other asynchronous events.
- SLA Service Level Agreement. An external promise about service levels, often with penalties or consequences if it is missed.
- SLI Service Level Indicator. A metric that measures a user-facing aspect of service health, like success rate or latency.
- SLO Service Level Objective. A measurable reliability target for a service defined over a time window.
- Source code Human-readable text that describes computation in a programming language, meant to be translated and executed.
- Stdout/stderr The standard output and standard error streams of a process, typically file descriptors 1 and 2.
- Supervisor A process that starts and monitors other processes, restarting them and managing their lifecycle and logs.
- System call A controlled request from user space into the kernel to perform a privileged operation like I/O, process management, or memory mapping.
T
U
- Use-after-free A memory safety bug where code uses memory after it has been freed, leading to crashes, corruption, or exploitable behavior.
- User journey An end-to-end path a user takes through a system, from intent to outcome. Good requirements describe journeys, not just screens.
- User space The unprivileged execution environment where applications run, separated from direct hardware access and mediated by the kernel.