Backend & Data

Busted

• 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.
• 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.
• Database transactionA group of database writes treated as one unit: they all commit together, or they all get undone together.
• 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.
• 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.
• IdempotencyRunning the same operation twice leaves things exactly as running it once did. It makes retries safe instead of scary.
• 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.
• 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.
• 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.
• Race conditionTwo things happen at once and the result depends on which one wins. Fine on your laptop, chaos under real traffic.
• 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.
• Seed dataStarter records loaded into a fresh database so the app has something to show: dev fixtures, demo accounts, and required lookup rows.
• Soft deleteMarking a row as deleted instead of removing it, so it disappears from the app but can still be restored.
• WorkerA separate always-on process that pulls jobs off the queue and runs them, so your web server can stay busy answering requests.

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