Easy everything in Backend Dev, page 14
Connection Pooling: Don't Re-Open, Reuse
A connection pool is a valet service for database access. Instead of creating a new connection for every request, you borrow a ready-made one and return it. This avoids costly setup/teardown in web apps.
Role-Based Access Control (RBAC) in Databases
RBAC bundles permissions into roles, like 'analyst' or 'admin', instead of assigning them to individuals. This simplifies managing who can read or write data in a database. The footgun is creating too many roles, making it as complex as individual permissions.
Differential Backups: Faster Backups, Simpler Restores
A differential backup saves all changes since the last full backup, making daily backups faster. To restore, you only need the full backup and the latest differential file. The footgun: each differential file grows larger until the next full backup is made.
Read Replicas: Scale Out Your Database Reads
A read replica is a read-only copy of your database that handles query traffic. Use it for read-heavy apps to prevent your primary DB from becoming a bottleneck. The footgun: replication is asynchronous, so reads from a replica can return slightly stale data.
Document Databases: Store Data as Flexible Objects
A document database stores data as self-contained objects, like JSON, instead of rows and columns. It's ideal for user profiles or product catalogs where each item might have different attributes. The footgun is treating it as a schema-less free-for-all.
Key-Value Store: The Simplest Database Model
A key-value store is a giant dictionary. You give it a unique key, like "user:123", and it returns the associated data. It's the foundation for caching and session management. The footgun is trying to query by value—it's built for key lookups only.
NoSQL: Databases Beyond Rigid Tables
NoSQL databases trade rigid tables for flexible models like documents or key-value pairs. This allows them to scale for massive, unstructured datasets from social media or IoT.
Nested Loop Join: The Brute-Force Database Join
A nested loop join is the brute-force way to match two tables. For each row in the first table, it scans every row in the second. It's simple and effective for small tables but its performance degrades quadratically on large datasets.
Database Pages: The Building Blocks of Your Data
A database page is the fundamental 8KB block for all storage. The database engine reads and writes entire pages, not single rows, for user data, indexes, and metadata. The key footgun: the physical order of rows on a page is not guaranteed.
Row vs. Columnar Storage: Organizing Data for Speed
Row stores group data by record, like a phone book entry. Column stores group by attribute, like separate lists for all names. Use row stores for transactions (OLTP), but for analytics (OLAP), they force you to read unneeded data from disk.
Storage Engine: The Database's Filing System
A database's storage engine is its specialized filing system, handling how data is physically written to and read from disk. Different engines optimize for different tasks, from fast writes to complex queries.
Row Mode vs. Batch Mode Execution in SQL Server
Row mode processes data one row at a time, like a checklist. Batch mode processes chunks of rows together for vectorized speed. Row mode is classic for OLTP, while batch mode shines in data warehousing for large scans.
B-Tree: The Workhorse of Database Indexes
A B-tree is a self-balancing tree that keeps data sorted for fast lookups, generalizing a binary search tree by allowing nodes to have many children. It enables searches, insertions, and deletions in logarithmic time, making it ideal for large datasets.
Query Execution Plan: The Database's Road Map
A query execution plan is the database's internal strategy for fetching your data. It's the recipe it creates before running your SQL. This plan determines whether to use an index or scan a whole table, directly impacting performance.
Shared & Exclusive Locks: The Read vs. Write Rule
A Shared (S) lock is like many people reading a library book at once; an Exclusive (X) lock is one person writing in it alone. Databases use S/X locks to manage concurrency, preventing writes from corrupting reads.
Database Transaction Log: Your System's Safety Net
A transaction log is your database's safety journal. Before changing data, it records the intended action in a durable file. This is vital for crash recovery, ensuring data isn't left corrupt. The footgun: its primary role is integrity, not just auditing.
Write-Ahead Logging (WAL): Survive Crashes by Journaling First
Think of it as a journal of intentions. Before changing data, a database writes the intended change to a log file first. This ensures that if the system crashes, it can recover by replaying the log, guaranteeing no writes are lost.
Lock Now or Check Later: Optimistic vs. Pessimistic Concurrency
Pessimistic concurrency locks data first, assuming conflict is likely ('ask permission'). Optimistic concurrency proceeds without locks and checks for conflicts before saving, assuming they're rare ('ask forgiveness'). Use pessimistic for high-contention.
Junction Table: Connecting Many to Many
A junction table is a bridge between two other tables, enabling a many-to-many relationship. It's used to connect students to classes or tags to articles. The common footgun is forgetting a unique constraint, allowing duplicate connections.
First Normal Form (1NF): No Nested Data
First Normal Form (1NF) means every table cell holds one single value, not a list. It's the first rule of relational databases, stopping you from storing comma-separated strings. The footgun is stuffing multiple values into one field, which breaks SQL queries.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles