Core jargon for software architecture, delivery, and engineering culture.
Hiding how something works internally and exposing only the interface a caller needs to use it.
A defined set of endpoints and rules that lets one piece of software request data or functionality from another, without needing to know how it's implemented internally.
The packaged output of a build — a compiled binary, container image, or bundle — that gets promoted through environments and ultimately deployed.
The process of verifying that someone is who they claim to be.
Deciding what an already-authenticated user is allowed to do or see.
The system keeps responding to requests even when part of it has failed — one of the three properties in the CAP theorem.
Existing clients keep working without modification after something behind the scenes has changed.
A way of describing how an algorithm's run time or memory use grows as its input size grows, ignoring constant factors.
How much of the system — and how many users — would be affected if a given change or component fails.
Running two identical production environments and instantly switching all traffic from the old one to the new one, enabling near-zero-downtime releases and instant rollback.
Standard, repetitive code that must be written in nearly the same form every time, carrying little logic of its own.
The single slowest component in a system that caps overall speed, no matter how fast every other part runs.
A named pointer to a line of commits in a repository, letting work proceed in parallel without touching the main codebase.
A change to an API or system's behavior that forces existing consumers to update their own code, or their integration stops working.
A tool that takes source modules (JavaScript, CSS, assets) with their dependency graphs and outputs one or more optimized files for the browser.
Storing the result of expensive work so a later request can reuse it instead of recomputing or refetching from scratch.
Rolling a change out to a small slice of real users first, to catch problems before they affect everyone.
A network of geographically distributed servers that cache and serve static assets from wherever is closest to the user.
Continuous Integration / Continuous Delivery (or Deployment) — automatically building, testing, and optionally shipping code every time it changes.
A pattern that detects when a downstream service is failing and stops sending it requests temporarily, instead of letting every caller time out and pile up.
A function that captures and 'remembers' variables from the scope it was defined in, even after that scope has finished executing.
A structured process where one or more teammates read proposed changes before they merge, checking for bugs, design problems, and maintainability issues.
A surface-level pattern in code — not a bug by itself — that often signals a deeper design problem worth investigating.
Breaking a bundle into multiple smaller chunks that load on demand rather than shipping everything upfront, so the initial page load only pays for what it immediately needs.
How tightly a module's responsibilities relate to one single purpose, rather than being a grab-bag of unrelated tasks.
A code path that runs rarely, so its performance has little effect on the system overall.
A saved snapshot of changes to a repository, along with a message describing what changed and why.
Building behavior by assembling small, independent objects instead of extending a shared base class, avoiding deep and fragile class hierarchies.
Making progress on multiple tasks over the same time period by switching between them — not necessarily running them at the exact same instant.
When two branches have made incompatible changes to the same part of the same file, requiring a human to decide what the final version should be.
Every read returns the most recent write, so all clients see the same data at the same time — one of the three properties in the CAP theorem.
A lightweight, isolated package that bundles an application with everything it needs to run, so it behaves the same on any machine.
A system that automatically deploys, scales, restarts, and networks containers across a cluster of machines, so you don't manage each one by hand.
The agreed-upon set of inputs, outputs, and behavior that two systems promise to honor when communicating.
A scenario where multiple edge cases occur at once, making it far rarer and harder to anticipate than any single edge case alone.
The degree to which one component depends on another's internals — the tighter the coupling, the more a change on one side risks breaking the other.
An attack that tricks a logged-in user's browser into making an unwanted request to your app — exploiting the fact that browsers automatically attach cookies to requests.
A numeric score counting every possible route through a function — each branch or loop adds one. The higher the score, the more paths there are to test and reason about.
Code that exists in the codebase but can never be reached or executed under any condition.
Delaying execution of a function until a specified quiet period has passed since the last time it was called — collapsing a burst of rapid calls into one.
An external package, library, or service that your code requires to function.
Supplying an object's dependencies from the outside instead of having it construct them itself, so those dependencies are easy to swap or mock.
Taking raw transferred data — JSON, bytes — and turning it back into a usable object your code can work with.
Same input, same output — every single time, with no variation between runs.
"Don't Repeat Yourself" — any piece of knowledge or logic should exist in exactly one place in a system.
The same logic expressed in multiple places in the codebase, so a single change has to be made — and remembered — in every copy.
Loading related data upfront, before it's needed, trading extra initial work for fewer round-trips later.
A rare but technically valid input or condition that sits at the boundary of what the system was designed to handle.
Bundling data with the methods that operate on it, and blocking other code from reaching in and changing that data directly.
A test that drives the full application as a user would — through the UI, through the backend, against a real or near-real environment.
A named value injected into a running process from outside the code — used to pass configuration, secrets, and environment-specific settings without hardcoding them.
Services communicate by publishing and subscribing to events rather than calling each other directly — a producer emits 'something happened' and consumers react without the producer knowing who they are.
Updates spread to all copies of the data over time, so reads may briefly return stale data before every copy catches up.
New functionality can be added without rewriting or breaking the code that already works.
Automatically switching operation to a standby system the moment the primary one fails, with minimal disruption.
A runtime switch that turns a piece of functionality on or off for some or all users without requiring a new deployment.
A known, reusable block of test data or environment state set up before a test runs, so every test starts from the same baseline.
A test whose pass/fail result varies between runs with no underlying code change, usually due to timing, ordering, or external dependencies.
A system can be adjusted to meet new or changed requirements without a large rewrite.
A query language for APIs where the client specifies exactly what data it needs, and the server returns exactly that — nothing more, nothing less.
A built-in constraint that prevents a system or user from taking an action known to be incorrect or unsafe.
The scenario where a user provides valid input and everything proceeds exactly as designed, with no errors or edge cases involved.
A code path that executes very frequently relative to the rest of the system, making its performance disproportionately important to optimize.
HTTP over TLS — the transport layer is encrypted so credentials and data can't be read or tampered with in transit.
The process of attaching JavaScript event listeners and client-side state to HTML that was rendered on the server, making a static page interactive.
An operation that produces the same end result no matter how many times it's performed, so retrying it is always safe.
A value or data structure that cannot be changed after it's created — any 'modification' produces a new value rather than altering the original.
Releasing a change to a small slice of users first and progressively widening it, rather than shipping to everyone at once.
A data structure the database maintains alongside a table to speed up queries on specific columns, at the cost of slower writes and more storage.
A test that exercises multiple components together — typically hitting a real database, message queue, or API boundary — to verify the pieces work when assembled.
A defined set of operations something promises to support, without specifying how those operations are implemented internally.
A design principle where the framework calls your code, rather than your code calling the framework — the framework drives the overall flow, not you.
A signed, self-contained token that encodes claims (user ID, roles, expiry) as base64 JSON — the server can verify it without hitting the database.
"Keep It Simple, Stupid" — favor the simplest solution that works over a more complex or clever one.
The delay between starting an operation and getting its result back, typically measured in milliseconds for a single request.
Deferring the loading of a resource until the exact moment it's actually needed.
When a cluster of machines needs one to be in charge, they run a protocol to automatically agree on which one — and pick a new one if it goes down.
An abstraction meant to hide complexity that occasionally forces the caller to understand what's happening underneath anyway.
A static analysis tool that scans source code for style violations, suspicious patterns, and common bugs — without running it.
A component that distributes incoming requests across multiple server instances so no single one gets overwhelmed.
A literal value embedded directly in code with no explanation of what it represents, instead of being assigned to a named constant.
How easily developers can read, understand, and safely change a codebase over time — driven by clarity, structure, and test coverage.
Caching a function's return value keyed by its input, so calling it again with the same input skips recomputation entirely.
Combining the changes from one branch into another, producing a unified history that includes both lines of work.
A durable buffer that holds messages between a producer and a consumer, decoupling them so the producer doesn't block waiting for the consumer to be ready.
An architecture where an application is split into small, independently deployable services, each owning a narrow slice of functionality and communicating over a network.
A function that runs in between an incoming request and the final handler, used to add cross-cutting behavior like logging, auth checks, or parsing.
A versioned, usually irreversible script that changes a database's schema or data — adding a column, renaming a table, backfilling values.
A test double that stands in for a real dependency and lets you verify how it was called — e.g. that a specific method ran with the expected arguments.
A single deployable unit where all features and components of the application live together and run as one process.
Storing multiple related projects or packages in a single version-controlled repository, with shared tooling and the ability to make cross-project changes atomically.
A synchronization primitive that ensures only one thread can access a shared resource at a time — others wait until the lock is released.
Minimum Viable Product — the smallest version of a product that's still useful enough to release and learn from real users.
A data-fetching pattern where you make one query to get a list of N items, then run one additional query per item to fetch related data — totaling N+1 round-trips instead of one.
Structuring a relational database to eliminate redundancy by storing each fact in exactly one place and referencing it by key everywhere else.
A single long-term metric or goal that smaller, day-to-day decisions are meant to align with.
How well you can infer a system's internal state and diagnose problems from its existing logs, metrics, and traces — without having to add new instrumentation on the spot.
A library that maps database tables to code objects, letting you query and manipulate data using the language's own constructs instead of writing raw SQL.
Breaking a large result set into pages of a fixed size, so callers fetch one chunk at a time instead of the entire collection.
Actually running multiple tasks at the exact same instant, across multiple CPU cores or machines simultaneously.
The system keeps operating even when a network failure splits it into isolated groups that can no longer communicate.
A piece of code that implements a browser API or language feature in environments where it doesn't natively exist yet.
A rough, throwaway build made to demonstrate that an idea is technically feasible — not to be shipped to production.
A request to merge a branch into another, used as the gate for code review before changes land in the main branch.
A function that always returns the same output for the same input and has no side effects.
A bug where the program's outcome depends on the unpredictable ordering of concurrent operations, producing different results depending on timing.
Capping how many requests a client can make to an API in a given time window, to protect the server from overload and abuse.
Replaying your commits on top of a different base commit, rewriting the branch history so it looks like you started from the latest point.
Restructuring existing code to improve its internal design and readability while deliberately keeping its external behavior unchanged.
Previously correct behavior that breaks as an unintended side effect of a later, unrelated change.
The system keeps producing correct results consistently over time, without unexpected failures.
Keeping multiple copies of the same data on different machines, for redundancy and to spread read traffic.
When something fails, the system detects it and recovers automatically — continuing to operate, possibly in a degraded state — instead of going down entirely.
An architectural style for HTTP APIs where resources are addressed by URLs and manipulated with standard HTTP methods (GET, POST, PUT, DELETE).
Request for Comments — a written design proposal circulated for team feedback before a risky or significant piece of work begins.
The system keeps working correctly even when it receives invalid input or hits unexpected conditions.
Reverting a system to the previous deployed version after a new release causes problems.
The system can handle growth in users, data, or traffic by adding resources — not by needing a redesign.
The declared structure of a data store or message — what fields exist, what types they are, and what constraints apply.
A versioning convention where version numbers follow `major.minor.patch` — patch for bug fixes, minor for backward-compatible additions, major for breaking changes.
Structuring a system so each part owns one distinct responsibility, with minimal overlap between parts.
Converting an object into a flat, transferable format — like JSON or bytes — so it can be sent over a network or saved to disk.
The mechanism by which services in a distributed system find each other's current network addresses, which change as instances start and stop.
Splitting a dataset across multiple machines — often by a key like user ID — so each machine holds only a slice of the total data.
Any observable change a function causes beyond returning its output value — writing to a database, modifying global state, logging, making a network request.
Designating one system or table as the definitive record for a piece of data, so every other copy defers to it instead of drifting out of sync.
A web app that loads once and handles subsequent navigation by swapping content via JavaScript — the URL changes, but the page never fully reloads.
A short, time-boxed technical investigation done to answer a specific question or reduce uncertainty — not to produce shippable code.
An attack where unsanitized user input gets interpreted as SQL, letting an attacker read, modify, or delete data they shouldn't touch.
Pre-building all pages as static HTML at build time rather than rendering on each request, so the server just serves files with no per-request compute.
Generating the full HTML for a page on the server at request time and sending it to the browser, rather than sending a bare HTML shell and letting JavaScript build the page.
The server remembers information from earlier interactions and uses it to affect how it handles later requests.
The server keeps no memory of past requests — each request carries all the information needed to handle it on its own.
A test double that returns fixed, predetermined responses regardless of input, used to isolate the code under test from a real dependency.
The future rework cost you take on by choosing a quick solution now instead of a more thorough one.
The raw logs, metrics, and traces a running system continuously emits about its own behavior.
The percentage of code lines (or branches) executed at least once by the test suite.
A practice where you write the failing test first, then write the minimum code to make it pass, then refactor — the tests drive the design.
Limiting a function to fire at most once per defined time interval, regardless of how many times it's invoked.
The volume of work a system can complete in a given time period, such as requests handled per second.
Is a situational choice where you give up some amount of one quality, value, or thing to gain more of another
A bundler optimization that eliminates dead code — specifically, exported module members that nothing in the app actually imports.
A language feature or tool that assigns types to values and catches type mismatches before runtime — either at compile time (TypeScript, Java) or by inference.
A test that exercises a single function or class in isolation, with all dependencies replaced by fakes.
A callback pattern where one service notifies another by sending an HTTP POST to a URL the receiver registered in advance — triggered by an event, not a poll.
A persistent two-way connection between client and server over a single TCP connection — either side can push data to the other at any time without a request.
An attack where malicious scripts get injected into a page and run in other users' browsers — usually by storing attacker-controlled input that the app then renders as HTML.
"You Aren't Gonna Need It" — don't build functionality before it's actually needed, on the guess that it might be useful someday.