Backend & Data

Busted

• ACIDThe four promises behind reliable transactions: all-or-nothing writes, valid state, controlled concurrency, and durable commits.
• Audit logAn append-only record of who changed what, when, and to what value, so 'who did this?' has an answer months later.
• BackfillA one-time job that fills a newly added column, or repairs bad values, across rows that already existed, in safe batches.
• CacheA fast side store that remembers expensive answers so you skip the slow work next time. Great until it hands back stale data.
• Change data capture (CDC)A live feed of committed inserts, updates, and deletes, usually read from the database log instead of polling tables.
• Columnar storageStoring each column together so analytical queries can read only the fields they need and compress repeated values efficiently.
• Connection poolA small set of database connections kept open and shared across requests, so you stop paying to reconnect and stop hitting connection limits.
• Cron jobA task your server runs automatically on a clock: every night at 2am, every five minutes, the first of the month.
• Cursor paginationPaging by a pointer to the last row you saw instead of a page number, so new rows arriving never duplicate or skip results.
• Data pipelineA staged flow that pulls data out of one system, cleans and reshapes it, and loads it into another. The nightly job behind every dashboard.
• Data warehouseA separate home for historical data from many systems, built for heavy reporting without slowing the production database.
• Database constraintA rule the database itself enforces, so invalid values and broken relationships are rejected no matter which code writes them.
• Database lockA temporary claim that makes conflicting database work wait, so two transactions do not change the same data at once.
• Database transactionA group of database writes treated as one unit: they all commit together, or they all get undone together.
• Database triggerA database hook that runs automatically when rows are inserted, updated, or deleted, even if a different app made the change.
• Database viewA saved query you can read like a table. It gives complicated or restricted data a simple, reusable name.
• Dead letter queueA quarantine queue for jobs that kept failing, so good work can continue while operators inspect and safely replay the bad ones.
• DenormalizationDeliberately duplicating or precomputing data so reads get fast, accepting the chore of keeping the copies in sync.
• Document databaseA database that stores whole nested JSON records instead of flat rows spread across tables. One document holds the object and its children.
• Event-driven architectureInstead of calling each other directly, services publish 'this happened' events and whoever cares reacts on their own time.
• Eventual consistencyDatabase copies may briefly disagree after a write, but they should settle on the same state once updates finish spreading.
• Foreign keyA column that points at another row, plus a rule stopping it from pointing at nothing. 'This order belongs to that customer.'
• Full-text searchSearch that indexes the words inside your content, matches word stems, and ranks by relevance instead of a literal 'LIKE %cat%' match.
• Graph databaseA database built to follow relationships across many hops, such as friends of friends or dependencies of dependencies.
• IdempotencyRunning the same operation twice leaves things exactly as running it once did. It makes retries safe instead of scary.
• Identifier strategyThe rule for choosing record IDs, usually compact sequential numbers, globally generated random IDs, or both for different jobs.
• IndexA lookup structure the database maintains and reads instead of scanning every row. The usual answer to 'why is this query slow?'
• Job queueA list of slow tasks your app hands off to run later in the background, so the user gets a response now instead of waiting.
• JoinOne query that pulls matching rows from two tables together, so you get the user's name next to their orders.
• Key-value storeThe simplest database shape: give it an exact key and get back the value stored under that key.
• Many-to-many relationshipBoth sides can have several of the other, so a middle table stores each link, like memberships between users and teams.
• Materialized viewA stored snapshot of a query result that reads quickly and gets refreshed when you can afford the recomputation.
• Message brokerA middleman that stores and routes messages so senders and receivers can work at different times and speeds.
• N+1 queryOne query for the list, then one more per item. 50 rows on screen, 51 trips to the database, and a page that crawls.
• NormalizationStoring each fact in exactly one place and pointing at it from everywhere else, so an update only has to happen once.
• Object storageA bucket you throw files into by key and fetch back by URL. No folders, no filesystem, just cheap storage that grows as you fill it.
• One-to-many relationshipOne parent record can have several child records, like one customer with many orders; the child stores the parent's id.
• Optimistic lockingA version check that rejects your save when someone changed the record since you loaded it, instead of overwriting their work.
• ORMA library that turns database rows into objects in your language, so you query with code and types instead of raw SQL strings.
• Point-in-time recovery (PITR)Restoring a database to any exact moment in the past by replaying its write log on top of a base backup.
• Primary keyThe column whose value identifies exactly one row, forever. Hand the database that value, get back one record.
• Query plan / EXPLAINThe database's step-by-step route for running a query, showing scans, indexes, joins, estimates, and the work that is actually slow.
• Race conditionTwo things happen at once and the result depends on which one wins. Fine on your laptop, chaos under real traffic.
• Read replicaA read-only copy that follows the main database and handles SELECT traffic, with the tradeoff that fresh writes may arrive late.
• Replication lagHow far a database copy trails the primary, explaining why a write can succeed while a read from the replica still shows old data.
• Row-level securityDatabase rules that filter rows per user automatically, so an ordinary app query returns only the rows that user is allowed to see.
• Schema migrationA versioned script that changes your database structure, committed to git and run in order, so every environment matches.
• Schema-on-read vs schema-on-writeThe choice between checking data's shape before saving it and storing it raw so each reader interprets it later.
• Seed dataStarter records loaded into a fresh database so the app has something to show: dev fixtures, demo accounts, and required lookup rows.
• ShardingSplitting one table's rows across several databases so no single machine has to hold or write the whole dataset.
• Soft deleteMarking a row as deleted instead of removing it, so it disappears from the app but can still be restored.
• Stateless serviceA service where any instance can handle the next request because no user's required state lives only in one server's memory.
• Stored procedureA named routine that runs inside the database, useful when one controlled call must perform several data operations.
• Time-series databaseA database tuned for measurements indexed by time, such as metrics, sensor readings, and values drawn on monitoring charts.
• Transaction isolationThe rules for what concurrent transactions can see, from ordinary committed data to a fully one-at-a-time result.
• Unique constraintA database rule that refuses duplicates, such as two accounts with the same email or two identical memberships.
• UpsertOne database operation that inserts a new row or updates the matching row when it already exists.
• WorkerA separate always-on process that pulls jobs off the queue and runs them, so your web server can stay busy answering requests.
• Write-ahead log (WAL)The database's crash-safety journal: record each change durably first, then apply it to the main data files.

The territory

30 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• primary keycolumn or columns uniquely identifying each table row"the id column" · "what makes each row unique"
• foreign keycolumn referencing another table's row, enforcing relational integrity"this order belongs to that customer" · "linking two tables"
• indexprecomputed lookup structure making queries fast on chosen columns"why is my query slow on a big table" · "the thing that makes searching fast"
• schema migrationversioned, repeatable script that changes database structure safely"the file that adds a column without breaking prod" · "how do I change my database after launch"
• joinquery operation combining related rows from multiple tables"combine two tables in one query" · "pull the user's name alongside their orders"
• N+1 queryloop firing one query per row instead of one batched query"it hits the database once per item in the list" · "hundreds of tiny queries in my logs"
• database transactiongroup of writes that all succeed or all roll back"either both updates happen or neither" · "money left one account but never arrived"
• ORMlibrary mapping database rows to objects in your language"writing database stuff without SQL" · "the thing that turns tables into code objects"
• cachefast intermediate store holding results to avoid recomputation"remember the answer so we don't ask again" · "Redis in front of the database" · "caching layer"
• connection poolreusable set of open database connections shared across requests"too many connections error" · "why serverless kills my database"
• job queuelist of background tasks workers pull and process asynchronously"do the slow thing after the response" · "a to-do list my server works through"
• workerlong-running process consuming jobs off a queue"the background process that does the slow jobs" · "a second server that drains the queue"
• cron jobtask that runs automatically on a fixed time schedule"run this every night at 2am" · "scheduled script"
• idempotencyrepeating the same operation produces no additional effect"clicking submit twice shouldn't double-charge" · "safe to retry"
• race conditionoutcome depends on unpredictable ordering of concurrent operations"two people bought the last one at once" · "it breaks only under load"
• normalizationsplitting data into tables so each fact is stored once"stop copy-pasting the same data everywhere" · "one source of truth per field"
• denormalizationdeliberately duplicating data to make reads faster"store the count on the row so I don't count every time" · "copy it for speed"
• soft deletemarking rows deleted instead of removing them"hide it but keep it recoverable" · "trash can instead of shredder"
• cursor paginationpaging by pointer rather than offset, stable under inserts"load more without repeating or skipping items" · "paging that doesn't break when new rows arrive"
• audit logappend-only record of who changed what and when"history of every edit" · "who touched this record"
• row-level securitydatabase rules restricting which rows each user can see"users should only see their own data" · "multi-tenant data isolation"
• seed datastarter records loaded so a fresh database is usable"fake data to develop against" · "prefill the empty database"
• backfillone-time job populating a new field across existing rows"fill in the column I just added for old data" · "catch up historical records"
• point-in-time recovery (PITR)restoring the database to any past moment"rewind the database to yesterday" · "undo after someone dropped a table" · "backup and restore"
• full-text searchindexed search over natural language content with ranking"a real search bar over my content" · "search inside the text"
• object storagebucket-based store for files, cheap and infinitely scalable"where uploaded files live" · "S3-style file dumping ground"
• document databasedatabase of nested JSON-like records without fixed schema"store JSON documents instead of rows" · "MongoDB-style database" · "document store"
• vector databasestore optimized for similarity search over embeddings"search by meaning not keywords" · "where AI memory lives"
• event-driven architectureservices react to published events instead of direct calls"something happened, let other parts react" · "fire and forget notifications between services"
• data pipelinestaged flow extracting, transforming, loading data between systems"move data from A to B and clean it" · "nightly sync job" · "ETL job"

Deeper in the field

• unique constraint database rule preventing duplicate values in selected columns
• database constraint rule enforcing valid values and relationships within stored data
• one-to-many relationship one record relates to several records in another table
• many-to-many relationship records on both sides relate through a junction table
• upsert insert a row or update it when already present
• ACID guarantees governing reliable and consistent database transactions
• transaction isolation rules controlling what concurrent transactions can observe
• database lock temporary restriction preventing conflicting concurrent data changes
• optimistic locking version check prevents overwriting someone else's concurrent edit
• query plan / EXPLAIN database analysis showing how a query will execute
• database view named query exposed like a virtual table
• materialized view stored, refreshable result of an expensive query
• stored procedure logic saved and executed inside the database itself
• database trigger automatic action fired on insert, update, or delete
• write-ahead log (WAL) durability log recording changes before applying them
• message broker infrastructure routing asynchronous messages between producers and consumers
• dead letter queue holding pen for jobs that failed repeatedly
• stateless service server keeping no per-user memory between requests
• read replica copy of the database serving reads to reduce primary load
• replication lag delay before a replica reflects the primary's writes
• eventual consistency replicas converge to same state after a short delay
• sharding splitting one dataset horizontally across multiple databases
• change data capture (CDC) streaming database changes out as an event feed
• time-series database store optimized for timestamped metric data
• key-value store simplest database: fetch a blob by its key
• graph database store optimized for traversing relationships between entities
• data warehouse analytics-optimized store separate from production database
• columnar storage data laid out by column for fast analytical scans
• schema-on-read vs schema-on-write validate structure when reading versus when storing
• identifier strategy random unique identifiers versus sequential numeric keys