## Engineering terms: delivery and operations

From Vibe Coding 101 (https://vibe-coding-101.brighteng.org/). When a request describes one of these problems, use the named technique, say its name, and run its check. Each term's page has the full entry and a prompt.

- **continuous integration**: Run repeatable checks when code changes are integrated. Use when: Changes pass locally but break the shared branch. Do: Use a clean install, required checks, and retained failure artifacts. Confirm the checks run on the actual proposed revision. Avoid: A successful check belongs to an older revision of the change.
- **request-scoped state**: Keep user-specific mutable state within the request that owns it. Use when: A warm server process reuses variables across different users. Do: Pass request context explicitly. Share only safe reusable resources, and test interleaved requests for different users. Avoid: A shared cache key omits the user or tenant even after globals are removed.
- **streaming**: Process or forward data incrementally as it arrives. Use when: A download buffers the entire response before sending any bytes. Do: Keep the path incremental, respect backpressure, and test cancellation and errors after output has begun. Avoid: A later transformation reads the whole stream into a string.
- **idempotency**: Repeating an operation has the same intended effect as doing it once. Use when: A retried request or duplicate message repeats a side effect. Do: Choose a stable operation key and durable duplicate handling. Coordinate the recorded result with the side effect; use provider support for external effects. Avoid: Recording completion separately from the side effect leaves a crash window. Worked example: https://vibe-coding-101.brighteng.org/examples/idempotency.md
- **secret management**: Supply credentials through an appropriate secret store or runtime configuration. Use when: An integration needs a credential in development and deployment. Do: Document variable names, inject values at runtime, and inspect release output for accidental exposure. Avoid: Rotating the environment value while an older leaked credential remains valid.
- **feature flag**: A switch controls whether a behavior is enabled. Use when: A new behavior needs a staged rollout or a quick way to disable it. Do: Define the flag’s scope, default, owner, and removal condition; exercise both branches. Avoid: Treating a rollout switch as an authorization check.
- **rollback**: Return to an earlier working release or state after a failed change. Use when: A deployment needs a tested recovery path. Do: Identify a known working artifact and verify its compatibility with the state left by the new release. Avoid: Claiming a destructive data rewrite can be undone by redeploying old code.
- **load balancer**: A load balancer routes requests among service instances. Use when: A service runs on multiple instances that must share traffic safely. Do: Define readiness and state ownership, then test routing when an instance fails. Avoid: Sending traffic to a process that has started but is not ready.
- **horizontal scaling**: Increase capacity by running more service instances. Use when: One instance cannot handle the measured workload. Do: Find the bottleneck and account for shared resources before adding replicas. Avoid: Adding instances while a shared database, hot key, or serialized operation remains the bottleneck.
- **CDN**: A content delivery network serves content through distributed edge locations. Use when: Public assets or pages need lower latency for geographically distributed users. Do: Classify public and private responses and test cache keys, freshness, and invalidation. Avoid: Caching authenticated content under a key that omits its authorization context.
- **read replica**: A read replica serves a copy of database data. Use when: Read-heavy work competes with writes on the primary database. Do: Classify reads by consistency requirements and observe replication lag. Avoid: Sending a read-after-write to a lagging replica and treating missing data as a failed write. Replicas do not replace backups.
- **eventual consistency**: Replicas or projections converge when updates stop and propagation succeeds. Use when: A view updates asynchronously after the authoritative write. Do: Define which views may lag, how pending work appears, and how failed propagation is detected. Avoid: Calling permanently missing updates eventual consistency.
- **saga**: A saga coordinates a multi-step operation through local commits and explicit recovery actions. Use when: A business operation spans systems that cannot share one transaction. Do: Persist progress and define retries, compensation, and manual recovery for each step. Avoid: Assuming every external effect has an exact inverse.
- **transactional outbox**: A transactional outbox records an event alongside the business change in one database transaction. Use when: A database write and event publication must not drift apart. Do: Commit the business record and outbox record together, then publish with retry and duplicate handling. Avoid: Deleting the outbox record before publication has been safely acknowledged.
- **cache stampede**: Many callers rebuild the same missing or expired cache entry at once. Use when: A popular key’s expiration causes a burst of expensive work. Do: Choose refresh coordination and a bounded wait or stale-response policy. Avoid: Using an in-process lock while every instance independently rebuilds the same value.
- **dead-letter queue**: A dead-letter destination retains work that exhausted normal processing or retry policy. Use when: Repeatedly failing jobs block progress or disappear from view. Do: Keep the error context and stable identity; define ownership, retention, and replay behavior. Avoid: Collecting failed jobs without a way to inspect or recover them.
- **liveness and readiness**: Liveness asks whether a process should be restarted; readiness asks whether it should receive work. Use when: Deployments send traffic too soon or restart healthy processes during dependency failures. Do: Define separate probes and test startup, dependency loss, and recovery. Avoid: A probe depends on the same congested path whose health it should diagnose.
- **canary deploy**: A canary release exposes a new version to a limited portion of traffic first. Use when: A release needs production evidence before a full rollout. Do: Choose representative traffic and measurable failure thresholds while keeping versions compatible. Avoid: Comparing unequal workloads and calling the difference a release regression.
- **failover**: Failover transfers responsibility from an unavailable component to another. Use when: A primary service or datastore has a standby that must take over. Do: Use the platform’s supported mechanism and rehearse its failure and recovery boundaries. Avoid: Promoting a new writer while an old writer still accepts conflicting work.
- **pub/sub**: Publish/subscribe distributes events to interested subscribers. Use when: Several independent consumers need to react to the same event. Do: Define which consumers require durable delivery and how they handle repeated events. Avoid: Assuming pub/sub or a work queue guarantees exactly-once side effects.
- **timeout budget**: An operation’s total deadline must account for downstream calls, retries, and cleanup. Use when: A user-facing request takes far longer than its intended maximum. Do: Propagate a remaining deadline and define safe cancellation and retry behavior. Avoid: Retrying a timed-out write without knowing whether its side effect already happened.
- **graceful degradation**: Keep essential behavior useful when an optional dependency or capability is unavailable. Use when: An optional widget failure takes down an otherwise useful page. Do: Separate essential dependencies from optional ones and test the declared fallback. Avoid: Replacing a failed dependency with a more expensive fallback that overloads the system.
- **backend for frontend**: A backend for frontend adapts backend capabilities to a client’s needs. Use when: A client assembles one screen from many internal service calls. Do: Define a screen-oriented response and keep shared rules in their authoritative location. Avoid: Copying pricing or access rules into a client-specific layer.
- **infrastructure as code**: Infrastructure as code describes infrastructure in reviewable files. Use when: Environments depend on undocumented manual configuration. Do: Inspect the plan, protect state, and verify how existing resources are adopted. Avoid: Applying a replacement plan without accounting for the resource’s stored data.
- **container**: A container runs a process with a packaged filesystem and configured isolation. Use when: A service starts differently across development and deployment environments. Do: Build a reproducible image and test startup, shutdown, configuration, and persistent storage explicitly. Avoid: Assuming a container alone supplies durable storage or a complete security boundary.
- **multi-tenancy**: A multi-tenant application serves distinct customers through shared infrastructure. Use when: Several customer organizations share the same application. Do: Derive tenant context from trusted membership and trace it through every shared resource. Avoid: Accepting a tenant ID without checking the caller’s membership.
- **object storage**: Object storage stores data as objects addressed by keys. Use when: Uploaded files must outlive an application instance. Do: Choose ownership and access policy, index object references, and handle incomplete uploads and deletion. Avoid: Assuming an unguessable object key provides authorization.
- **blue-green deploy**: Blue-green deployment keeps old and new environments available during a traffic switch. Use when: A release needs a quick traffic switch with an available previous version. Do: Verify the new environment before switching and test the route back with shared state. Avoid: Calling a traffic switch a rollback when the previous application can no longer read the database.
- **configuration drift**: Configuration drift is a difference between intended and running configuration. Use when: An environment behaves differently despite using the expected application build. Do: Compare authoritative configuration with observed state and explain each meaningful difference. Avoid: Automatically overwriting an emergency change without understanding why it exists.
- **TLS**: TLS protects communication and authenticates peers according to the configured trust model. Use when: An application connects to a service over an untrusted network. Do: Use supported TLS clients and inspect the entire path, including proxies and trust configuration. Avoid: Assuming an encrypted connection is authentic when certificate validation is bypassed.
- **HTTP caching**: HTTP caching controls when clients and intermediaries can reuse a response. Use when: A response is unexpectedly stale or reused for the wrong user. Do: Classify responses, define validation and variants, and test the actual browser or shared cache. Avoid: Reading no-cache as a prohibition on storage; it requires validation before reuse.
- **reverse proxy**: A reverse proxy accepts client traffic and forwards it to application services. Use when: An application sits behind a gateway that handles TLS, routing, or limits. Do: Define trusted proxies and align path, timeout, body-size, and scheme handling. Avoid: Trusting client-supplied forwarding headers from connections that bypass the proxy.
- **port mapping**: Port mapping publishes a service port through another network boundary. Use when: A container runs but the browser cannot reach its service. Do: Trace the listener, published port, bind address, and each caller’s network context. Avoid: Publishing the wrong internal port or unintentionally binding a private service publicly.
- **bind mount vs volume**: A bind mount exposes a host path to a container; a managed volume has a separate storage lifecycle. Use when: Container replacement loses a database or development edits are not visible. Do: Choose the appropriate mount for source and data, then test replacement and cleanup. Avoid: Calling a mounted directory durable without checking its actual host lifecycle.
- **preview deployment**: A preview deployment exposes a particular proposed revision for review. Use when: Reviewers need to exercise a change outside the developer’s machine. Do: Identify the built revision and verify the environment before testing the feature. Avoid: Testing the wrong revision because the preview address points at an older artifact.
- **build ID**: A build ID identifies the artifact running in an environment. Use when: A fix is deployed but users may still be running an older release. Do: Embed a stable build identity and expose it through an appropriate diagnostic surface. Avoid: Using request time as a build ID so every response appears to be a new version.
- **database clustering**: Coordinate database nodes with explicit storage, replication, and routing roles. Use when: A single database node cannot meet your availability or capacity target. Do: Draw the node roles and failure domains. Define write routing, replication, and failover. Check a node-loss drill and verify acknowledged writes. Avoid: A cluster is not automatically highly available, strongly consistent, or faster for every workload.
- **rebalancing**: Move existing partitions or replicas to improve their placement. Use when: A newly added shard is idle while older shards carry most data. Do: Inspect bytes, traffic, and replica constraints per node. Move data gradually, then verify placement and request latency. Distinguish balancing bytes from balancing hot keys. Avoid: Moving an indivisible hot key to another node can merely move the bottleneck.
- **resharding**: Change the shard layout or assignment used to distribute data. Use when: The existing shard key or partition layout cannot spread the workload. Do: Plan copy, change capture, routing transition, and rollback. Check row reconciliation, writes during migration, and queries using the old key. Avoid: Online resharding still needs resources and can block writes briefly; product behavior and limits vary.
- **split-brain**: Competing nodes act as the same write authority after losing coordination. Use when: An old primary resumes writes after a standby has been promoted. Do: Use the platform’s election and fencing mechanisms. In a disposable drill, isolate the primary and verify the old authority cannot write after promotion. Avoid: A timeout shows that a node is unreachable, not that it is dead. Deliberate multi-leader replication has a different conflict contract.
- **high availability (HA)**: Keep the service usable through specified failures and recovery procedures. Use when: A single machine or zone failure must not exceed the service’s outage budget. Do: Define the availability objective and failure domains. Drill node and zone loss. Measure successful user operations and recovery duration, then restore redundancy. Avoid: An HA setup is not a backup strategy or a promise of zero downtime and zero data loss.
- **vertical scaling**: Give one instance more CPU, memory, or I/O capacity. Use when: One database instance is constrained by a measured resource bottleneck. Do: Identify the constrained resource, compare a larger instance under the same workload, and check resizing downtime, cost, and remaining headroom. Avoid: More CPU does not repair a serialized critical section, missing index, or remote dependency bottleneck.
- **geo-replication**: Replicate data across geographic regions with an explicit consistency policy. Use when: A regional outage or distant users require copies beyond one region. Do: Choose regions and consistency mode. Measure cross-region writes and lag, then drill regional loss and reconnection. Verify data residency requirements separately. Avoid: A remote copy is not proof of zero data loss, local write latency, or residency compliance.