Glossary (terms mentioned in our conversation)

ADR (Architecture Decision Record)

A short document that records a single technical/architectural decision: the context, what was decided, why, alternatives, risks, and how/when it will be revisited. Used to prevent re-litigating decisions and to preserve reasoning over time.

DRI (Directly Responsible Individual)

One explicitly named person accountable for an outcome (a decision, project, rollout, incident follow-up, etc.). The goal is to eliminate ambiguity and ensure decisions have clear ownership.

CSAT (Customer Satisfaction)

A customer satisfaction metric, typically collected via a survey (often 1–5 stars or 1–10). Reported as an average score or as the percent of respondents who rate satisfaction above a threshold (e.g., “% satisfied”).

NPS (Net Promoter Score)

A customer sentiment metric based on: “How likely are you to recommend this product?” (0–10 scale). Respondents are categorized as Promoters (9–10), Passives (7–8), and Detractors (0–6). Computed as:

$$ NPS = %Promoters - %Detractors $$

SLI (Service Level Indicator)

A measurable metric that reflects service performance/reliability (e.g., availability, p95 latency, error rate). SLIs are what you measure.

SLO (Service Level Objective)

A target for an SLI over a time window (e.g., “99.9% successful requests over 30 days,” “p95 latency < 200ms”). SLOs define what “good enough reliability” means internally.

SLA (Service Level Agreement)

A customer-facing contractual commitment, often tied to penalties/credits if not met. SLAs are frequently derived from SLOs but are typically less strict and legally framed.

MTTR (Mean Time To Recovery/Restore)

The average time to restore service after an incident causes degradation or outage. Often calculated as total time in degraded state divided by number of incidents over a period.

“Review apps” (Merge Request / Pull Request review environments)

Ephemeral environments created per MR/PR so reviewers can see and test changes without pulling code locally. Typically deployed via Kubernetes/CI and destroyed after merge.

WebSocket

A persistent, bidirectional network connection between client and server, commonly used for real-time updates (e.g., GraphQL subscriptions).

GraphQL

An API query language and runtime where clients request exactly the data they need, typically via a typed schema. Often used to reduce over/under-fetching and improve frontend-backend contract clarity.

GraphQL Subscription

A GraphQL operation type for pushing real-time updates from server to client, commonly implemented over WebSockets. Often used for live dashboards and event-driven UIs.

Apollo (Apollo Client)

A popular GraphQL client for frontend applications (especially TypeScript/React) that supports caching, typed operations, and subscriptions.

Redux

A predictable state container commonly used in React applications to manage global/shared state. Useful for cross-cutting state, but can add complexity if overused for local/derived state.

TypeScript type generation (Generated TS types)

Automatically generated TypeScript types from an API schema (often GraphQL) to ensure compile-time correctness and safer refactors.

Virtualization (List/Table virtualization)

A UI technique that renders only the visible portion of large lists/tables to keep scrolling smooth and reduce DOM/render cost (e.g., react-window, react-virtualized).

Infinite scroll

A UI pattern that loads additional content as the user scrolls (often combined with pagination and/or virtualization).

Observability

The ability to understand a system’s internal state from its outputs—usually via logs, metrics, and traces—to support debugging, reliability, and performance tuning.

“Drive-by critique” (informal term)

A criticism raised publicly (often without prior context, reproduction steps, or direct communication), which can derail discussions and create status/attribution issues.

Decision DRI vs Implementation Owner (distinction we discussed)

• Decision DRI: accountable for the choice and its outcomes/tradeoffs.
• Implementation owner: responsible for building it. Sometimes the same person, but separating them prevents authority-without-accountability dynamics.

If you want, I can format this glossary as a one-page internal doc you can paste into Confluence/Notion/GitHub (and tailor it to your team’s exact terminology).