For product managers
The technical vocabulary of product work, explained properly.
Every term you will hear in standups, incident channels, and architecture reviews. What it is, why it exists, how it actually works, and what it means for you.
See every one of these working inside a real store, built phase by phase in front of you.
Tier 1 · 0 of 20 known
You'll hear these this week
For the PM in their first month. Standup and bug-triage vocabulary.
The two halves
Client and serverTwo roles that exist the moment anything is online: the machine that asks (client) and the machine that answers (server).Phase 1FrontendEverything the user sees and touches: the pages, buttons, text, and layout running inside their browser or app.Phase 1BackendThe part of your product that runs on the server, out of sight: the logic, the rules, and the handling of data.Phase 2ServerA computer that is always on and always connected, whose job is to answer requests from other computers.Phase 1Browser vs mobile appThe same product can live on the web (opened in a browser) or as an app installed from an app store. What changes between them matters.Phase 1
Talking over the network
APIThe defined way the frontend asks the backend for things and gets answers back. A contract for how the two talk.Phase 2EndpointA specific address on the server that handles one specific kind of request.Phase 2HTTP methodsThe verbs of an API: asking for something, creating something, changing it, or deleting it are different actions on the same address.Phase 2Status codesThe server's one-line verdict on every request. 200 means success, 404 not found, 401 unauthorized, 500 server error.Phase 2JSONThe format almost every API speaks: labelled values wrapped in braces, readable by both machines and people.Phase 2LatencyHow long a request takes from asking to getting an answer. Users feel it once it crosses a threshold.Phase 2
Where data lives
DatabaseOrganized, permanent storage for your product's information, built to be searched and updated safely.Phase 2Tables and schemaThe designed structure of a database: which tables exist, what columns they have, and how they relate. Changing it is real work.Phase 2Queries and CRUDEverything any app does to data is one of four things: create, read, update, delete. A query is a request to the database to do one of them.Phase 2
Shipping and breaking
Deployment and releasesThe controlled act of moving finished code into production so users get it.Phase 6Environments: local, staging, productionSeparate copies of the product for different purposes: a developer's laptop, a staging rehearsal, and production where real users are.Phase 6LogsThe running diary the software writes as it works, recording what happened. Debugging is largely reading it.Phase 6Bug severity and triageA shared scale (P0 to P3) for how badly a bug hurts, used to decide what gets fixed first.Phase 6QA and testingChecking that software works before users get it, through a mix of automated tests and manual checking.Phase 6Browser DevToolsThe browser's built-in developer window, opened with F12 or right-click then Inspect, that shows the network requests, console messages, and page internals of any website.Phase 1
Tier 2 · 0 of 46 known
How software gets built and shipped
The machinery of everyday product work: releases, accounts, vendors, measurement.
The web's plumbing
HostingRenting the always-on machine your product runs on, instead of buying and running one yourself.Phase 1IP addressThe numeric address every machine on the internet can be reached at, like a phone number for computers.Phase 1Domain and URLThe human-readable name you buy and own (tiffinbox.com), and the full address of a specific page on it.Phase 1DNSThe system that converts a domain name (tiffinbox.com) into the IP address of the server that hosts it. Browsers can only connect to numbers; DNS is the lookup that happens before any page loads.Phase 1HTTP and HTTPSThe agreed language browsers and servers use to ask for and send things. HTTPS is the same language, encrypted so others cannot read it.Phase 1SSL / TLS and the padlockThe encryption that protects data as it travels between the user and your server, shown as the padlock in the address bar.Phase 1
Store and search
SQL vs NoSQLTwo families of databases. SQL stores neat, related tables; NoSQL stores more flexible, loosely-shaped data. Each fits different jobs.Phase 2Search indexA pre-organized copy of your data built so it can be searched very fast, instead of scanning every item each time.Phase 2DebounceWaiting for a short pause in typing before acting, instead of reacting to every single keystroke.Phase 2PaginationReturning results in pages rather than all at once, so a search for a common term doesn't try to send ten thousand items.Phase 2
Identity and security
AuthenticationProving who you are. The system's way of confirming you are the account holder before letting you in.Phase 3AuthorizationDeciding what you are allowed to do, once the system knows who you are. Different from proving who you are.Phase 3Password hashingStoring a scrambled, one-way version of a password instead of the real thing, so even the company never knows it.Phase 3SessionHow the server remembers you are logged in across many requests, so you don't re-enter your password on every click.Phase 3CookiesSmall pieces of data the browser stores and sends back to the server with each request, often carrying the "it's still me" proof.Phase 3Access and refresh tokensThe modern proof of identity: a short-lived access token you send with each request, plus a longer-lived refresh token that quietly renews it.Phase 3OAuth / "Login with Google"Letting users sign in through a provider they already trust, so you never handle their password.Phase 3Roles and permissionsGrouping what users can do into roles (customer, staff, admin) so access is managed cleanly instead of person by person.Phase 3OTP and two-factor authenticationRequiring a second proof beyond the password, usually a short code sent to your phone, so a stolen password alone isn't enough.Phase 3Encryption at rest and in transitScrambling data so it is unreadable to anyone without the key, both while it travels and while it sits stored.Phase 3PII (personal data)Personally identifiable information: names, phones, addresses, emails. Collecting it brings legal and ethical duties.Phase 3
Working with vendors
Third-party APIs and integrationsUsing another company's service through its API instead of building that capability yourself.Phase 4Payment gatewayThe specialist third party that actually moves money: takes card or wallet details, charges them, and confirms the result.Phase 4API documentationThe manual for an API: which endpoints exist, what to send, what comes back. PMs read these too.Phase 4SDKA vendor's ready-made code package that saves you from calling their API by hand.Phase 4WebhookA reverse API call: instead of you asking a service repeatedly, it calls you when something happens.Phase 4
Correctness under pressure
IdempotencyDesigning an action so that doing it twice has the same effect as doing it once. Essential where retries and double-clicks happen.Phase 4Race conditionA bug where two operations run at almost the same instant and interfere, producing a result impossible if they'd run one after the other.Phase 4Background workerCode that does slower work after the user's request has already been answered, so the user isn't kept waiting.Phase 4Cron jobWork scheduled to run on a clock rather than in response to a user: nightly reports, daily settlements, weekly cleanups.Phase 4Internal APIs / service-to-service callsOne user action often triggers several of your own backend services calling each other behind the scenes.Phase 4
The shipping machinery
Git and version controlA system that records every change to the code, who made it and when, and lets many people work without overwriting each other.Phase 6RepositoryThe shared home of a project's code and its full history, usually hosted on GitHub or GitLab.Phase 6Pull requests and code reviewA proposed change is opened as a pull request and read by another engineer before it's allowed into the product.Phase 6CI/CDAutomated pipelines that test every change and ship it, replacing slow, error-prone manual steps.Phase 6RollbackReturning to the previous working version when a release breaks something, the fastest way to stop the bleeding.Phase 6HotfixAn urgent, minimal fix pushed straight to production outside the normal queue to stop something actively breaking.Phase 6Feature flagsA switch that turns a feature on or off without deploying new code, separating shipping code from releasing features.Phase 6Config values and environment variablesSettings that live outside the code, so the same code behaves differently in different environments.Phase 6Remote configChanging an app's behavior, prices, text, limits, toggles, from a server, without shipping a new version. Vital on mobile.Phase 6
Knowing when it breaks
Monitoring and alertsDashboards that watch the system's health continuously, and alerts that notify humans the moment something crosses a danger line.Phase 6Incidents and postmortemsAn incident is a live production problem, handled with urgency; a postmortem is the honest, blameless write-up afterward.Phase 6Tech debtSpeed borrowed from the future: shortcuts taken to ship fast that must be repaid later, with interest, as slower work.Phase 6
Measuring the product
App events and instrumentationRecords the product emits when users do things, tapped a button, viewed a page, completed checkout. The raw material of all product data.Phase 7FunnelsA sequence of events viewed in order to see where users drop off: viewed, added to cart, checked out, paid.Phase 7A/B testingShowing two versions to different users at random and measuring which performs better, the honest way to settle design debates.Phase 7
Tier 3 · 0 of 24 known
How it runs at scale
Architecture-review and scale vocabulary.
Handling the crowd
Scalability (vertical and horizontal)How a system copes with more load. Vertical means a bigger machine; horizontal means more machines working together.Phase 5Load balancerA traffic director that sits in front of several servers and spreads incoming requests across them.Phase 5ProxyA middleman that forwards requests between two parties, sitting in the path to add control, security, or convenience.Phase 5Reverse proxyA proxy on the server's side: one public front door that receives all requests and passes them to the right servers behind it.Phase 5NGINXThe specific, extremely common software your engineers run as a reverse proxy and load balancer.Phase 5Stateless servicesDesigning servers so none of them remembers a specific user, letting any server handle any request. Required for horizontal scaling.Phase 5Rate limiterA guard that caps how many requests someone can make in a time window, blocking abuse and runaway traffic.Phase 3
Speed at scale
CacheA small, very fast storage layer holding copies of answers already computed, so the next identical request skips the work.Phase 5RedisThe near-universal in-memory data store used for caching, sessions, and queues, prized for being extremely fast.Phase 5CDNA network of servers spread around the world that serve your images, files, and static content from a location near each user.Phase 5
Data at scale
Database replicationKeeping live copies of the database so reads can be spread across copies and the system survives one database failing.Phase 5ShardingSplitting one database across many machines by a rule, when the data grows too big for a single machine to hold or serve.Phase 5Database vs data warehouseA separate copy of your data built for analysis, so heavy reporting queries don't slow down the live product.Phase 7
The modern stack
Cloud providers (AWS, GCP, Azure)Companies that rent computing on demand, servers, storage, databases, by the hour, so you don't buy or run hardware.Phase 5Docker and containersA way to package an app with everything it needs into a sealed, identical box that runs the same anywhere.Phase 5KubernetesAn automated manager for large numbers of containers: it starts them, stops them, spreads them across machines, and heals them.Phase 5Monolith vs microservicesTwo ways to structure a backend: one large codebase (monolith), or many small independent services (microservices).Phase 5Uptime and SLAHow much a system stays up, expressed as a percentage, and the formal promise (SLA) to keep it above a level.Phase 5Message queueAn orderly line for background work that holds tasks safely until a worker can handle them, even across crashes and spikes.Phase 4
Going global
Push notifications and deep linksMessages sent to a user's device to pull them back, and links that open the app directly on the exact right screen.Phase 7Email and SMS servicesSpecialist third parties that reliably deliver transactional messages, receipts, OTPs, alerts, at scale.Phase 7LocalizationAdapting the product for a different language and region, text, formats, and layout, not just translating words.Phase 7Currency and timezone handlingHandling money and time correctly across regions, two things famously easy to get subtly and expensively wrong.Phase 7MultitenancyOne system serving many separate customers (tenants) whose data must stay fully isolated from each other.Phase 7
Prefer a flat list? Browse A to Z. Progress is saved on this device.