SaaS engineering jargon

Engineering teams at software companies share a lot of vocabulary that newcomers have to pick up quickly. Here are brief explanations of the terms that come up most often.

API

Application programming interface: a defined way for one piece of software to request data or actions from another.

A/B test

An experiment that shows two variants to different users to see which performs better on a chosen metric.

Backfill

Populating historical data into a new table, field or system after the fact.

Blue-green deploy

A release approach that runs two identical environments and switches traffic from the old one to the new one.

Canary release

Rolling a change out to a small share of users first to catch problems before a full release.

CI/CD

Continuous integration and continuous delivery: automating builds, tests and releases on every change.

CDN

Content delivery network: servers distributed geographically to serve content closer to users.

Circuit breaker

A pattern that stops calls to a failing dependency for a while so failures do not cascade.

Cold start

The extra delay when a service or function must start up before handling its first request.

Data migration

Moving or transforming stored data, often alongside a schema change.

Dead letter queue

A queue that holds messages that could not be processed, so they can be inspected later.

Feature flag

A runtime switch that turns a feature on or off without deploying new code.

Idempotency

The property that repeating an operation has the same effect as doing it once.

Incident

An unplanned event that degrades or interrupts the service.

Infrastructure as code

Defining servers and networks in versioned files rather than configuring them by hand.

JWT

JSON Web Token: a signed token that carries claims, commonly used to authenticate API requests.

Latency

The time between sending a request and receiving a response.

Load balancer

A component that spreads incoming traffic across multiple servers.

MTTR

Mean time to recovery: the average time to restore service after a failure.

Monolith

An application built and deployed as a single unit.

Multi-tenancy

Serving many customers from one shared deployment while keeping their data separate.

OAuth

An open standard that lets a user grant an application limited access to their account on another service.

Observability

How well you can understand a system's internal state from its logs, metrics and traces.

On-call

A rotation in which an engineer is available to respond to production alerts.

Postmortem

A written review of an incident covering what happened, why, and what to change.

Rate limiting

Capping how many requests a client can make within a period of time.

RBAC

Role-based access control: granting permissions according to a user's role.

Read replica

A copy of a database that serves read queries to reduce load on the primary.

Refactor

Restructuring code without changing its external behavior.

Rollback

Reverting to a previous version after a bad release.

RPO

Recovery point objective: the maximum amount of data loss, measured in time, that is acceptable after a disaster.

RTO

Recovery time objective: the target time to restore service after a disaster.

Runbook

A documented set of steps for handling a known operational task or alert.

SLA

Service level agreement: a contractual commitment about service performance, often with remedies if missed.

SLI

Service level indicator: a measured value, such as the success rate of requests, that reflects service quality.

SLO

Service level objective: an internal target for an SLI over a period.

SSO

Single sign-on: letting users sign in once through an identity provider to reach multiple applications.

Technical debt

The future cost of shortcuts taken in code or design to move faster now.

Webhook

An HTTP callback in which one system notifies another when an event occurs.

Zero downtime

Deploying or changing a system without interrupting service for users.